Comments on: Disadvantages of Agile Development

By: Anonymous

Anonymous — Wed, 21 Apr 2010 09:29:09 +0000

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

By: Kelly Waters

Kelly Waters — Tue, 19 Jan 2010 10:27:41 +0000

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.

By: Anonymous

Anonymous — Tue, 19 Jan 2010 09:23:17 +0000

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.

By: Kmilo

Kmilo — Tue, 19 Aug 2008 15:33:00 +0000

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

By: Daniel Pietraru

Daniel Pietraru — Sat, 28 Jun 2008 15:26:00 +0000

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

By: compaspascal

compaspascal — Sat, 28 Jun 2008 06:19:00 +0000

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?

By: compaspascal

compaspascal — Sat, 28 Jun 2008 06:15:00 +0000

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.

By: compaspascal

compaspascal — Sat, 28 Jun 2008 06:13:00 +0000

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.

By: Daniel COHEN-ZARDI

Daniel COHEN-ZARDI — Thu, 08 May 2008 20:02:00 +0000

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.

By: Nikita Knysh

Nikita Knysh — Thu, 24 Jan 2008 15:40:00 +0000

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

By: Anonymous

Anonymous — Thu, 06 Sep 2007 14:23:00 +0000

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

By: Renji

Renji — Wed, 05 Sep 2007 06:42:00 +0000

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.