Agile Zone is brought to you in partnership with:

Michael became a Certified Scrum Master (CSM) in 2004 and is huge advocate of better (XP) engineering practices since discovering unit testing in 2001. Michael has a B.A.Sc. from University of Toronto in Engineering Science and a M.Sc. from U.B.C. in Computer Science. He has presented at Agile Tour Toronto and the XPToronto/Agile User group on Scrum and XP. His is also an active member of the Agile community and co-organizer of Agile Tour Toronto. Michael lives and works in Toronto, Canada, as an independent Agile and Lean coach, consultant and trainer. Michael is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

Shhh! Agile Failures (in the large)

  • submit to reddit
Agile failure is a sensitive topic but one that we as a community need to talk about in order to build a brighter future together. In this post, I will share some observations that came out of an informal session that took place over an extended coffee-break session at Play4Agile conference.

Survey Results

I ran a quick fist of five survey with first eight coaches and then with twelve as people. The question was:

“How many (percent) of your Agile transitions have been successful? Zero for none. Five for all.”

The results confirmed what I have suspected and experienced: a single one, lot’s of twos and threes, and one four. No zeros or fives.

It was noted that one problem with the survey is that Agile (Lean?) is a direction (dream of perfection) and not a destination.

Good news, Bad news

Consider the visual note below (start in the top left).

Agile in the small is fine

When probing about what was working and what wasn’t it became clear that agile in the small was working well. With single teams and smaller companies, people were pretty happy with the results. Even isolated teams at large companies seemed to find success when the teams wanted to go Agile. The principle that applies here is: Go where the energy is.

Agile in the large needs attention

Now that Agile has crossed the chasm and many more transitions are initiated by the early majority we are seeing more of “me too” Agile adoption. Some of the support found in earlier transitions are now missing:

  1. Strong management support
  2. Sense of urgency (Critical for Kotter model)
  3. Notion that: failure is not an option

Case studies MIA

One key need of early majority is case studies. We as a community do not do a good job sharing success stories and an even worse job sharing failures. This makes it hard to learn and improve.

Agile in the Large

Craig Larman and Bas Vodde have written a great book - Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum – on how to make Agile work in the large. This is a good start and paints a clear vision for alternatives for making Agile work.

We also have Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising. This is nice, but not nearly enough to get to a playbook for Agile adoption.

I believe that we as a community need focus more attention on models, patterns and guides for Agile transition and adoption. Lot’s of open territory here.

It’s about people. Duh.

One of the challenges with Agile in the large is that many people really don’t care about Agile and don’t want to change. Yeah, this happens with small teams too, but I find it is manageable there. When dealing with hundreds and thousands of people the problem gets amplified.

I thank Christine Neidhardt for reminding me that organizational change is about people. The way to change an organization is one person at a time.

Published at DZone with permission of Michael Sahota, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Shumona Kapil replied on Sun, 2012/02/19 - 9:55am

Nice post! I agree we need more Case studies, but that is just a start. We really need to focus on where tings went well or not so well (failure or not) and do a lot to capture the context of the organization of a particular case study. I’d like use to build an Agile Body of Experiences, not Knowledge as PMI uses which implies it is the end all be all. Experiences implies an organically growing body of information that folks can turn to… Something they can use as a research tool to answer the question “I think I want to try X, who else has tried X and what was their experience in adopting it?”

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.