What are pitfalls for agile development methodologies?

Question

What are pitfalls for agile development methodologies?

Answer 1

The common criticisms include:

• Lack of structure and necessary documentation
• Only works with senior-level developers
• Incorporates insufficient software design
• Requires too much cultural change to adopt
• Can lead to more difficult contractual negotiations
• Can be very inefficient — if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once.
• Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements
• Can increase the risk of scope creep due to the lack of detailed requirements documentation
• Agile is feature driven, non-functional quality attributes are hard to be placed as user stories

Answer 2

This is very a philosophic question. Here one pitfall: Management that thinks that agile development could excuse 180 degree turn every two weeks. Another pitfall is that when done wrong, the work load isn't well balanced between team members.

Answer 3

Using Agile as an excuse to spend insufficient time and effort on planning, requirements definition, and documentation.

Answer 4

PHBes who think "agile" means "get things done with fewer people" ;)

Answer 5

I disagree with all of the common criticisms except "Can lead to more difficult contractual negotiations". It is difficult to get around this if your customer does not want to have anything to do with your dev process.

The other items are only true if your dev process is broken in some other way, like you don't do unit testing or continuous integration or version control.

The main pitfall is trying to do a "sort of agile" approach without every having read the Agile Manifesto or done any study of the doingess of the subject.

Answer 6

I think the number one pitfall is thinking that "agile methods" means that you can do or not do anything you want. I would hazard a guess that most people who use agile, really use "ad hoc" rather than implementing those practices that lead to agility. Agility requires work and discipline, perhaps more so than plan-driven development.

I get a chuckle out of people who say that agile is less efficient because changes can occur and you'll have to do stuff over. The reality is that changes occur and you have to do stuff over (or end up with an unhappy customer) regardless of method. Agile methods just accept that this will happen and try to use methods that allow it to happen in the least disruptive way. To be efficient you still need to be disciplined about what changes you allow, using agile just gives you a better chance to say yes and still get done on time.

Answer 7

My sense is that the biggest risk of Agile methodologies is its reputation for being "flexible." That is, you run the risk that developers begin filling in their own definitions for Agile methodologies. If this happens, you'll end up with essentially no methodology at all.

Answer 8

From @Gortok's quoted list, with my rebuttals...

• Lack of structure and necessary documentation

  1. Many agile methods are highly prescriptive of essential practices and have structure, though much of it is informal.
  2. Define necessary. Much documentation required by plan-driven methods is not used and/or hopelessly out of date. Agility focuses on producing those deliverables that are actually needed.

• Only works with senior-level developers

  1. Works best with developers who can work independently (or in pairs).
  2. A mix of senior/junior developers works just fine.

• Incorporates insufficient software design

  1. Incremental design with aggressive refactoring can lead to better design because much of the design is done with better understanding of the application.
  2. A valid criticism might be that agile implementers may be afraid to do any design up front for fear of not being "agile" -- none of the methodologists would recommend entirely skipping up front design.

• Requires too much cultural change to adopt

  1. Can be valid, but in my opinion it is worth it

• Can lead to more difficult contractual negotiations

  1. Definitely. This should change as more agile successes are achieved.

• Can be very inefficient — if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once.

  1. Only if the plan is rigidly adhered to at the expense of actual desired behavior, otherwise you have the same problem.
  2. If changes do occur, agile methods handle this better than plan-driven methods.

• Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements

  1. Most agile methods give you good tools to understand your velocity.
  2. Planning is hard for all methods. This is not unique to agile methods.
  3. Agile methods, by putting software in the customer's hands early discover the real requirements faster than rigorous, up-front planning because the customer doesn't know what he really wants until he sees it.

• Can increase the risk of scope creep due to the lack of detailed requirements documentation

  1. Agile takes a completely different perspective to this. It focuses on scope/time trade-offs rather than limiting scope to keep fixed time.
  2. Customers get to make choices about the scope/time trade-off in Agile, so they are in complete control of scope.

• Agile is feature driven, non-functional quality attributes are hard to be placed as user stories

  1. You can use whatever method you want to track quality attributes, including traditional methods from plan-driven practices if you want.

Answer 9

Thinking that Agile is an excuse to do "fly be the seat of your pants" development.

Answer 10

The biggest pitfall is that people look at the practices and miss one thing:

• Inspect and Adapt

If you, as a team, are not constantly evaluating your practices and finding out what works, what doesn't, what needs to be tweaked, and what needs to be adapted, then you'll likely fail.

Answer 11

• Agile can only be successfull if you have the requirements for atleast one sprint.
• Most of the clients will tend to not have proper requirements or they change frequently in middle of the sprint, which leads to re-planning and starting the sprint again.
• Agile could be more successfull when the application is in maintenance mode, where the application is already in production and the dev is simply adding more features to the application in each sprint.
• Management has one advantage, they get to sneak into the devs/qa daily life at work (in the sprint meetings every day).
• It could eat thru budjet pretty fast if proper planning is not in place (most of the time this occurs due to change that needs to adopted).
• Since there is less/no documentation, you cannot make one person accountable for a feature that is miscommunicated or misunderstood.
• This lack of accountability may lead to more problems of one being deliberatly not performing their part in the team.
• Developers might get frustrated with constantly changing requirements and re-work that is involved. (imagine tweaking the same feature in 5 sprints, which could be compleated in one sprint with properly analysed requirements).
• Business/Client representative tend to not take the accountability of giving proper requirements.

I have been working with Agile processes for 3 years now. Before that I used to work in CMM Level 5 company where waterfall methodolgies were followed.

Answer 12

A lot of the answers here are not pitfalls, the are criticisms. In my mind, "pitfalls" are potential problems to watch out for, not reasons to avoid agile.

Here are some of mine from Extreme Programming:

• Personal hygiene, sexual comfort, and intimate social skills suddenly matter more with Pair Programming

• It's easy to get so excited about Refactoring that you want to refactor code that doesn't matter, to apply advanced patterns to trivial routines, and to refactor right before deadlines.

• The practices support one another in important ways. If you abandon one, you'll get in to trouble in another. For example, if you stop doing TDD, your Refactoring will get harder & riskier.

• Just because you think you're following the practices doesn't mean you're doing it right. You really need to have talented people, to understand how XP works, and to do it right.

• You may still fail. Just because you're all agile doesn't guarantee that you'll complete your project, or that it'll be good software that your customers want.

Answer 13

A good analysis of Agile weaknesses could be found in Tom Gilb's article "What's Wrong With Agile Methods" (http://www.methodsandtools.com/archive/archive.php?id=58)

Answer 14

Common objections from organizational and personal levels discussed: http://agileinaflash.blogspot.com/2010/02/organizational-objections-to-agile.html http://agileinaflash.blogspot.com/2010/03/personal-objections-to-agile-process.html