All About Agile | Agile Development Made Easy


Disadvantages of Agile Development

by Kelly Waters, 4 September 2007 | Agile Adoption

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:

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.

Kelly.

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

Home



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:

    http://www.agile-community.com

    Kind regards
    Kelly.

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