In light of Agile adoption failures and awareness of cultural challenges, the purpose of this post is to review current models that are applied to adopting Agile and transforming with Agile at organizations. Worthy background reading is Mike Cottmeyer’s post on Untangling Adoption and Transformation.

It is worth noting that there is no widespread agreement about how to undertake agile adoption.

A Tour of Adoption and Transformation Models

Below a number of models for Agile adoption and organizational transformation are shown.

The horizontal scale shows on the one hand techniques aimed at adopting practices while at the other we have wholesale organizational change or transformation. I am increasingly thinking that for many situations, adoption is not sufficient and transformation is required but not wanted.

Models above the line are not specific to Agile, while those below the line come from an Agile context.

What follows is a short overview of each model or approach.

Becoming Agile in an Imperfect World

Smith and Sidky’s book – Becoming Agile in an Imperfect World – provides a lot of practical advice on adopting Agile. They begin with the premise that many companies are not ready for Agile along a variety of dimensions: Tools, Culture, Project Management, Software Process and Physical Environment. They advocate becoming as Agile as possible given the current environmental limitations and most important needs. Although they recognize that Agile represents a shift in thinking, they support an incremental practices-oriented adoption. Some might characterize this as Doing Agile rather than Being Agile.

Containers, Differences and Exchanges

The CDE (Containers, Differences, Exchanges) model provides a way to understand the context of a team or group and highlights ways of effecting change. For example, a team is a very powerful container for organizing staff. So is the physical environment. Esther Derby has a good post and presentation/video on Shifting Organizational Patterns. CDE is also discussed in Succeeding with Agile (p. 221-227).

Fearless Change

Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising provides lots of great techniques and tips for adopting new ideas within an organization. The image at the right shows the different patterns (click for hi-res version). I have used these patterns and they are very helpful for adopting new ideas. I have included them on the adoption end of the scale as they are not about organizational transformation although they can support it.

Inspect and Adapt with Enterprise Transition Team

In The Enterprise and Scrum Ken Schwaber outlines his view of how to transition an organization to Scrum:

1. Create an Enterprise Transition Team – a Scrum team responsible for the transition of the organization to Scrum.
2. Apply Scrum to an enterprise backlog of transition items.
3. Inspect and adapt to success.

Although there are a number of caveats – Scrum requires a new Enterprise Culture and huge effort to execute – the book is light on specifics.

Another example of this approach is written by Schwaber, Leffingwell and Smits: A CIO’s Playbook for Adopting the Scrum Method of Achieving Software Agility.

To my knowledge, this is the most commonly applied pattern within the community.

ADAPT

ADAPT is Mike Cohn’s model for adoption of Scrum:

• Awareness that the current process is not delivering acceptable results.
• Desire to adopt Scrum as a way to address current problems.
• Ability to succeed with Scrum.
• Promotion of Scrum through sharing experiences so that we remember and others can see our successes.
• Transfer of the implications of using Scrum throughout the company.

This feels like a light-weight version of the Kotter Model (below) for organizational change so I have placed it further along the scale towards transformation. See Chapter 2 of Mike Cohn’s Succeeding with Agile or presentation for further details.

Cynefin Framework

The Cynefin is a decision-making framework that recognizes the causal differences that exist between system types and proposes new approaches to decision-making in complex social environments. Some argue that the Cynefin model (Snowden) can be used for Agile adoption. Others use it as an analysis model to create a shared understanding of the type of environment so that the most appropriate approach can be selected. For example, for complex environments, cause and effect are so closely linked that an adaptive approach to change is appropriate.

Here is a short video explanation of the Cynefin model as well as a presentation on why it matters. i.e. the case for Complex Adaptive Systems.

The implications for Agile adoption/transformation is clear – many organizational environments are complex and adoption approach needs to reflect this. In this case, we will not know what actions will lead to the desired result. We can only take one and sense the result. This state implies less clarity than one would have with an Enterprise transition backlog.

Kotter Model for Organizational Change

Truly transforming an organization requires consistent sustained energy over a long period of time. Kotter outlines the 8 steps that need to happen in sequence to establish real and lasting change. These have been observed in a variety of companies over the last 20 years:

1. Establish a Sense of Urgency
2. Forming a powerful Guiding Coalition
3. Creating a Vision
4. Communicating the Vision
5. Empowering Others to Act on the Vision
6. Planning for and Creating Short-Term Wins
7. Consolidating Improvements and Producing Still More Change
8. Institutionalizing New Approaches

The model is simple, yet powerful and challenging. For example, the criteria put forth for a sense of urgency is that “75% of management genuinely believe that the status quo is unacceptable”. Another key aspect is that it is not possible to make real progress unless each step is completed in order.

To learn more please see: short article or Leading Change book. Also, Olivier Lafontan has Card Decks for Implementing Kotter (very cool) if you are interested in using this model.

Marshall Model of Organisational Evolution

At the very extreme edge of transformation, the Marshall Model defines a paradigm for organization evolution and growth. It can be viewed as an organizational maturity model where effectiveness increases with maturity. It reminds me of Spiral Dynamics Model that posits a theory of human development.

Conclusions

There are a lot of different ideas floating around of how to adopt and transform to Agile. The models presented here, together with your client’s situation, puts you in a better place to choose a suitable model to help them find success. Perhaps even asking yourself the question “Am I adopting Agile or transforming to Agile?” may help you find a happier path or terminate a painful one.

What’s Missing?

I am sure that you (the reader) have a story to tell about an approach to Agile Adoption or Organizational Transformation through Agile. Please comment and share.

At XPDays Benelux last November, Pascal Van Cauwenberghe told me that his main focus is to stop companies from doing Agile. I didn’t get it then. I think I finally understand.

(Note: Post used to be named “Problems with Agile? Check your Culture!”)

Agile (and Kanban) from the perspective of Culture

Rather than seeing Agile as universally great (aka silver bullet), I see it as a tool or philosophy that fits better in some company cultures than others.

Consider the following diagram illustrating how Agile, Kanban, and Craftsmanship principles align with various cultures. If, for example, you are working with a competence culture, then a good starting place is to focus on software craftsmanship and help them get really good at building quality software. Similarly, Kanban for control cultures and Agile for collaboration and cultivation cultures.

For this to make any sense, it would be advisable for you to check out the four related posts on culture:

1. How to Make Your Culture Work (Schneider Model)
2. Agile is about Collaboration and Cultivation Culture
3. Kanban aligns with Control Culture
4. Software Craftsmanship promotes Competence Culture

(Seriously, go read them now. They are pretty short and have great diagrams).

Rock my World

For me this is pretty profound. Cultural analysis provides me a tool for understanding clients and helping them where they are right now.

When a client contacts me as a coach, it is because they want help. What they think they need is a better process to help them with their problems. They do not want to change their company culture – they just want results. Well, depending on their company culture Agile may fit or it may not. Perhaps this is why many of us are experiencing the Post-Chasm Agile Blues.

A lot of my clients ask for Scrum and I am actively working on helping them understand where they are and where Scrum will take them. This is part of stepping away from one-size-fits-all. Scrum isn’t a good idea for every company.  That should be obvious, but true believers may want to burn me at the stake.

What this means is that we may need to act more like a consultant than an Agile Coach. Some people have already been doing this to greater or lesser extents. A good example is David Hussman, who shares his thoughts on Coaching and Producing Value.

Empirical data that Culture is the Problem

Courtesy of VersionOne, I would like to share a snippet of the results of their 2010 Agile Survey. Thank you, VersionOne! (The image below is copyright VersionOne and is reproduced without permission).

Note that:

• The #1 problem (51%) is cultural change
• The #2 problem (40%) is resistance to change

Maybe it’s time we start paying attention to Culture!

Cargo Cult and Being Agile

There is the famous line from Ken Schwaber about 75% of companies not getting the expected benefits from Scrum that they expect. Why?

Scrum is a disruptive, transforming technology and most companies don’t want to be disrupted or have some Agile consultant tell them how they need to change their core culture to succeed. (But we don’t actually tell them, we just create lots of conflict and may even create a mess). So what is the result? Lot’s of Cargo Cult behaviour where people Do Scrum (or worse Scrum, But) without Living Scrum or Being Agile.

What do I mean by be Agile? Fortunately, some great minds in our community have written on this topic, so you can go read their stuff:

• Tobias Mayer has written about how Scrum is much more about changing the way we think than it is a process. For example, two good posts on this are The People’s Scrum and Scrum: An New Way of Thinking. I think what he is getting at is the essence of being Agile.
• Bob Hartman has a great presentation on this topic – Doing Agile isn’t the same as being Agile.
• Mike Cottmeyer wrote a series of great posts on how companies are adopting Agile, not transforming to Agile.

Post-Agile? Agile-AND?

What I am saying aligns with the concept of becoming Post-Agile. If it means using tools beyond Agile, then I am there and so are most people practicing Agile.

I like the term Agile-AND. I still like and use Agile. AND I use other tools and approaches depending on the situation.

We as a community need to get better at communicating when and where to use Agile and more importantly when not to.

The rise of anemic Scrum was noted to dismay among the Agile community and in particular by “Uncle Bob” Martin who coined the fifth Agile manifesto value of Craftsmanship over Crap(Execution). This gave rise to the much needed community of Software Craftsmanship.

Looking at an earlier post - Agile is about Collaboration and Cultivation Culture – it is clear that the Agile community was not addressing the Competence Culture. And we as a community of software professionals do need to pay attention to competence and technical excellence for long term sustainability. Uncle Bob recently wrote a good article on this topic – The Land that Scrum Forgot.

Cultural View of the Manifesto for Software Craftsmanship

The diagram below relates parts of the craftsmanship manifesto to cultures identified in the Schneider cultural model.

Not surprisingly, there is a big focus on Competence Culture. This culture is focussed achieving success by being the best. And craftsmanship is about being the best software developers possible.

The value of productive partnerships stands alone. I am curious as to what purpose this supports as it is not directly related to writing quality software. I am wondering whether:

• this exists as a bridge to the Agile community?
• is related to the strong XP practice of pairing?
• is intended to appeal to the need for mentorship?

So what?

Craftsmanship needs to exist to make sure that the technical practices promoted by XP don’t get lost in fluffy bunny Agile culture. Things like: refactor mercilessly, do the simplest thing that could possibly work, TDD, ATDD, continuous integration, continuous deployment, shared code ownership, clean code, etc.

The existence of a separate movement to support competence culture that exists outside of the Agile, supports the assessment of Agile culture as focussed on Collaboration and Cultivation.

Caveats

I think that Craftsmanship is a good thing. I also believe it is complementary to Agile.

This is post is about understanding how Craftsmanship fits with Agile and company culture.

What is Agile Culture? In an earlier post, I talked about Schneider’s model for understanding culture – How to make your culture work. (Hint: this post will make more sense if you read the earlier post.)

What do we discover about Agile culture when we apply the Schneider model? How does this inform us about approaching Agile adoption or transformation?

Michael Spayd has done the community a great service by undertaking a culture survey of Agilistas. The results are very striking: it shows that the two dominant cultures are collaboration and cultivation, with competence a distant third and control barely even on the map. So one can say clearly, Agile is all about the people. Interestingly, the survey included Scrum, XP, as well as Lean-Kanban folks. So thanks, Michael!

What does the Agile Manifesto and Principles informs us about Cultural?

I took a look at all the values and principles and plotted the ones that show a cultural bias on the following chart:

The chart illustrates  the same finding as Michael Spayd’s survey – Agile is all about the people. It is aligned with a company cultures of collaboration or cultivation.

An Explanation Please!

Some of you may be curious as to how I arrived at my result.

For each value or principle, I analyzed how well it was aligned with each of the cultures. If there was a strong affinity, I associated it with that culture. For example, Customer Collaboration was very easy since it has the word collaboration in it and identifies success through people working together.

Some items seemed to be orthogonal to culture. For example, working software, didn’t really seem to suggest one culture over another. Well, it may weakly suggest competence culture, but only a bit.

Other items were a best guess based on my current understanding. It would be great to have a workshop to see if we can come up with an even better model.

I could go through each item and argue why I placed or chose to omit it. But that’s pretty boring and wouldn’t really change the result much.

So, there you have it: Agile is about people!

So what?

Consider for a moment what happens when foreign cultural elements are injected into an organization. Well, it’s like the human body: unless the body can be fooled into accepting the foreign tissue, it will be rejected.

More on what this means for Agile adoption and transformation in upcoming posts.

Agile has crossed the chasm and things are different over here. Really different. And not so good.

It feels like we have landed at Dieppe (Canadian/British Military WW2 Failure). The bad news is that there is significant failure successfully adopting Agile. The good news is that we can recognize it and learn from it.

Technology Adoption and The Chasm

Michael Moore’s crossing the chasm introduces the notion of phases in technology adoption.

Consider the diagram below:

As a community, we have experienced a lot of success working with Innovators, Early Adpoters. Here we are working with visionaries that have a high tolerance for change and provide strong management support.

The problem is that we are now working with the Early Majority. The recent announcement of PMI certification is pretty strong evidence of entering the early majority.

So what’s the problem? “75% or organizations do not get the benefits they expect.” – Ken Schwaber. These are pragmatists. Their goals are to avoid risk and change as little as possible. They want to buy some off-the-shelf Agile so they can get the benefits, with the least effort. They have heard good things about Agile and want the Agile Tooth Fairy to come in wave a magic wand.

Agile is not an out-of-the-box solution. I don’t there will ever be one, but we can build more around Agile to change the world of work.

We all have a pretty good idea (more or less) what Agile is. The problem is that the whole product is only partly defined by our community. For example, tools that do not scale to Enterprise needs. Some level of agreement about when to use Agile and when not to. Sorry, that I can’t paint a clear picture of what the whole product looks – still figuring this out. (If you have one, let me know).

There are for sure many talented coaches who have something that approaches whole product thinking. We need to do better communicating and growing our ideas around this or we will fail as a community.

External Related Blog Posts

• Agile’s Second Chasm (and how we fell in)
• Agile is Here to Stay… Now What?
• Agile @ 10 Years – Elephants in the Room

Epilog (Apr. 12, 2011)

I am thinking more and more that Agile is so tightly bundled with modern management culture that this is less about the whole product and more about organization evolution.

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)

At XPDays Benelux I was fortunate to accidentally attended Agile Community Vision with StrategicPlay by Olaf Lewitz and Yves Hanoulle. If you are curious how you can use Lego to achieve strategic results, read on.

Ideal Team Member

One of the exercises was for each participant to build an identical turtle from a kit using instructions. We were told that the turtle represented an ideal member of a team and ask to add one part that represented what we thought was important. In my case, I picked a flower (see photo on right). For me the flower stands for individualism that is needed to have a strong team. I am sad I did not video record my explanation or take notes since I can’t re-access the profound insight I had when created my model.

You can also see all the turtles that the group created in the photo below. Even though some us picked the same Lego piece to add, the location and narration of the meanings were quite different. So, in this case you really need to hear the debrief to understand the meaning.

Agile Community Vision

The next exercise was for each of us to build our vision of the Agile Community using a large collection of Lego without talking. After building, we took turns debriefing. You can see the different models that people created below. Mine is the one in the foreground with a tall antenna and bridges to other communities. As I went through the exercise, I found that I was learning things about myself. This can be a very revealing exercise.

Check out a very short video where I explain my model.

Shared Agile Community Vision

In the next exercise we built a shared vision that incorporated ideas from the individually created models. As we did this we clarified and enriched our metaphors. It was a very interesting social/team exercise to work through the ideas.

There was only one rule to guide us: everyone had to feel comfortable with the model. If there was a part that did not work for them, we were to remove it.

Here is a short video where we took turns explaining parts of the model:

Martin Fowler is among other things the Chief Scientist for ThoughtWorks. He gave an interesting keynote that consisted of 3 mini-talks. I thought it was very effective since it was accessible to those new to Agile as well as interesting for folks like me.

Here are my notes containing the juicy bits:

One problem Agile suffers from is Semantic Diffusion where the meaning of Agile is getting diluted. As we grow, there is increased miscommunication and less understanding. I see this struggle on mailing lists where well-intentioned people sometimes mis-explain things.

Martin then made the case that Agile requires Evolutionary Design. It goes like this: requirements change, so you need adaptive planning and hence evolutionary design. Play the Marshmallow Challenge to experience how this can work.

The next topic (middle of diagram) was about people. He touched on Taylor’s anti-pattern of process-centric view where people are replaceable parts and contrasted this with the research of Alistair Cockburn who classified people as non-linear and variable. Martin suggests that each team must own it’s process and evolution. Not sure how he reconciles this with the enterprise view.

The final topic was on code branching strategies and how continuous integration is the best of all strategies. Heed his call or suffer the despair of code decay in your feature branches.

If you want to get a more in-depth report, check out John Tobin’s blog post or Piergiuliano Bossi’s very detailed post.

Slides? Not sure. If we do get them, the will be linked from the conference website.

For those of you who follow the Agile Games Google group, you may already be aware of my proposal to create a Serious Games Stage at Agile 2011. The initial title concept was Agile Game stage, but then based on feedback from the list, I read about Serious Games and realized that this title fits the bill.

This week I finally get to learn a ton of useful information at Luke Hohmann’s Innovation Games® for Consultants class. So when we got a chance to do Product Box, I picked the Serious Games Stage as my product.  Below are photos of the product box I created as well as a lightning talk (video) where I sell it (You may want to up the resolution to 720p when viewing).

I have also posted a proposal for the Serious Games stage.

2 minute Lightning Talk

The Product Box

Agile requires a lot of skills. Agile Coaching demands even more.

Each individual coach has specific talents, capabilities and passions. Similarly, superheroes have their special powers, areas of strength and weaknesses.

Sure the Thing can break down a door, but Mr. Fantastic can slip his arm under and open it without damage or noise. Of course, if “It’s clobberin’ time!” then maybe the Thing is the right superhero for that situation.

Superheroes work in challenging environments and often succeed by working with a team that has complementary talents. The same is true for Agile coaches – we can achieve more in a team with other coaches.

In this post, I want to touch on the skills needed for Agile coaching and how this relates to learning and working in coaching teams.

Skills needed for Agile

The Agile Skills Project is the best reference that I know of. It breaks Agile skills into 7 competence areas: Business Value, Collaboration, Confidence, Product, Self Improvement, Supportive Culture, Technical Excellence. Each competence area has lots of definition (see MindMap). Phew! There’s a lot to know.

I just finished my self-assessment (see below) and probably the biggest challenge for me is around how to rate myself around areas for which I am an expert, however, not currently practising (in last 30 days). So if you want to be strict, just shrink the figure – shape won’t change much.

Overall, I am not 100% happy with this model. On the other hand there is not better.

Agile Skills for Coaches

Agile coaches are a mix of consultant, trainer, and coach. I do not know of a list of skills, so I’ll take a stab at it below. The astute reader will be aware that each of these is a profession in its own right.

Consultant

• Systems Thinking
• Root cause analysis
• Client relationship management
• Consultative Selling
• Organizational Change Management
• Navigating politics

Trainer

• Participatory training – including Agile Games, Training from the back of the room
• Speaking skills
• Presentation software such as PowerPoint. Including graphics/photos/diagrams
• Lesson and content preparation

Coach

• Listening
• Effective Questions
• Giving feedback
• Group collaboration

• Retrospectives
• Personality models such as Myers Briggs
• Psychology models such as NLP (NeuroLingusticProgramming)

To quote Socrates – “The more you know, the more you realize you know nothing.”

Every Agile coach will have some areas of skills that they have capability and vast areas with limited skills. This is why it is best to work in teams. As well, all the usual reasons for pairing apply here too.

Coaching Circle – the Fantastic Four

Gerry Kirk created a coaching circle for some of us in Ontario to meet online weekly to share ideas, provide support, debug situations and learn together. Other participants are Declan Whelan and Jason Little (photo from Agile Coach Camp Waterloo). For me the sessions have highlighted that we come from different backgrounds and have different skills and interests. When working together, it is these very differences that add value and allow the sum to be much greater than the parts.

Gerry ran an open space workshop on this at Scrum Gathering in Orlando if you would like to learn more - Agile Coaching Circles aka How to avoid feeling isolated and unsupported as a coach [Open Space]

Post Script: Selena Delesie and Susan Davis recently joined the coaching circle. Bye bye, Fantastic Four. Hello, X-Men.

Pair Coaching and Coaching Teams

In 2009, I had the fortune of pair-training with Yves Hanoulle at Agile Tour Toronto. He introduced me to the concept of PairCoaching for which I am very grateful as it has profoundly influenced how I work. (For example, I had two pair-authored sessions at Agile 2010).

Earlier this year, I was on a coaching team with Alistair McKinnell and Jason Little. I learned a lot see different skills sets in action. Alistair is a world-class technical architect, consummate consultant and above all test-infected. Although he can do much more than this, he is a great technical coach -someone to sit with developers and testers to get in the trenches and show people how to do quality work. Although Jason knows some technical practices and has worked with Agile Management, he worked with team process (Scrum, Kanban) as well as team dynamics. Me? I love getting people to work together. On this engagement, I worked mostly at the team level and the organizational/inter-departmental level. We did a lot of pairing and the quality of our work was way higher.

I know some XP Coaches who think that all Agile coaches need to be developers in order to assist the team in technical practices. For me, it is more important that all relevant skills are manifested in a coaching team and not in a given coach.

So be a superhero and work in a coaching team. If you are a coach, work this in to your engagement model. If you are a client, ask for this and join the team as internal coach – you are welcome for sure.