Archive for Adoption

Stop Agile Initiatives!

Stop Agile HeadlineI am sick to death of Agile Initiatives because they usually fail. Sure there are some companies where Agile just fits, but the most common case is a culture conflict. Best fix I know is: Agile is NOT the Goal (Workshop)

The core problem is that the typical approach used to initiate Agile is inconsistent with Agile goals of empowerment and engagement.

Paul Heidema and I ran a session to explore this at Agile Open Toronto this Spring and this post is a way to share the key learnings.

This is a great workshop to run with people to help them understand different options for engaging with change.

I Caused Damage By Agile …

My mom used to say: “The road to hell is paved with good intentions”.

Here is how I and others have caused damage with Agile:

 I caused damage with Agile by...

Of course you can replace the word “Agile” with any other word such as “Lean”, or “Total Quality Management” or <Fill-in-the-blank>.

 Real Change Happens When…

We then reflected on the times when we participated and witnessed real change and found that it emerges – it’s not forced:

Real-change-happened-when

How Change Your Agile Initiative into Something Better

Real success comes from digging in deep on what is important and really valued in the organization – not just jumping on the Agile bandwagon.

Here is are practical exercise you can use to transform your Agile Initiative into something more resilient and lasting: Agile is NOT the Goal (Workshop)

Acknowledgements

We really appreciate all the folks who showed up and participated in this session. It was awesome.

Stop-Agile-Initiatives-Contributors

Leave a Comment

Agile is NOT the Goal (Workshop)

Here is how to run a one hour workshop turn your “Agile” initiative into something valuable, sustainable and open the door for real change (transformation).

This may be the most important hour in your whole change effort.

Setup: One Hour to Clarify Goals

Get the senior managers and stakeholders together for a one hour workshop to clarify the purpose of the Agile initiative you are leading or participating in or hope to undertake. Also consider including key influencers from the organization.

Remember that the higher up you go, the bigger the scope of possible change. See How to Build a Culture Bubble for why the choice participants is crucial.

Step 1: Ask Why?

Give everyone sticky notes and sharpies and ask them to brainstorm Why are we doing this Agile Initiative? Ask people to work on their own for three to five minutes before sharing as a group.

I find with senior management, I usually need to explain How to go Fast with Sticky Notes. If they will not use sticky notes, then real change has little hope and focus on adopting Agile practices or use stealth Agile.

Step 2: Data collect around What, Why, How

Once they have finished writing sticky notes, then setup three flipchart pages with labels What, Why and How. Ask them to put each sticky note on the spectrum made by these three words and cluster based on matching concepts. Circle each cluster. See diagram below.

Why Agile

Explain to people that we are using this model to help clarify thinking around why we are doing this.

As you can see from the photo, I sometimes add the label Outcome to help clarify meaning of “What”.

THE TRICK: It is really important to ask WHY when brainstorming and only during playback separate the reasons into What, Why, How.

Step 3: Explain What, Why, How

Here is my explanation:

  • What/Outcome –  This is about the result: what we want want to achieve. The outcome we are looking for as an organization.
  • Why – The motivation for this undertaking. You may also see here leading indicators of success.
  • How – This is about the mechanism or means that support getting to the outcome. How we actually do things.

Note: it doesn’t really matter where things go as long as it generally makes sense to participants.

Defend the What/Outcome. It is really important that the What or outcome only contains the end result that is sought after by this group. If it has means and intermediate elements, then expect unhelpful distortions in your initiative.

Step 4: Pick most important Elements

Quality ProductUse dot voting to have them select the most important elements for this initiative.

Important: Have them vote in reverse seniority order to avoid hierarch bias. See Highest Paid Person in the Room (HIPPO) bias problem for why this is very important.

Summarize  the results to check for understanding: “So it seems like the outcome for this initiative is X and we see Y and Z helping us get there?”

Step 5: “Agile” is Not the Goal

Let them notice that Agile is gone! The outcome that they seek has nothing to do with Agile! Agile is not the goal.

Help them notice how Agile will help with the What, Why and How (if that is true).

Step 6: Replace the “Agile” Initiative with something else

Suggest officially dropping Agile as a goal and instead re-brand the initiative to focus on whatever their desired outcome was.

This will help people focus on the outcome, and not on “doing Agile”.

In a recent transformation, this turned out to be a key element in our success. Do not underestimate the value of a name and the stories we tell about ourselves. 

Being Agile & Transformation

It probably seems scary to let go of Agile as an official goal.

It turns out that this is necessary to Stop Agile from being used as a Whip or a Shield.

My experience is that the only way we can really get to an Agile mindset is to let it arrive of it’s own free will. Coercing a system as an evangelist (I have done this) guarantees limited results.

If you love something, set them free.

Comments (1)

Don’t Weaponize Agile

(Title was: Stop Using Agile as a Whip and Shield)

I hate “Agile” Initiatives because of the damage they usually cause. The problem is that when people start thinking that “Agile” is the goal they start to weaponize “Agile” and use it as a Whip or a Shield.

The Whip

WhipWe use Agile as a Whip to criticize, accuse, attack and condemn other people. We do this when we don’t like what someone is doing or saying or when they ask us to do something. It sounds like this:

  • “You are not Agile”
  • “That’s not Agile”
  • “How dare you? You can’t ask for something in the middle of a Sprint”
  • “You are supposed to self-organize – why didn’t you do this”

The Shield

ShieldWe use the shield to deflect blame or justify our actions. Here are some examples:

  • “Don’t tell us what to do – We are self-organizing”
  • “You can’t ask us why we are doing something – we are autonomous”
  • “You have to wait for the next Sprint for us to work on that. It’s the rules. Suck it up.”
  • “We have to do it that way, we are Agile”

Whips and Shields are not part of Agile

Agile is about valuing the individuals and the interactions. It is about collaboration – let’s work on this together. It is talking about how to get to working software and get results.

A healthy option is to talk about goals and how to accomplish them together – not to attack and defend with whips and shields.

See Wholehearted Manifesto for what Agile is really about for me and many others.

Help people in your environment put away the whips and shields and start having conversations about what is important.

Agile is NOT the Goal

Read more about how to avoid this by ensuring that Agile is NOT the Goal.

Leave a Comment

10 Things Executives Need to Know about Agile

Slide deck with the top 10 things executives need to know about Agile:

Here’s the list with some handy links:

  1. Agile Is Mainstream
  2. Many Benefits from Agile
  3. Agile is not a Silver Bullet
  4. Agile Fails Due to Culture
  5. Agile Differs from Most Company Cultures
  6. Most Value Comes from Mindset/Culture, not Practices
  7. Adopt Agile Practices that fit Culture (Option 1)
  8. Change Culture through Organizational Transformation (Option 2)
  9. Culture Mismatch will Slow and Ultimately Fail Your Agile Initiative
  10. Culture Eats Strategy for Breakfast

Of course, it is fine to proceed with either option – adoption or transformation – it’s about what is the best fit for the client environment and their wishes.

There are two conversations around transformation that this deck is designed to trigger/encourage:

  • What does break-through organizational culture look like?
  • What does organizational transformation look like?

My Favourite Slide in the Deck

Benefit of Practices vs Culture

Acknowledgements

I would like to thank the hundreds of people who have attended my workshops and talks over the last two years to help clarify and refine this message.

Comments (1)

Beyond the Maelstrom: Chaotic Behaviour is matter of Perspective

I created the painting below almost two years ago to reflect the pain, frustration and disconnection I felt as an Agile consultant when working with a large organization.

At the time I thought of Agile as a coherent system of energy – waves of light – illustrated by the yellow lines in the top left.

Along with other coaches, we thought the organization was chaotic or complex as defined by the Cynefin framework. The organization is illustrated by blue structure. The severe difficulty we had working with it is expressed as a swirling mess of green.

In hindsight it is clear to me that the mess of interactions was the result of the incompatible culture and thought systems between the coaches and the client organization.

I suspect the client may have had the opposite perception: that they had a coherent and understandable structure while we Agile coaches seemed chaotic.

Future success relies on understanding these differences in perspective due to culture and other dimensions.

To help others avoid pain and waste, I wrote An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture Consider reading it to learn from my failures and to avoid creating your own.

This painting was one of the candidates for the cover art.

Leave a Comment

Visual Summary of Agile Adoption and Transformation Survival Guide

After providing my 13th verbal summary of my session at Agile 2012, I realized that I did not have an infographic summarizing the session and book – An Agile Adoption and Transformation Survival Guide. So here they are.

Agile Failure & Culture

Agile Differs from Most Company Cultures

 

Adoption –> Doing Agile; Transformation –>Being Agile

Agile Adoption <—->  Transformation

There are a range of approaches – some are more appropriate for adoption vs. transformation.

 

 

Leave a Comment

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)