Disadvantages of Agile Software Development
by Kelly Waters
Don't get me wrong. I'm a big fan of agile software development. If you're a regular reader of my blog, you'll know that :-)But I'm not so pro-agile that I've lost all sense of balance. An agile approach to development is good for so many reasons. But agile development does require certain things that can also be a disadvantage.
If you're thinking of adopting agile principles, it's important that you know what you're in for. You need to be sure that you, your project team and the management supporting your project all understand these trade-offs, and are happy to accept and support them in preference to a more traditional approach.
Here's my list of potential disadvantages with agile:
- Active user involvement and close collaboration are required throughout the development cycle. This is very engaging, rewarding and ensures delivery of the right product. It's the fundamental principle in agile that ensures expectations are well managed. And since the definition of failure is not meeting expectations, these are critical success factors for any project. However these principles are very demanding on the user representative's time and require a big commitment for the duration of the project.
- Requirements emerge and evolve throughout the development. This creates the very meaning of agile - flexibility. Flexibility to change course as needed and to ensure delivery of the right product. There are two big flip sides to this principle though. One is the potential for scope creep, which we all know can create the risk of ever-lasting projects. The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver. This can make it harder to define a business case for the project, and harder to negotiate fixed price projects. Without the maturity of a strong and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very dangerous.
- Agile requirements are barely sufficient. This eliminates wasted effort on deliverables that don't last (i.e. aren't part of the finished product), which saves time and therefore money. Requirements are clarified just in time for development and can be documented in much less detail due to the timeliness of conversations. However this can mean less information available to new starters in the team about features and how they should work. It can also create potential misunderstandings if the teamwork and communication aren't at their best, and difficulties for team members (especially testers) that are used to everything being defined up front. The belief in agile is that it's quicker to refactor the product along the way than to try to define everything completely up front, which arguably is impossible. And this risk is managed closely through the incremental approach to development and frequent delivery of product.
- Testing is integrated throughout the lifecycle. This helps to ensure quality throughout the project without the need for a lengthy and unpredictable test phase at the end of the project. However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project. This does have the effect of reducing some very significant risks, that have proven through research to cause many projects to fail. The cost of a long and unnpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs. However there is an additional cost to the project to adopt continuous testing throughout.
- Frequent delivery of product and the need to sign off each feature as done before moving on to the next makes UAT (user acceptance testing) continuous and therefore potentially quite onerous. The users or product owner needs to be ready and available for prompt testing of the features as they are delivered and throughout the entire duration of the project. This can be quite time-consuming but helps drastically to ensure a quality product that meets user expectations.
- Finally, common feedback is that agile development is rather intense for developers. The need to really complete each feature 100% within each iteration, and the relentlessness of iterations, can be mentally quite tiring so it's important to find a sustainable pace for the team.
I believe these trade-offs are well worthwhile. Software is complex. People are complex. And the only thing that's certain in projects is change. This lethal combination of unpredictability is more often than not helped by agile principles. So, in my view, for many project situations, the advantages of agile development far outweigh the disadvantages.
See also:
Is agile development right for your project?
Why most IT projects fail. And how agile principles help
10 good reasons to do agile
10 Key Principles of agile software development
5 September 2007 07:42
Active user/customer involvement is crucial to the success of any project, and should not be treated as a disadvantage, especially when there is potential for the requirements to change.
Changing requirements are not only ok, but necessary in certain projects. Agile processes emphasis that the project must be in a shippable state at the end of every iteration to counter the feature creep. In other words, feature creep is okay, as long as it doesn't hold up your releases.
Low requirements are ok, and doesn't create problems for newcomers because nobody says don't document at all. Documentation can definitely be done post-facto. The lower up-front documentation results only in less trashing.
Testing should be automated as much as possible, and testers should work with the development team to develop automated test cases, not perform manual test cycles.
6 September 2007 15:23
another big disadvantage is - for totally new project - the lack of a arquitecture. everybody is moving in small steps and sometime the full picture is lost.
I saw that also in upgrade project that the lack of a arquitecture or of some long-term view, make easy to take wrong solutions or wrong small scale arquitecture that afterwards need to be redone
24 January 2008 15:40
Great post! Recently we had a discussion on subject in our team and I must say you've listed all the disadvanages we talked about :)
8 May 2008 21:02
I am also a big fan of agile methodologies.
Another disavantage that needs to be mentioned though is the necessity to have all people in the same location.
The highly collaborative mode required for agile methodologies is not compatible with distributed locations.
It may be an issue in some contexts to involve the right resources.
28 June 2008 07:13
If you have problems with Agile, it's probably because you're not agile enough. As Mary Poppendieck said it: If you're 100% scrum, you're not 100% agile.
Real agility is not about being the opposite of waterfall model. It's basically about not using religions. It's about continuous improvement. If your customer doesn't like to talk to you, improve the way you work so that the customer gets happy. This may involve less customer cooperation.
28 June 2008 07:15
To Daniel: We have a large distributed team that is rarely located in the same city. I would say that agile is the only way to make this team work efficiently.
28 June 2008 07:19
To Anonymous: Architecture is the set of decisions you make early in the project. Agile software development is about making sure that the early decisions (=architecture) are made well. For instance, if you choose to base your application on IBM DB/2, and the customer doesn't accept software that uses DB/2 - would you prefer to find out after 1 month or after 6 months of programming?
28 June 2008 16:26
So very true. Every advantage brings with it some issues - no free lunch. The culture/tradition, the people and the project nature, all are interacting to make agile or any other methodology successful or not. What can be an advantage in some organizations can also be a big disadvantage in others because of the culture. I think various aspects of XP for example can be bot advantages or disadvantages depending on the context. Take pair programming - if you have people that like each other and are compatible, you will get a boost. But there are cases where forcing incompatible people to work in pairs will lead to disaster.
By the way, for my ironic view on agile adoption in the enterprise, you can glance at The Agile 800 Pounds Gorilla
19 August 2008 16:33
nice post I was thinking in this subject the last month and my main concern is about "the less predictability, at the start of the project and during, about what the project is actually going to deliver" because I work for a contractor and we need to give our users a pretty good estimate of time, money and scope before they give us a contract for the project.
By the way I'm thinking agile is more appropriate for in-house development
19 January 2010 09:23
realistically, using Agile, can you provide a quote to the customer that is as undefined as the system specification at the start of Agile ?
Without trying to specify as much as possible at the start and making the quote on that, will the customer accept a quote that is Agile in its response to changes as is the software that is Agile in its response to specifications ?
how do you manage scope creep , realistically in an Agile development paradigm.
19 January 2010 10:27
Hi Anonymous! I think for questions like this, you're better off asking the agile community for feedback about their experiences, so you can get an insight from a multitude of different people. You can find the community here:
http://www.agile-community.com
Kind regards
Kelly.
21 April 2010 10:29
what are the pros and cons of introducing measurement in agile software devlopment