Everyone is using Agile development but most teams are failing to achieve the anticipated benefits. There are many reasons that Agile fails, but here are some of the most common fatal flaws in the way companies try to implement Agile.

1. Having the wrong person as scrum master or Agile coach

Agile is an iterative process that takes time to master as a team. Agile works only when someone understands how the pieces are supposed to fit together, what role each team member should play, and what software to use to manage your Agile process, and then helps the team to make the necessary adjustments over time. The person running your Agile team needs to understand "enough" about product management, development, design, etc., and know the Agile process well enough to identify deficiencies in the quality and number of user stories.

2. Stand-ups are too frequent and useless

If you are doing a daily stand-up, have they become meaningless and rote? I prefer having stand-ups a max of twice per week. The rest can be handled via email, IM, or preferably, your Agile workflow tool, such as Jira Agile (formerly Greenhopper).

3. Sprint planning sessions are too long and mistaken for design meetings

Most teams hold marathon sprint planning sessions that mistakenly try to cover things best addressed in other venues. A sprint planning meeting is not where features should be argued and designed, nor the backlog extensively groomed. Prior to sprint planning, there should be some reasonably fleshed-out user stories, somewhat groomed (i.e., prioritized in the backlog). The sprint planning meeting should not exceed 1 hour per two weeks of development. The meeting should consist primarily of the product owner explaining the priorities s/he would like to see in the upcoming sprint, the developer offering a point estimate, and the team agreeing to the overall commitment for the upcoming sprint. Certainly, clarify any questions from developers in how to implement a feature or the QA team in how to test it. But, it is not the time to decide how a screen should be laid out or what the overall product vision should be.

4. Trying to make a silk purse out of a sow's ear

If your developers are terrible, Agile will not make them better. If your product owner is unfocused or absent, Agile won't solve the problem. Agile will not make a dysfunctional team functional. It can, however, make a functioning team more productive and focused.

If you have the wrong staff, replace them, train them, or reassign their roles.

5. Not involving QA properly

Agile works best when there is a dedicated QA person embedded within the team. If the QA person isn't present in stand-ups and sprint planning, it is highly likely s/he will not be able to QA features properly and rapidly. This leads to a QA cycle that is out of step with the development sprint. Because tasks are not tested and closed in a timely manner, they are not credited towards the team velocity, and the project loses focus and momentum. If you don't have a dedicated QA resource, consider hiring one or assigning responsibility to one or more team member(s).

6. Using Agile to bludgeon or bully developers

Agile falls apart rapidly if there is not trust among the parties involved. Agile needs to be based on two-way conversations, not used as a club against developers who are perpetually "late." Critically, only developers are allowed to estimate how many points a user story will require to develop. That is, whereas the product owner sets the priorities, it is developers who decide how many items can be moved from the backlog into the current sprint.

7. Too many or too few tasks and user stories, especially when first beginning Agile

Many projects are begun from scratch using Agile development. These often suffer from having too few tasks and user stories (or ill-defined user stories) groomed in the backlog and ready for estimation during a sprint planning session. It is important for the product owner to formulate clear directions on, say, enough tasks for the current sprint plus two or three sprints into the future. Otherwise, developers are sent off to code ideas that are only half-baked.

Conversely, many projects begun using traditional waterfall (or no) development model are converted to Agile because the initial attempts were not working well. In that case, you might have a backlog of hundreds of uncategorized tasks and bugs. That much pent-up demand is not a good way to approach Agile. Tasks need to be clarified and prioritized, so the team can build momentum in the first few sprints.

8. Lack of patience or misunderstanding of time requirements

Agile takes a day to learn and a lifetime to master. Every team makes mistakes and needs to know, going in, that there will be an adjustment period. It might take six sprints (12 to 24 weeks), to work out kinks in the workflow software, learn how to write good user stories, learn how to accurately estimate stories, and determine your steady-state velocity. Usually there are many other pressures going on (bugs, feature requests, deadlines, funding), so when things go wrong, you have to know not to blame Agile itself.

Conclusion

There are many, many other pitfalls in Agile development, but the ones above are the most common and damaging.

Agile development can work extremely well for smart teams that heed its guiding principles without falling prey to zealotry. As if often said about money, Agile is an excellent servant but a terrible master. Find things that work for your team without being overly rigid. In the words of Bruce Lee, "Be like water." Be Agile!