The pros and cons of Agile

As with everything in life, there are pros and cons when using Agile. We believe that the pros far outweigh the cons. To be fair this blog post will cover both.

Because I am an eternal optimist, I will list the pros first:

Revenue: The revenue advantages are two-fold. Firstly, small sections of work are completed per iteration. These can already be made available and sold while the project continues. This ensures prompt and steady release cycles. Secondly, developers make prompt changes as requested by product owners. These changes won’t have a huge impact on the base line of the project, as they are handled before developing continues.

Customer satisfaction: Agile inspires active participation from all parties and consistent evaluation of the product. This happens while the developers work. Users or product owners request modifications during development, rather than when everything is done.

Cost Control: The definite time allocation per user story enables a fixed cost even though the product’s requirements may change. The product and features are variables, rather than the budget.

Flexibility: The agile development team expects changes and welcomes them. Not only does it guarantee fulfilled requirements, but meets the approval of the product owner. Instead of having a fixed time line, the team moves the focus onto customer satisfaction.

Product evolution: Because of the constant involvement of the product owners and the entire team, the product grows into the right direction. It ensures that the meets customer expectations and industry regulations, engages the latest technology and encourages learning among all.

Team spirit: Most people enjoy the active collaboration, assistance and group effort in Agile teams. The satisfaction of delivering a working product is immense. It encourages the team spurs it on to greater heights.

And here are the cons:

User commitment: The user (or product owner) of the completed software is very involved in the development cycle. This close collaboration ensures that expectations are met or at least managed. While this works really well, it is quite taxing on the user. When expectations are not met, the sprint/project failed according to Agile. So it is very important for the user to be really committed. This includes:

• communicating requirements / expectations
• meeting with the team on a regular basis
• finding solutions

Changing requirements: In an Agile environment change is welcome throughout the project. This should be a positive point, but there are some negative spin-offs. One of these is scope creep that could cause a never-ending project. Another is a lack of certainty. Changing requirements involve removing user stories from the backlog. This in turn means that the user is not 100% certain of the functionality that will actually be delivered at the end of the project.

Testing: In Agile, testing happens during the development cycle. Not everybody sees this as a good idea. There are two reasons for this. One is that a tester is needed throughout the project, instead of just at the end. The other is that functionality often re-tested more than twice as the different increments of software come together to form a whole. This may make testing extravagant and uneconomical.

Development team: Lastly, some agile teams find developing in Agile very intense. They are expected to achieve a 100% sprint pass rate. The constantly repeating iterations may be exhausting and unattainable for some. So it is important to find a suitable pace for the team.

In the next blog post, we are looking at doing agile in a virtual team… we have first-hand experience here!