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 7 + 3 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”