In my last post, I looked at how Agile Culture is about Collaboration and Cultivation.
Today, I am likely to ruffle a lot of feathers by observing that Kanban aligns well with control culture. So, if you are a consultant or coach, this is good news since Agile plays badly to companies that have a control culture. I view todays post as a refinement of my earlier post – Scrum or Kanban? Yes! – where I argued that some situations are a better fit for Kanban vs. Scrum.
What is Kanban?
I am choosing a recent and very insightful post by David Anderson – The Principles of the Kanban Method as the basis for my analysis. David is arguable the leader of the Kanban/Software school with his book, very active mailing list and Lean Software and Systems Consortium.
Kanban is mostly aligned with Control Culture
The cultural model used in the analysis below is based on the work of William Schneider. If you are not familiar with it, I suggest you check out my summary of his book. The terms I am using have a very precise meaning, so please refer to this for additional context.
As you can see the main focus is about Control. Control cultures live and breathe policies and process. Kanban has this in spades. Control culture is also about creating a clear and orderly structure for managing the company which is exactly what Kanban is about.
Control cultures focus on the company/system (vs. people) and current state (vs. future state). This is a good description for the starting place for Kanban.
What is really interesting from a cultural analysis perspective is the principle: Improve collaboratively using models and scientific method. These two concepts really don’t mix, so how can this work? According to Schneider, other cultural elements can be present as long as they support the core culture. So having some people focus is fine as long as it supports controlling the work.
The notion of evolutionary or controlled change can also be compatible with a control culture if it is used to maintain the existing organizational structure and hierarchy.
Wait a minute, Kanban is Agile, isn’t it?
Mike Burrow’s made a very influential post: Learning together: Kanban and the Twelve Principles of Agile Software. In it he argues that Kanban satisfies each of the Agile Principles. Now that I am studying this from the perspective of culture, I see that this is in fact not the case or perhaps only weakly the case.
Agile and Kanban for sure share a common community, and many practices may be cross-adopted, however, they are fundamentally promoting different perspectives. Agile is first about people and Kanban is first about the system. Yes, people are important in Kanban too, but this is secondary to the system.
So is Kanban Agile? I used to think so. I don’t any more.
This is an update to this post where I need to clarify a few things:
- I love Kanban and think it is great. We need more of it in the world.
- I am not saying people who use Kanban are control freaks or prefer command and control. What I am saying is that if your client has a control culture, then Kanban is a good thing to talk to them about (vs. Scrum).
- I am not saying Kanban is incompatible with Agile. I am saying that they are complementary perspectives.
You may be burning with curiosity about what the implications of this are. Stay tuned for upcoming posts.
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!
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.
2018 UPDATE: The post is out of date!
I do NOT recommend following what is written below …
An updated and more effective description of how to work with culture is here:
I finally had time to read The Reengineering Alternative: A plan for making your current culture work by William Schneider. If you are at all concerned about successful Agile adoption, then this is a must-read.
Before reading the book, I already had a pretty good idea about it thanks to a private seminar with Michael Spayd and a conference session by Israel Gat – How we do things around here in order to succeed. But when reading the book, I crystallized my thinking about a whole number of disparate experiences and open questions.
In this post, I will cover the key concepts of the book. Analysis and connections to Agile will follow in subsequent posts.
Schneider Culture Model
In the diagram below, there are four cultures depicted – one in each quadrant. Each has a NAME, a “short quote”, a picture, and some words the characterize that quadrant. As you read through this, you may will get a sense of where your company is.
There are also two axis that indicate where the focus or an organization is:
- Horizontal: People Oriented (Personal) vs. Company Oriented (Impersonal)
- Vertical: Reality Oriented (Actuality) vs. Possibility Oriented
This provides an a way to see relationships between the cultures. For example, Control culture is more compatible with Collaboration or Competence cultures than with Cultivation culture.
Key points about culture
- Management guru Peter Drucker says “Culture … is singularly persistent … In fact, changing behaviour works only if it is based on the existing ‘culture'”
- No one culture type is better than another. The book details the strengths and weaknesses of each so check it out if you are curious to learn more.
- Depending on the type of work, one type of culture may be a better fit.
- Companies typically have a dominant culture with aspects from other cultures. This is fine as long as those aspects serve the dominant culture.
- Different departments or groups may have different cultures. (e.g. development vs. operations)
- Differences can lead to conflict.
How to make Culture work
The starting point for making culture work is understanding it. The book describes a survey you can give to staff (Example Survey from Book in Survey Monkey – N.B. You can’t see the results). The book suggests using this as a starting point for culture workshops with a diverse group of staff.
There are several suggestions for using cultural information to guide decision-making:
- Evaluate key problems in the context of culture. Sometimes changes are needed to bring the culture into alignment with the core culture.
- Sometimes the culture is too extreme (e.g. too much cultivation without any controls – or vice versa!), and elements from other cultures are needed to bring it back into balance.
- Consider the possibility of creating creating interfaces/adapters/facades to support mismatches between departments or groups.
Well, that’s the book in a nutshell. More to follow on how this relates to Agile.
2016 – Update
About a year ago, I stopped using the Schneider culture model. Instead, I have been using the Laloux Culture Model. Why? It works better for my clients. The Laloux Model provides not just a sense of where we are, but where we might go. It helps crystallize the benefits of change.
In the last 4 years since I wrote this post, I have been exploring ways of helping organizations navigate culture change. In addition to the Laloux, model, I would invite you to check out these posts:
- Tactics, Strategy, & Culture – A Model for Thinking about Organizational Change
- Culture is the Core of Your Organization – V2
- Culture Change: Reinventing Organizations
- How to Build a Culture Bubble
We have learned so much more over the last 2 years since this and want to invite you to check out our recent calendar to see if there is a Certified Agile Leadership Training in your area:
A critical predictor of success I have seen in Agile transitions is how people define reality.
Let’s face it, if you are running Scrum well, then there will be all sorts of ugly problems that pop out of the woodwork: decaying technical infrastructure, technical debt, people struggling with new roles, people no longer able to hide behind the fog of waterfall, and conflicts between groups.
Scrum is designed to make impediments visible. Management’s role is to act on these and remove them to support the team. Usually, these problems have been around for a while.
Consider the Matrix
What does the film The Matrix have to tell us about this situation?
Neo is Seeking
Neo is not satisfied with the status quo. He knows that something is wrong but is not sure what it is.
Morpheus is the Guide
Morpheus acts as a guide. He tells Neo that everything is not as it seems. Neo must decide if how badly he wants to know the truth.
Neo must choose
Morpheus gives Neo a choice:
- Red Pill: Learn the truth about and discover how deep the rabbit hole goes.
- Blue Pill: Remain in his current reality and wake up the next morning believing whatever he wishes.
What does have to do with Agile?
- The Matrix = Organizational Reality
- Neo = Transition Sponsor
- Morpheus = Agile Coach
When a client swallows the red pill, they choose to confront the red flags and problems. Just like the recommendation from one of my favourite management books – Good to Great. In this situation, it is possible to do what Michael Spayd call Strategic Agile. This is represents the fundamental shift in behaviours and values called for by Agile. It leads to a learning organization that is on the road to joy in work and high performance.
When a client swallows the blue pill, the we are in a Tactical Agile situation. In this case, it might be possible to find some local wins with morale, teamwork and productivity. It might also lead to organizational backlash that reverts Agile. Sadly, what frequently happens is that the Agile champions and advocates who want to create a better company leave to find a place with a future.
In every transition, I have seen red pill, blue pill situations. Some of them are minor decisions. Some are major like investment in repaying technical debt and investing in improving productivity.
At one company, the top 10 contributing staff built a value stream showing that a “5 day project” actually took 9 months to complete and the $5k revenue was offset by $25k of costs. More than half of the executives (CEO, CTO, VP Sales, VP Engineering, CFO) discounted the data. It was a blue pill moment.
At another company, we talked about the science of motivation, and they took the red pill. The yearly bonus went bye-bye. On the other hand they later took the blue pill on technical debt. Can’t win ’em all.
One of the biggest problems I have seen is that the sponsor of the Agile transition is often the author of the problems. For example, the VP Engineering who was on watch when technical debt was piling up – it’s hard for him to get excited about sharing this problem with superiors and asking for patience while he fixes it.
If you are a coach, it’s your job to know where the boundaries are and help clients cross them when they are willing.
Next time you are working with someone, think about their reality and how they see the situation. Then find ways to share yours. At the end of the day, it is their choice.
Take a few minutes to watch this video clip from the movie. It’s fun and will help your brain remember this post.