Shhh! Agile Failures (in the large)

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.

Addendum

Subsequent to publishing this, I found this great post that I strongly recommend: Agile’s Second Chasm (and how we fell in)

Print Friendly
 

18 Comments »

  • Ilja Preuß Said,

    February 28, 2011 @ 3:16 am

    “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.”

    Frankly, I don’t buy it.

    That is, of course people don’t care about Agile. Why should they?

    In my view, the key to a sustainable transition to Agile, at any scale, is caring about the people involved, finding out what they long to accomplish, and genuinly supporting them in achieving it – and then tying Agile values, principles or practices to it *where it makes sense*. When you do that, you might find out that people actually can be quite passionate about change…

  • Paul Boos Said,

    February 28, 2011 @ 9:13 am

    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?”

    If we can record this information and maintain some semantics about it, whether it be as simple as an exercise for a retrospective or as large as an Agile adoption, then we’ll certainly have a lot to gain as Community.

    Cheers!
    Paul

  • Michael Sahota Said,

    February 28, 2011 @ 4:08 pm

    Hi Ilja, thanks for your comments… it seems like we agree. Agile is something that we do to support people, not something we do to them. That’s why organizational change is about people. Unfortunately, in the context of a top-down push for Scrum things can go quite wrong.

  • YvesHanoulle Said,

    March 4, 2011 @ 9:11 am

    people never want to change when they don’t see the advantages of the change.
    I know no one who says I would not want to receive a million dollar and be unhealthy rich.

    Two years ago I proposed a session for agile tour toronto about agile failures. I could not do it (failed at it, “How Fascinating” ;-))
    Mainly because what do I call a failure? Every time I finish a coaching job I feel like damn they could have gotten 10 (or 100) times better. And everytime I have to realize, yes I hav eseen things a lot better, but fir this company that was much further as what the people on the floor imagined what was possible x time ago.

    + About case studies:
    As a coach I promise the people I coach that what they tell me I won’t go talking to their boss or the rest of the world. The same is true for the organisations (my clients) I don’t want to drag their garbage out in the open.
    Part of why I can do the work, is because they trust me.
    If I would publicly say that went wrong at that company. I doubt new clients will trust me enough to do the work I want to do.

    We could drop the name.
    - Case studies without a name don’t work
    - My clients will feel they still could be recognized. (and that is true, look at my linkedin page and see what healthcare company I worked for and boom you got a name. Or a British Service company …

  • Michael Sahota Said,

    March 4, 2011 @ 9:31 am

    Yves – Thank you for you insightful comments. For me the goal of negative case studies is for the community to get the learning so names are not that important.

    I agree with you about confidentiality and trust. So anonymity is needed. Maybe an easy place to start is at Coach Camp.

  • YvesHanoulle Said,

    March 6, 2011 @ 7:14 am

    http://sethgodin.typepad.com/seths_blog/2011/03/the-limits-of-evidence-based-marketing.html

  • William Pietri Said,

    March 14, 2011 @ 9:47 pm

    Hi, Michael. Personally, my belief is that the main way you’ll get large Agile organizations is by starting small ones and letting them grow for a few decades.

    I hope I’m proven wrong, but I expect large companies will fail to adopt Agile approaches (other than as a gloss of bullshit) for the same reason almost all American manufacturers failed to really adopt Lean. The necessary culture and values are just too different from what they’re used to, and would threaten existing power relationships too much.

    So personally, I’m encouraging people to concentrate on all those small Agile teams that are mostly ok and make them truly excellent. Because I think that’s what it will take for them to scale enough to take major market share from companies that currently dominate more through size than through quality.

  • Michael Sahota Said,

    March 15, 2011 @ 9:36 am

    I agree with your analysis but am perhaps a bit more hopeful that something can be done to ease the pain large companies feel. Not Agile, but perhaps a cousin to Agile. Perhaps Kanban. Perhaps something else.

  • Bob Marshall Said,

    March 15, 2011 @ 4:46 pm

    A topic worthy of much more attention than the Agile community seems interested in giving it, presently. :(

    Just one gripe: “The way to change an organization is one person at a time.” If you’re acquainted with e.g. the Marshall Model at all, you might see just how wrong (and misleading) this piece of advice is. Where did it come from? “Common sense”? :{

    If we accept that the root cause of Agile failures in the large is down to conflicting mindset (teams have learned to see the world of work through a Synergistic lens, rest of organisation remains with e.g. an Analytic perspective) then I propose “the way to change an organization is with everybody at the same time.”

    - Bob (@FlowchainSensei)

  • Michael Sahota Said,

    March 15, 2011 @ 5:59 pm

    Bob, thanks for your comments. I do not mean to imply here that one approach is better – starting small vs. starting large (with a organization wide transformation). What I mean to say (regardless of approach) is that we need to win each and every person over. It’s a hearts and minds campaign. So, big or small scale, it is still one person at a time. Does this make sense?

    P.S. I have loved your twitter handle since the first time I saw it.
    P.P.S. Reading the Marshall Model now.

  • Bob Marshall Said,

    March 16, 2011 @ 8:24 am

    Michael, thanks for your clarification. I agree that we need to win over each and every person (or, sadly perhaps, let them go). But I still maintain that to shift a *collective* mindset requires taking everybody along at (more or less) the same pace. In summary, I think we’re on the same page, maybe just with different language?

    P.S. Thanks for the PS’s :)

  • Michael Sahota Said,

    March 16, 2011 @ 10:42 am

    Yup. We agree. Ain’t language wonderful? :-)

  • Still No Silver Bullets « OlafLewitz Said,

    May 11, 2011 @ 3:50 am

    [...] Michael Sahota lead a session about agile failures in the large at Play4Agile and wrote about it here, Esther’s points remind me of that discussion in multiple areas. Esther Giving Her XP2011 [...]

  • Adam Nemeth Said,

    September 26, 2011 @ 8:20 pm

    Do we have to agilize everything?

    I’m pretty much fine that someone realized that
    1) Agile isn’t always success
    2) Corporate cultures are different.

    My question:

    Is it a problem? Does everything have to be Agile?

    Let’s say I have 10 developers, who’re individual quality-maniacs. They’ll fight like it was for their lifes. But the product is awesome, both inside and out! Shall I care that my team culture is blahblahblah, not Agile? Shall I care if one of the guys don’t write unit tests,but he’s maintaining an API documentation which just simply kicks ass?

    Also, shall I care that big companies fail to adopt Agile? I mean, some companies have to take deadlines seriously for example.

    Is it a success story of Agile if the company went Agile, yet also nearly out of business? Full of unit tests, the only problem is that 3 years ago it was the market leader, using waterfall methodologies, now we’re speaking about who will buy them, with their all-agile cross-functional teams, and millions spent on agile coaches?

    Is Agile the only solution? Can’t there be values in other solutions as well?

    Does Agile scale? I mean, it’s pretty fine to have some disconnected teams walled from each other, but can a large organization consist of such teams? Couldn’t it be, that the larger a community gets, the person-to-person communication gets harder to impossible, as it’s simply way too many people to find who to talk to and who to listen to? Could it be, that such amount of people are served better with processes and documents?

  • Michael Sahota Said,

    September 26, 2011 @ 9:16 pm

    Hi Adam,

    I agree – not everything needs to be Agile. As more executives see Agile (wrongly) as a silver bullet, I seem my role as stopping them from doing Agile and help them solve their real problems (which may or may not involve Agile practices).

    It seems like you have a number of concerns about Agile and I am sorry if you have had bad experiences with it.

    I am not going to defend Agile as universally better. What I will say is that like any approach or tool it does not fit all situations or cultures. That said, I do use Agile practices to solve real business problems so in my experience it can help.

    Peace,
    Michael

  • John Quincy Said,

    November 14, 2011 @ 7:06 pm

    Agile is not sustainable, but it has to run its course. The difference with this fad is a highly effective marketing blitz by a lot of hungry consulting companies that are enjoying the perfect storm of economic downturn and ignorant CIOs. Mind you, these are not stupid CIOs, but a very high percentage were never developers or have not been developers for decades.

    Check out this hilarious video that depicts one such CIO:

    http://www.youtube.com/watch?v=nvks70PD0Rs

    John

  • Michael Sahota Said,

    November 14, 2011 @ 7:42 pm

    Hi John,

    Thanks for sharing the hilarious video. It is right on target with CIO’s trying to buy Agile like a product and thinking it is a silver bullet.

    On the whole, I disagree with your sentiment – I have used Agile to help a lot of people and teams deliver software.

    I would be interested in hearing what you suggest people do rather than Agile.

    - Michael

  • Jordan Said,

    December 5, 2011 @ 3:45 pm

    I think people should think of waterfall and agile as flour and water, and use as much of each as is appropriate — not 100% flour, not 100% water.

    There is nothing wrong with documents, and there is nothing right with ad hoc communication that is the result of the lack of documents.

    Shorter time frame traditional processes are fine as an agile substitute, and correcting the underlying problems. More information on all these topics at my blog
    Jordan

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>