Summary
Contrarians reject the majority opinion and often have personal reasons to degrade Agile. These writings often disqualify themselves through bias, thus failing to benefit the community. But non-contrarians - practitioners who tend to support the majority view - may be in the best position to drag the skeletons out of the closet.

The Salt Lake Agile Roundtable is a group of practitioners that meet monthly to discuss items of interest to the group. I had asked the group for pointers to seminal papers on Agile development. Of the many topics I was interested in, two resonated with the group:

Why Agile Fails - Traps and pitfalls that can destroy adoption or cause agile teams to fail.

Why Agile Sucks - Contrarian views; must be better than just bitching about why some schmo couldn't get Agile to work.

I didn't want papers from people with an axe to grind or who didn't understand Agile development; that seemed to be the case with most of the contrarian papers out there. The roundtable thought it would be interesting to brainstorm a list of problem areas ourselves: What do knowledgeable and experienced Agile practitioners say about this?

What follows are a list of traps and pitfalls we identified.

1. Agile teams may be prone to rapid accumulation of technical debt. The accrual of technical debt can occur in a variety of ways. In a rush to completion, Iterative development is left out. Pieces get built (Incremental development) but rarely reworked. Design gets left out, possibly as a backlash to BDUF. In a rush to get started building software, sometimes preliminary design work is insufficient. Possibly too much hope is placed in refactoring. Refactoring gets left out. Refactoring is another form of rework that often is ignored in the rush to complete. In summary, the team may move too fast for it's own good.

2. Successful Agile development presupposes that team members will all act like adults. That's a euphemism for being competent and professional. Agile teams are expected to to accept a high level of responsibility and accountability. When they don't, things can fall apart really fast.

3. Agile methodologies misunderstood may lead to team burnout due to an irrational culture of ugency. We even use the word sprint, a term that is not connotative of sustainability.

4. Agile requires more team and individual discipline, commitment and openness than a dysfunctional organization may be able to bear. Yet a dysfunctional organization is likely to place excessive hope in Agile as a silver bullet.

5. The high visibility on agile teams causes poor performers to stand out. The benefit is that the organization can take corrective action. In the absence of corrective action, poor performers may try forms of sabotage to avoid detection.

6. Agile teams have a tendency to focus on tactical accomplishments at the expense of strategic goals. Missing the big picture can lead to long-term failure at the expense of sort-term success.

7. Agile can be hard on the product owner who has a lot of responsibility. They are often asked to provide real time requirements support, make feature and business decisions, define acceptance criteria, and be constantly available to answer questions. The product owner is often responsible for understanding and communicating the needs of the customer and the company. This role can become a bottleneck because it is unable to "feed" the development team fast enough.

8. Agile is over-hyped, thus leading to unrealistic expectations. 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. A moderately successful agile development team usually will no longer be the bottleneck. Other departments can no longer blame development and this may give rise to a shift in political games.

10. Too much power can be granted to the product owner when it comes to steering the product. If they have an agenda, they can cause a lot of damage. Agile teams often seem to lack sufficient checks and balances.

11. Agile is too programmer-centric leaving it unclear how to balance work across an organization. There is a need for better documentation and coaching for non-development participants.

That's the list we came up with; no solutions yet. Most of these traps are not specific to Agile but the group felt that Agile development is predisposed to these problems by its nature.

Thanks to all the attendees of the Salt Lake Agile Roundtable for this list. Do any of these traps and pitfalls resonate with you? What traps and pitfalls have you experiences with Agile development? Are you a practitioner? Contrarian? Or both?

Talk Back!

Have an opinion? Readers have already posted 38 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Sean Landis adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Sean Landis is a technologist and programmer interested in, among other things, mobile and distributed sytems, location-based services, and skiing.