Disadvantages of Agile Development

Disadvantages of Agile Software DevelopmentDon’t get me wrong. I’m a big fan of agile 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

14 Responses to “Disadvantages of Agile Development”

  1. Renji says:

    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.

  2. Anonymous says:

    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

  3. Nikita Knysh says:

    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 :)

  4. Daniel COHEN-ZARDI says:

    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.

  5. compaspascal says:

    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.

  6. compaspascal says:

    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.

  7. compaspascal says:

    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?

  8. Daniel Pietraru says:

    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

  9. Kmilo says:

    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

  10. Anonymous says:

    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.

  11. Kelly Waters says:

    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:


    Kind regards

  12. Anonymous says:

    what are the pros and cons of introducing measurement in agile software devlopment

  13. William says:

    1) Since there is no Design document for the functional implementation, It is hard for the client for handovering the project to another Vendor for maintainance/development.
    2 Frequent complaints & Escalations for every small reason. You start to look at every deviation with a microscope which mandates explainations to resolve things.
    3) Since the iterations are time-boxed, there is greater chance to compromise code quality to deliver on time.
    4) Poor understanding of Agile, inexperienced developers introduce regression defects or delays in deliverables.
    5) There is high chance of regression defects as there is not enough design documentation in place. It is hard for an experienced developer to go through the whole code to implement any change.

  14. Amit Bandekar says:

    Totally Agree!!

    When the develpment is to be done with hardware it becomes all the more difficult.

Leave a Reply

What is 6 + 5 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)