Deconstructing Agile

When you hear the word Agile, what do you think of? Maybe smooth, quick and effective movement. Now apply that to software, apps and the IT world. Here we have a methodology that breaks down projects, making them more doable while also allowing for constant testing. Despite all of this, Agile has garnered criticism, especially from large companies. According to them there are just too many limitations to make it a worthwhile approach. Still, as a business that actually employs Agile, we at Parthenon have seen its benefits.

Let’s break down a few of the arguments from our perspective.

One of the things Agile emphasizes is the capability of developers and the quality of their work. One would think having highly skilled people producing high quality work would be the ideal, but there has been an outcry of exclusivity. The main argument here is that the average joe is not necessarily highly skilled. It’s a given that not everyone is as skilled as others, but doesn’t mean Agile can't be used. For us, it’s about hiring the right people. All of our developers must complete a coding test, demonstrating their skills. Now before you call foul, we also hire developers who exhibit potential. They are paired with higher level developers, ensuring that they get the help they need and that the quality of our work is maintained.

Another component of Agile concerns a business's organizational culture. All too often businesses can get stuck in a cookie cutter approach to projects. Their argument consists of the belief that not everyone can hold themselves accountable or stay organized without direction. Once again, hiring the right people makes a difference. This is not to say that upper management is dispensible. At Parthenon we have project managers to direct and guide developers when needed. We also have a ticketing system that keeps people on track. We set a goal and let greater freedom allow for more creativity, discovery of newer ways to doing things and the potential for higher quality work. We understand the importance of creativity and embrace the newest and most effective ways of doing things.

Larger projects must be augmented with organizational structure carefully to preserve a creative atmosphere. Since Agile favors smaller teams, big companies and organizations have argued that their projects and teams are too large for Agile implementation. Yet, how effective are these teams? It's been proven that smaller teams are more effective. How so? We allow team members to communicate directly with each other. Meetings can waste time if the do not serve a need, and too many people designing the same thing can lead to disagreements over trivial matters.  We encourage our developers to identify a need in the course of their work, and then contact the best people to assist them.

As for the workload, Agile breaks a project into smaller project pieces and delivery of the pieces once they are ready. We deconstruct a task, identify its critical components, and then work to complete them individually before combining them into a finished product.  This allows us to optimize our workflow in different ways.  Smaller components allow us to leverage pre-built modules, and can test each piece easier for a more stable result.  We can also reallocate programmers from one project to another as more or less work is required.  This keeps our developers fresh, always experiencing new challenges and gaining unique experience.  Work gets done faster and more cost effectively with less mental fatigue.

The aforementioned examples are only a few of the many arguments for and against the use of Agile. It can be argued that since Parthenon is a relatively small company, we are the ideal candidate for Agile, but that doesn't mean it should be completely discounted by larger companies. Sure it will mean change, but that’s not always a bad thing.