Agile Failure and Culture – Agile 2012 Workshop Results

What follows are the workshop results from Agile 2012 Session “An Agile Adoption and Transformation Survival Guide”. Book, slides, and video explaining the session.

The results are based on 120 people in the interactive section (there were another 60+ observers I was unable to involve).

Confirmed Insights

  1. Failure rates are high. Success reports are 2.8 average out of 5.
  2. Control culture is dominant in the majority of companies.
  3. Agile culture is primarily about collaboration culture. Cultivation and Competence cultures and are secondary.
  4. Lot’s of companies are “doing Agile” practices, and not “being Agile” (mindset)

Agile Failure rates are high

As can be seen from the photo on the right, people have reported different levels of success with Agile. 5 means always successful and 0 means never successful. The average of the respondents is 2.8 out of 5. This is a success rate of a little less than 60%. Ouch!

Reasons for Agile Failure

The photo below shows the reasons participants encountered Agile Failure. Notice that the most common item mentioned was management understanding and support.

Control culture is dominant in the majority of companies

As we can see here, approximately 77 out of 108 participants indicated that their dominant organizational culture is Control using the Schneider model. This is a little higher than 70%. And this is at an Agile conference!

Agile is about Collaboration culture

In the workshop, participants were asked to associate Agile values and principles with the cultures of the Schneider culture model. All twelve tables agreed that the dominant culture expressed by Agile is about Collaboration.

But what of Agile’s secondary culture? Three groups identified Cultivation culture while nine groups identified Competence culture. On the surface, this would seem to invalidate my claim that Agile is about People (Collaboration and Cultivation). My understanding of this is that on the surface, terms like “working software” are interpreted as signs of Competence culture whereas “working software” is a goal that can be satisfied by any cultural approach. My conclusion is that this exercise needs more time and discussion than I allocated to avoid simply sticking principles into the closest fit culture quadrant.

Either way, we can see that there is a big gap between Agile culture and current organizational culture. This is the aha moment that causes people despair.

Below are two examples. On the left there is the association with Competence and on the right, a balance of Cultivation and Competence. Click on images to see details of values and principles identified.

Doing vs. Being Agile

Another interesting artifact to share is what participants thought were the salient differences between “Doing Agile” and “Being Agile”. See photo below. This list is the result of large group shout-out/brainstorm so consider it directional rather than a crisp definition.

Approaches to Adoption/Transformation

At the end of the session, some participants share adoption and transformation techniques that I did not include in my slides or book. These are a mix of approaches and models. Interestingly, each one also has a book.

Want More?

Please see Book, slides, and video explaining the session.

Leave a Comment

Book – An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture

I am very excited that I just published my free book - An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture on InfoQ. Agile change agents will find it valuable in helping companies succeed with Agile and avoiding failure.

About the Book

Struggling with Agile? Frustrated that people don’t really get it? Tired of fighting with organizational bureaucracy? Wondering how you could have been more successful? If so, then this book is for you!

The book provides a set of essential thinking tools for understanding Agile adoption and transformation: how they differ and what you need to know to know to avoid being another statistic in the widespread adoption failure. In particular, you will learn how to use culture to work more effectively with your organization.

It is called a survival guide since so many people have found the concepts to be invaluable in understanding their experiences when working with Agile.

This book includes:

  • Identification of causes of the widespread Agile adoption failure
  • A model for understanding Agile, Kanban, and Software Craftsmanship culture
  • An outline of key adoption and transformation approaches
  • A framework to help guide when to use these these approaches with your organization
  • Real-life case studies of what has worked and what hasn’t

Electronic Version is Free

You can get a PDF or ePub version of the book for free on InfoQ. Why free? My primary goal is to change the world of work, and by making it free I can best achieve this goal. Of course, I would be really happy if you bought multiple copies of the print edition to give to your friends and clients to help them succeed as well as support my work.

Thank You

“If I have seen further, it is by standing on the shoulders of giants.” – Isaac Newton

I would like to thank Henrik Kniberg who has contributed so much open source material to the Agile community and inspired me to write a free eBook to pay it forward. I also appreciate him taking the time to write one of the forewords.

I would like to thank the attendees of workshops with early incarnations of this material – XPToronto, SoCal Lean Kanban, Agile Tour Toronto, and Agile New England. Your comments, challenges and reflections have helped in immeasurable ways.

Thanks to all the people who read my blog posts throughout 2011 on this topic and provided valuable feedback.

A big thanks to Michael Spayd for first introducing me to the Schneider culture model and for conducting a survey of Agilistas.

For sure this work would not exist but for Mike Cottemeyer’s differentiation of adoption and transformation.

Thank you to the review team for feedback: Chris Williams, Irene Kuhn, Armond Mehrabian, Krishan Mathis, Bernie Jansen, Ed Willis, Eric Willeke, Karl Scotland, Sabine Canditt, Todd Charron, Bob Sarni. Olaf Lewitz in particular deserves distinction by providing an extraordinary quantity of valuable comments, questions and challenges.

I would like to thank those who directly contributed to this work as well as reviewing: Olivier Gourment for contributing a case study; Jeff Anderson, Olaf Lewitz, Jon Stahl, and Karl Scotland and Alexei Zheglov for sharing their challenges and alternate visions in the appendix.

I would also like to thank Alistair McKinnell, Jason Little, Declan Whelan for providing feedback on the Methods & Tools article that formed a chapter in this book and to John McFadyen and Dave Snowden for feedback on the Cynefin section.

I am very appreciative of Jurgen Appelo for taking time out of his busy schedule to write a foreword.

And of course a big shout out for my daughter Scarlett who provided original art with the jigsaw puzzle and butterfly transformation drawings.

Wow! Even a small book such as this benefits from so much help.

- Michael Sahota

 

Comments (5)

An Agile Adoption Survival Guide: Working with Culture

Hi All,

Wanted to share my latest slide deck from my presentation at the Atlanta Scrum Gathering on working with culture. About 70% the same as earlier versions.

As FYI, the book is planned for May release on InfoQ and print.

Leave a Comment

What’s the first Decision? Implementing Kanban vs Scrum

Guest post by Michael DePaoli

If your development team or manufacturing team is considering moving to using Kanban vs. Agile Scrum, one of the biggest decisions is choosing the right agile development methods for the job. Let’s discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

  1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
  2. Establish and respect WIP(work in progress) limits in the value flow
  3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams. These outcomes in turn destroy brands, ruin company reputations on Wall Street, increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability. But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice: ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

  • Your organization’s product development and sales culture,
  • The nature of the demand for service from product development,
  • The competency of your organization to plan and execute change, and
  • The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

Michael DePaoli Bio

Over his 26 years in IT, Michael DePaoli’s experienced has included serving in different
traditional roles in highly respected companies. The roles have included analyst, software
engineer, quality engineer, development manager, project manager, Director of Engineering,
VP of R&D, CTO and Consultant in companies, such as American Express, Sprint, Deloitte
Consulting, Sapient, Knowledgepoint, Adobe Systems, AOL, NetApp and VersionOne. Michael
works as an agile / lean coach and product consultant with the VersionOne services group.

Comments (2)

Agile Culture and Adoption Survival Guide – Full Video!

I am very grateful to New England Agile (and Ron Verge in particular) for videotaping my presentation. For those of you who haven’t heard me speak about culture and adoption, I believe this is a crucial message for anyone acting as an Agile change agent. Enjoy.

Agile Culture and Adoption Survival Guide from Agile New England on Vimeo.

P.S. I am actively working on an eBook for those who prefer print. Drop me an email if you want to help review it before it comes out.

P.P.S Slides are here.

Comments (1)

Agile Failure and Corporate Culture


Last week I presented Agile Culture and Adoption Survival Guide at Agile New England. My message was around needing to understand corporate culture before undertaking Agile adoption or Agile transformation. The message resonated really strongly with participant and I received many personal thanks from people afterwards. The purpose of this post is to share additional data from that session.

Agile Failure

I did a hand vote to see how much failure people had seen with Agile adoption they were involved in. See photo on the right: most of the group rated their experiences with Agile success at 3 out of 5.

The results were pretty much consistent with the other times I have  run this: about 50% failure. I guess we can call this one – Agile is heading for the trough of disillusionment. But I haven’t given up – it’s time to up our game and turn this around.

Culture at Participant Companies

 Participants were worked in small groups to discuss what was the dominant culture at their company using the Schneider Model.  The photo below shows a histogram of the dominant culture. The peak is 30 participants identifying a control culture. It is interesting to note the relatively high 16 for Competence culture (vs. previous workshops) that represents the high density of hard-core engineering companies in the Boston area.

Closing Thoughts

Maybe the 50% failure is because 50% of the companies are control culture. Probably not entirely true, but this may be a helpful meme that allows us to change our approaches and behaviours to succeed.

Comments (4)

Agile Culture and Adoption Survival Guide @Agile New England

Here is the latest version of my talk that I will give at Agile New England – minor updates and tweaks since the Agile Tour Toronto version last month.

Leave a Comment

Agile Culture and Adoption Survival Guide (Presentation)

I am very excited to share some learnings over the last 6 months on culture and transformational leadership. Here is the presentation I am giving tomorrow at Agile Tour Toronto and in Boston (@Agile New England) next month. Enjoy.

Leave a Comment

How to Incubate Transformational Leadership

Jon Stahl had an enlightening talk at Agile 2011 where he walked through his process for incubating transformational leadership to achieve an Agile mindset.

Confused about adoption vs. transformation?  Check out ways to make progress with Culture Gaps.

Agile Mindset – Do you want it?

Jon shows the following short video of IDEO design group to illustrate the Agile mindset and the type of servant leadership needed to support it.

After watching the video with executives who want Agile, he checks in with them:

  • “Is this what you really want?”
  • “Are you prepared to change your own behaviour to support this?”
  • “Are you ready to go first?”

The approach outlined here is to go big or go home. Go big means to help transform an organization or division. Go home, means that rather than help adopt a few Agile practices that may disrupt the organization, to stop work and looks for clients who really want Agile.

Leaders Go First!

The remainder of the presentation is about how leaders can go first by adopting Agile principles as a management team. Jon summarizes this as:

  • Live the values
  • Lead by example
  • Be as transparent as the teams they lead

Here are some example activities for the management team:

  • Public display of values
  • Visualize projects and plans
  • Visual management of key information: people, technology, etc
  • Daily stand-up meeting in public place
Check out the groundbreaking slides for more details:

Thank you Jon, for sharing this at Agile 2011.

Leave a Comment

Exploring Agile Community Challenges through StrategicPlay® with Lego®

 

Last weekend, a group of local Agilistas got together for BBQ, drink, and to play with Lego. Well, not just play, but StrategicPlay® – with a purpose. And wow, what a result! The outcome was some deep insights into the Agile community that we’d like to share with you.

Setting the Stage

After a brief introduction and practice with StrategicPlay® model building and sharing, everyone proposed a topic for the session by building a model and explaining it. After voting (with little wee Lego coins), the group decided on the model/topic show to the left: it contrasts the low level of connection within the Agile community and outside with other communities with the ideal/future state where there is a very powerful coherent tower of strength in the community.

Individual Visions of Agile Community Challenges

Now that the topic was establish, everyone built their own model of it and took turns explaining them. Below, for example, is an individual model. Even though it was by the same participant who created the topic, the process of listening and sharing resulted in a dramatically different model. It tells the story of seemingly growing success of Agile as a movement, but coupled with a disconnect in making a difference with much of the corporate world. The possible elephant in the room is that perhaps Agile is and always has been about innovators and early adopters.

Here is another one – showing factions arguing with each other in order to produce commercial success while the great challenge of waterfall waste is left largely unchallenged.

 A Shared Vision of Agile Community Challenges

The next challenge was for the group to work together to create a shared model that:

  • Represented the most important concept from each person’s individual model, AND
  • Everyone felt comfortable will all parts of the shared model
After a period of intense collaboration and negotiation, they created the shared model:
Some of the key take-away messages are:
  • The community consists of factions and talking heads with increasing importance on commercial success. (photo left)
  • Many customer are still trapped with bad IT.  (White man under cargo net in the middle)
  • Within the community, there is a common sense of purpose to help people reach a meaningful improvement (Green on right)
  • But there is a difficult bridge or chasm to cross to get there. Interestingly, the bridge in this model was unstable.
  • By creating rich connections and communication including transparency it is possible to illuminate the way forward (top, middle)
Watch the video. It really tells the story.

Although I only facilitated the process, I felt a strong connection with the model and ideas in it.

Credits

Credit for the model goes to : Alistair McKinnell, Jason Cheong-Kee-You, Jeff Anderson, Siraj Berhen, Todd Charron, and Sam DeBoni. Great work!

StrategicPlay® looks powerful – What can I use it for?

StrategicPlay® is great for working out solutions to complex problems. The more complex, the better.

It has a wide variety of applications from: team building and organizational change to product innovation to developing company strategy.

If you are curious to learn more about applications or the science behind why this stuff works so well, please read a more detailed description.

Comments (2)