Traps and Pitfalls of Agile Software Development

This past Black Friday 2010 I found myself outside Best Buy in a line all the way around the building in the freezing cold. As I fumbled with the thrown-out Black Friday specials pamphlet I found on the ground I wondered whether this was all worth it. An hour later, I was inside dodging the crowded tables of technology and gadgets galore. My shopping-discernment had all but dissipated into a mere memory and my buyer-rationalization began full force.

It’s easy to rationalize why we should buy something. It’s far easier to weigh the positives than the negatives. I could tell you 10 different reasons why I need the new Macbook Air. But stop me mid-sentence and ask me about the negatives? Be off with you fiend! Maybe if I had @agileforall‘s terrible experience with the new Macbook Air I may not get one…

But sometimes it’s best if we look at the negatives first. Sometimes it’s easier to find out what you want or like, by first, considering what you don’t want or dislike.

That’s what a group of guys did at the 2009 Salt Lake Agile Roundtable did. We like what they had to say.

Why Agile Fails or Why Agile Sucks:

  1. Agile teams may be prone to rapid accumulation of technical debt.
  2. Successful Agile development presupposes that team members will all act like adults.
  3. Agile methodologies misunderstood may lead to team burnout due to an irrational culture of urgency.
  4. Agile requires more team and individual discipline, commitment and openness than a dysfunctional organization may be ready for.
  5. The high visibility on agile teams causes poor performers to stand out like a sore thumb.
  6. Agile teams have a tendency to focus on tactical accomplishments at the expense of strategic goals.
  7. Agile can be hard on the product owner who has a lot of responsibility.
  8. People are led to believe agile development will solve all their problems with minimal effort and experience disillusionment when it doesn’t meet their expectations.
  9. A variation on The Blame Game can arise from other business units, not on the development team, but on each other.
  10. Too much power can be granted to the product owner when it comes to steering the product.
  11. Agile is too programmer-centric leaving it unclear how to balance work across an organization.

We know this list is a year old, but it’s a good one to return to. Again, sometimes it’s good to know where the pain points are going to be in the beginning so you can make decisions around how not to do something.



13 Replies to “Traps and Pitfalls of Agile Software Development”

  1. Great list! I’ll point out two items…

    I wholeheartedly agree with “H. People are led to believe agile development will solve all their problems…”. So many folks think Agile is a silver bullet to solving problems. It isn’t. It is a silver bullet to exposing problems (and giving you some techniques to solve or avoid them).

    Second, both B & E are directly related IMHO – so many of the folks that are poor performers IMHO or those that don’t want to be responsible individually; they spend time ducking it! This is simply not an adult behavior.


  2. I strongly agree with these two

    C. Agile methodologies misunderstood may lead to team burnout due to an irrational culture of urgency.
    D. Agile requires more team and individual discipline, commitment and openness than a dysfunctional organization may be ready for.

  3. This is a pretty spot on list. One I would like to add, I got from Mike Cottmeyer’s Leading Agile blog. It’s actually a guest post by Jurgen Appelo.

    Quote: I believe a “weakness” of the Agile Manifesto is that it doesn’t (explicitly) recognize that all software projects need people being smart, disciplined, and attentive.

    Go back and check out the blog post. It’s a great read.

    Until then, keep up the great work!

  4. I believe the title is a bit deceiving and should be more along the lines of “Agile Pitfalls”.

    These are great points to look out for, but if such challenges are anticipated Agile can and has proven to be a progressive solution over traditional approaches. To be more specific, I believe that certain techniques under the Agile umbrella are not necessarily realistic. For example, I employ a scrum derivative as I feel “locking in” to sprints is just not flexible enough. We can however take such principals and make adjustments for what feels most natural.

    To address some of these points,

    A. Create a bug backlog that takes precedence over the sprint in progress. Make sure uncovered defects are addressed quickly, even if it slows velocity.

    B. Team building is an art. Agile is not for everyone and we should thoroughly understand our team’s attributes and weaknesses before delving into a project.

    C. Sure, this could happen. However even if you have a team that is engaged in direct customer communication, it is a good idea to have one team member (who I call the project executioner) to act as a buffer. He or she understands what is and what is not truly urgent despite a customer claiming the Apocalypse. These points are then placed appropriately into 1 of 3 categories; 1) Priority – Off Cycle (emergency), 2) Current Sprint / Iteration or 3) Product Backlog. A good buffer will keep the “emergency” list at a minimum.

    D. Agree, if your organization does not seem to meet this qualification then either don’t employ agile or focus on improving problem spots.

    E. Agree, agile teams assume highly skilled team mates. It may be the case that some team mates simply do not possess the experience necessary to work in this environment. On the other hand, this odd man out may quickly realize he/she needs to get his/her ass in gear. Continual learning and self improvement are good things in my opinion.

    F. Strategic goals can be conveyed as osmotic communication in the form of a project wiki or white board notes. Keeping these goals in mind can help maintain a higher level perspective throughout each iteration.

    G. This sounds more like a complaint. Whoever has this role should have a solid understanding of what it entails before being cast as the “product owner”. If you can’t take the heat get out of the kitchen.

    H. Keep it real people. Stakeholders who are lead to believe this just aren’t being properly educated. Before adopting agile, explore the risks and benefits.

    I. I can’t speak with much experience here. I’m sure this can happen but I have a relatively small web development firm. My “other departments” are not large and complex.

    J. See my recent post on “Death to Project Management”. I believe responsibility and power can be more evenly distributed (pending certain variables).

    K. Again, having a development centric business I can’t say much on inter-organizational implications. I will say however that I feel Agile is very customer centric with frequent communication and high level user stories. It is a more natural way of working than traditional document centric development.

    Just my thoughts.


  5. Let me clarify the first part of my post. I mistook the sub-title “why agile fails or why agile sucks” as the actual title of this post. Had I looked twice, I would have seen the actual title was exactly what I had suggested! My bad. I believe my other comments are still valid however 🙂

  6. I think the list captures the key reasons why people experience difficulties in implementing agile methods and agile thinking when the organization is new to the idea. The only item that may be misplaced is item E, which I think is not a weakness or pitfall, but a strength or benefit of the agile approach.


    To say “agile” fails or sucks or whatever seems to me to overlook the very first value statement in the Agile Manifesto. “Agile” as such doesn’t do anything at all. “Agile” as such has no fears, aspirations, knowledge, or habits. “Agile” as such cannot succeed or fail. Outcomes depend on what the people do. It really doesn’t matter whether they call their methods “agile” or not.

    One point that isn’t called out explicitly in the list is that most agile methods (like XP, for instance) assume the technical team members are at a high level of professional skill and that they are deeply committed to the pursuit of excellence. Some people are. Most people aren’t.

    Anecdotal evidence suggests only a small percentage of individuals who earn a living by writing software are actually any good at it, and that the majority of people who have any sort of job at all (including software development) are mainly interested in the paycheck, and in surviving the work week with enough energy left over to enjoy their weekend.

    Something sucks, perhaps, but it isn’t necessarily “agile.” It’s easier to blame a buzzword than to take a hard look in the mirror. Before these teams discovered “agile,” they were blaming some other buzzword. Two years from now, they will be blaming a new buzzword.

    It may be that what we like to call a “dysfunctional organization” is, simply, an “organization.”

  7. Pingback: Project Management At Work » Blog Archive » Weekly project management news roundup: Pitfalls of Agile project management; Barriers to Agile transformation; Why are we doing Agile?,and other interesting posts

Leave a Reply