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.
Some years ago, my book of the year was, “Good to Great: Why some companies make the leap … and others don’t” by Jim Collins. It is a research-based exploration of what it takes to turn ordinary companies into great companies.
A very practical and relevant question is: how does it fit in with Agile? If we are going to the bother of undergoing a transformation, let’s at least make sure we have the right ingredients.
I make the case that an effective transformation needs to bring elements from outside of these systems in order to be great.
First, let’s consider where Good to Great principles align with cultural analysis.
The following analysis is based on the Schneider Culture Model.
We see that the clear focus is on Cultivation and Competence cultures.
Competence. Good to Great speaks of companies that seek to be the best in the world. They get the right people on the bus. And the wrong people off the bus. Hire the best and the rest will take care of itself. Companies such as Netflix have taken this to an extreme with amazing results. Built on the people is a culture of focus and discipline to be the best.
Cultivation. Good to Great companies have a vision of being the best in something and the passion to pursue it. A sustained commitment to the vision allows such companies to work relentless year by year to build towards success. There is also a strong sense of the need to develop people, perhaps in different roles.
One of the phrases I love most from the book is: “Confront the brutal facts … yet never loose faith.” The idea here is to make visible and deal with all problems – no matter how discouraging or painful – and keep faith that success will come eventually. Faith in success is the key ingredient that allows one to examine the really tough issues.
Level 5 leadership is about unassuming leaders who build great teams around them.
Agile, even XP, is completely silent on competence as an important trait in company culture. In fact, this notion is at odds with singing kumbaya and holding hands. But as Ken Schwaber said, “If you have a crappy to team, at the end of a sprint, you will get an increment of crap.” And a lot of companies I see are filled with mediocrity. So, if we really want to help build great companies, we need to stretch beyond Agile. Yup, this means firing people. “The most common failure of great managers is not firing people soon enough.”
An even more interesting notion is that the quality of a transformation is limited by the leadership. So, who’s in charge and what they want to accomplish becomes really important. To quote one CTO who wanted the benefits of Agile but was not interested in personal change: “I didn’t hire you to give me feedback on how I treat my staff.”
So, it’s a great book and helps me see the larger business context.
Please check out some of the great comments below – like how some of these companies crashed and burned after the book was written.
Here is a video primer of the Schneider Culture Model and how Agile, Software Craftsmanship and Kanban fit in. It is recorded in HD so you may want to use full screen and 720p resolution to see all the slides.
For more information, please see Agile Culture Series Reading Guide.
I was thrilled when I had a chance to turn my Agile Culture Series and conclusions into a session to run at XPToronto (my local Agile user group). Slides are below.
There were some interesting results that came up in the workshop component that I will share in upcoming posts. As well, I am thinking of doing a screencast of this so I can get my message out better.
This is your chance to hear about the Ugly harsh realities, the Bad news and the Good opportunities for Agile. In many ways this concludes the past months series on Agile Culture.
The days where we pretend that Agile is the greatest things since sliced bread and we can just drop it in to any company are over.
This is a reading guide to the series that explores corporate culture and how that has a direct impact (sometimes very negative) on efforts towards Agile adoption and transformation. It is a must-read for every Agile Change Agent. The role of Kanban is quite distinct and is discussed throughout.
Below is a quick synopsis of each post in the series on Organizational Culture, Adoption and Transformation so you it’s easy to find the most relevant content for you and start with what interests you most.
Read about why it matters to you:
Read this to expand your toolkit:
If you want to understand the logic in linear order, start here:
Here are some more bits and pieces around culture:
In an earlier post, I talked about how Agile Fits Better in Some Company Cultures than Others.
In this post, we’ll review some common strategies for handling cultural mismatches.
I almost posted this blog without a summary picture and I am glad I stopped myself. Once I made the drawing below, I saw there are two main strategies (adoption and transformation) and sub-strategies within them. This post will walk you through the options and when to use them.
This is the recommendation from Schneider’s book – How to make your Culture work: work with your culture; don’t fight it. I’ll outline some ways below.
#1 Build on Your Current Culture
The idea here is pick an approach that is compatible with the current culture of the organization.
One way I interpret the diagram on the right (see related article) is a prescription of what aspects of Agile/Lean to focus on based on company culture:
Kanban? But it’s not Agile!
Some really smart Agile folks think than Kanban is a sell-out: That it is a watered down, inferior form of Agile that doesn’t measure up. (I mostly disagree with this sentiment).
This reminds me of a story Craig Larman shared at a local user group meeting: “My favourite process is Unified Process. I do it in a very Agile way. But, I never recommend it to my clients since it is too easily interpreted as Waterfall and they won’t get the benefits. Instead I use an explicit Agile method. It’s not my preference, but I use it and it is better for my clients.” So, even if you like Scrum better, your client may thank you for helping them with Kanban.
So my view on the topic is that it doesn’t really matter which is better in some abstract sense. All that matters is what will help this client the most and make peoples lives better. See Kanban is a Gateway Drug for more thoughts on this topic.
Consider the diagram to the right. It shows that although the easiest option is to work with the existing dominant culture (in this case Control) it is possible to explore adjacent cultures since these are more aligned. Choice of direction may be guided by what the secondary non-dominant culture of the organization is. The idea here is to work with the culture, and not go against the grain.
#3 Create Adapters between Different Cultures
Another way to handle this problem of cultural mismatch is to create barriers between different cultures. The idea here is to create a firewall or facade that lets the different cultural groups function with little friction.
Israel Gat talks about creating a boundary object such as automated tests and technical debt measurements to avoid conflict between development (collaboration) and operations (control). For this, and more on ways that you can make your culture work see Israel Gat’s presentation and conference session.
Joseph Pelrine has a great video on InfoQ – Dealing with the Organizational Challenges of Agile where he talks through some models including using people as buffers (Scrum Master) to translate between internal team culture and the external culture of the team. This is an amazing video that goes into much more theoretical arguments well beyond culture, so consider watching the full one hour.
One successful pattern I have seen is for Agile teams to create Gantt charts to keep the PMO happy. In some companies, this is necessary waste. It brings no value to the organization, but it is currently required for the organization to function. Of course you could stick to your principles and refuse, however, you may find that when the organizational antibodies that attack, they are stronger than your management support. Or it’s not worth the fight at this time.
OK, this is hard. Really hard. Culture is singularly persistent in organizations.
Conventional wisdom is that innovative companies with visionary leadership can also transform to Agile. This is why you will often hear Agile coaches say that you need strong management support. But is this true?
Some people might point to the success of a company like SalesForce.com as an example of how they were able to change their culture. On the other hand, in the article Six Common Mistakes that Salesforce didn’t make, it is stated that “The leadership saw the transformation not so much as a wholly new approach, but rather a return to the firm’s core values.” So, this would then not be an example.
I vaguely recall a similar story about getting back to the original culture with Yahoo, who also did and enterprise transition to Scrum.
If you have any case studies, please feel free to share via email or comments.
No, I’m not talking about the TV show. I’m talking about the Kotter model of organizational change. It recognizes the eight stages that are seen in successful organizational change efforts.
Some coaches in the Agile community are aware of the Kotter model and a few are actively using it to help companies achieve an Agile mindset. I am not aware of any case studies where a company has undergone transformation to Agile using this model (but we don’t do a good job as a community collecting case studies so it is unclear how heavily to weight this).
So, if you are thinking about changing company culture, this is pretty much the only clear transition model available. And yes, if you are a coach, you do need to understand organizational development to do your job well. Sad, but true.
As a coach, you need to know what game you are playing. Are you helping management transform their organization or are you helping them adopt a culturally-fit approach? Hopefully, you are not rolling the dice with inspect and adapt.
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.
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.
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.
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: 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.
In The Enterprise and Scrum Ken Schwaber outlines his view of how to transition an organization to Scrum:
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 is Mike Cohn’s model for adoption of Scrum:
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.
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.
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:
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.
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.
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.
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!”)
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:
(Seriously, go read them now. They are pretty short and have great diagrams).
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.
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:
Maybe it’s time we start paying attention to Culture!
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:
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.
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!
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.
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!
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.
| Log in |
