I recently had the opportunity to hear Jean Tabaka, Agile Coach from Rally Software, speak in Brisbane at Yow! Nights about The 12 Failure Modes of Agile.

Jean has been consulting as an Agile coach for many years, so it was really thought-provoking to hear her top reasons of why the adoption of Agile might fail.

I thought I’d repeat the list on my blog for my readers because I think it’s a great compilation of potential pitfalls we should all work hard to avoid. Perhaps we could call them “Agile anti-patterns”!

The 12 Failure Modes of Agile (from Jean Tabaka)

1. “Checkbook commitment”

This refers to when people are saying they’re doing “Agile”, but without actually committing to it. They expect immediate results, and they use the same old organisational structure and metrics.

2. Culture that doesn’t support change

If the company culture is resistant to change, how can it adopt a methodology that embraces it? An example of this would be a culture where people are rewarded for not “rocking the boat”.

3. Ineffective use of retrospectives

Retrospectives must be done and handled effectively. The feedback gained via retrospectives must be learned from and acted upon. The whole team must be responsible for the actions from the retrospective, not just the scrum master.

4. Ignore needed infrastructure

For example, for a team to do Continuous Integration, it needs access to a build server!

5. Lack of full planning participation

The whole team needs to participate in planning and, as a team, commit to the work defined for the iteration.

6. Unavailable (or too many) product owners

Product owners are busy, but it is a warning sign when they say “we’re too busy for all this communicating”. Also, if there are too many Product Owners, it can be hard to get agreement.

Jean raised an intriguing question here: she asked how many people in the audience had done some form of Agile training. Many hands went up. Then she asked, how many people had worked with product owners who have been trained in Agile? I don’t think anybody raised their hand…

7. Bad scrum masters

The team needs to collaborate well within each iteration, and a poor scrum master can be harmful to the team’s morale and productivity. An example of a bad scrum master is one that plans all the work, puts it in a tool and then tells people to do it.

Jean made the point that if you take over the decisions for others you lower morale (and IQ’s!). Scrum masters should not control, they should empower.

8. Not having an onsite evangelist

This point is particularly important for distributed teams, or teams in branch offices. Without an Agile evangelist/coach onsite, the remote team can lose its way.

9. Team lacks authority/decision making ability

Agile is not about control, it is about empowerment.

10. Testing not pulled forward

Testing should be done up front, ideally, or else as soon as possible. Testing should also be automated.

11. Traditional performance appraisals

Traditionally, performance appraisals reward individual performance. In an Agile environment, the focus is on team performance, not individual heroics, and appraisals should reflect this.

Performance evaluations should also be regular, not once per year.

12. Change is hard, Agile is blamed

For example: an Agile methodology is introduced to solve a company’s problems. It fails, and Agile is blamed rather than the company’s own, deeper problems. It is often easier to look outwards and assign blame rather than to look inwards.