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.

Best Summary

• 1 Hour Video explanation (and slides) of Culture; adoption/transformation meta-framework – If you really want to understand, I encourage you to watch the video. Don’t have time – just scan the presentation slides. Agile New England, Dec. 2011
• How to Make Your Culture Work with Agile, Kanban & Software Craftsmanship – Method and Tools Article, Dec. 2011
• eBook – In progress. Drop me a note if you want to be a reviewer.

Juicy Conclusions

Read about why it matters to you:

• Agile Fits Better in Some Company Cultures than Others – Agile is a great way of thinking about software development but that doesn’t mean it fits in with all company cultures. Ditto for Kanban.
• Agile – The Good, the Bad and the Ugly – Links cultural issues central to challenges faced with Agile Adoption and Transition. What you need to know as a change agent.

Change Agent’s Toolkit

Read this to expand your toolkit:

• A Tour of Agile Adoption and Transformation Models – Review of Agile Adoption and Transformation models. What tools people in the community are using and where they are effective.
• Ways to Make Progress with Culture Gaps – Different ways for coaches to make progress with Agile when it doesn’t fit with the culture.
• Agile – The Good, the Bad and the Ugly – See final section – “The Good”

Reading Order from Beginning to End

If you want to understand the logic in linear order, start here:

1. How to Make Your Culture Work (Schneider) – Explanation of Schneider culture model that is used as a base for the analysis and provides a framework for discourse.
2. Agile is about Collaboration and Cultivation Culture – Analysis of Agile/Scrum core values and associated culture.
3. Kanban aligns with Control Culture – Analysis of Kanban cultural bias.
4. Software Craftsmanship promotes Competence Culture – Analysis of Craftsmanship cultural bias.
5. Agile Fits Better in Some Company Cultures than Others – Juicy conclusions that points to a different way for coaches to approach and engage with clients.
6. A Tour of Agile Adoption and Transformation Models – Review of Agile Adoption and Transformation models. What tools people in the community are using and where they are effective.
7. Ways to Make Progress with Culture Gaps – Different ways for coaches to make progress with Agile when it doesn’t fit with the culture.
8. Agile – The Good, the Bad and the Ugly – Links cultural issues central to challenges faced with Agile Adoption and Transition. See also slides.

Post-Script

Here are some more bits and pieces around culture:

• DOI? Cultural Shotgun – Culture analysis of the Declaration of Interdependence
• Culture of “Good To Great” Companies and Why it Matters – Why competence matters.
• Workshop Results on Culture - Walk-through of workshop results supporting cultural claims.

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.

The Big Pitcure

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.

Work with your Culture

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:

• Control Culture? –> Lead with Kanban
• Competence Culture –> Lead with Craftsmanship
• Collaboration or Cultivation Culture –> Lead with aspects of Agile that align with the organizations culture. e.g. Vision and Retrospectives for Cultivation 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.

#2 Work with Compatible Cultures

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.

Change your Culture

OK, this is hard. Really hard. Culture is singularly persistent in organizations.

What about Visionary Leadership?

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.

Welcome back, Kotter

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.

So what?

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.

Although Agile coaching requires many skills, we get back to basics by revisiting three fundamental coaching skills: observing, listening and questioning.

As you put these three key skills into practice, you will get feedback on your performance and have the opportunity to try out improvement ideas in a safe, open and friendly environment.

Learning Objectives

• Practice listening without judgment
• Gather information more effectively
• Ask different kinds of questions to understand the real problem
• Gain fresh insights into a problem you face at work

Recipe

• Number of participants: 6 to 20 (could go to 30 with a bit of deterioration)
• Team size: work in groups of 3.
• Duration: 90 minutes (can be made shorter or longer)
• Materials: Flip chart paper and marker for each group.
• Setup: Chairs for sitting, walls for flipchart paper.
• Credits: This game was created by Michael Sahota and Portia Tung. It can be considered a variant of The Yellow Brick Road – Agile Adoption Through Peer Coaching (see below).

Process/Mechanics

Below is the core part of the Dojo – practicing skills.

We will use flipcharts and posters to support a highly interactive workshop where most of the work will be done in small groups.

(2 min ) Introduction – session objectives, activities
(2 min) Three key coaching skills (http://www.agilitrix.com/2009/08/agile-coaching-roles-notes-from-agile-2…) – tell participants that we will only focus on these three.
(5 min) Human bubblesort: participants order themselves by listening, observing and questioning skills (low to high)
(1 min) Form Triads (groups of three) with neighbours

(9 min) Build Skills poster for listening, observing and questioning

• (5 min) Each triad creates a poster to define the three skills. (Need poster, markers)
• (4 min) Triads share posters with large group; only some groups will share, not all. We will ask if anyone has something important that was missed.

(6 min) Launch triad

• Re-iterate session goals: 1) Identify Action Points 2) Practice Skills
• Individuals brainstorm up to three problems and pick one
• Explain Roles: Client, Coach, Observer
• Explain timing and structure of the practice rounds

(27 min) First Round of Practice

• 5 mins x 3 mini rounds (everyone rotates through roles)
• 5 mins sharing within triad
• 7 mins sharing with group

(27 min) Second Round of Practice

(2 min) Wrap-up

• Action point takeaways – close eyes for one minute and think of how you will use these skills in the next week.

(6 min) Slack/Buffer – for possible late start or time overrun

Facilitator Tips

• Prepare in advance flipcharts with:
  • The 3 roles
  • Timing of each mini-round
• Bring a gong or bell to let people know when to change roles. Why? People get so far down the tunnel it is hard to get them to shift gears.
• (Optional) Prepare a handout with a summary of the three skills.
• (Optional) Prepare your own poster explaining the three skills.

Sources of Inspiration

Michael attended Rachel Davies Coaching Dojo at Agile 2010 and was curious about how to build upon its subject using aspects of the Yellow Brick Road game.

Coaching Skills Dojo can be considered a variant of The Yellow Brick Road – Agile Adoption Through Peer Coaching created by Portia Tung, Pascal Van Cauwenberghe and Duncan Pierce. The inspiration for this new game is to streamline it and create a more relaxed pace than the original Yellow Brick Road game. For example, the mini-rounds are extended by five minutes and there are only two mini-rounds rather than three in the original game. As well, we have introduced a learner-led mini-workshop at the start to remind and grow peoples understanding of the three skills.

This was submitted (but not accepted) to Agile 2011 as “Over the Rainbow: Coaching success through observing, listening and questioning” and has been subsequently renamed.

Feedback from First Run at Agile Games 2011

• “It was great to bring specific focus on the skills involved in coaching: observing, listening and questioning. It is too easy to take this for granted.” – M.C.
• “Made 2 really great contacts.” – L.L.
• Rated 9.2/10 for usefulness at work.
• As facilitator, it was very moving to see participants improve their skills in such a short time.

Have you been on a software project where each release gets harder and harder? Many projects fall into the tar pit of the Design Dead Core.

Why do nearly all software projects fail to balance short term choices with long term consequences?

Through game-play you will experience how hard it is to make effective choices. Game learnings will be tied into well-known models in and beyond software such as Technical Debt, Stephen Covey’s Production Capability, and Alistair Cockburn’s theory of competing games.

Recipe

• Game Objective: Participants experience the attraction of short-term thinking and feel the long-term consequences. The game helps executives and managers understand the importance of investment in sustainable development practices. The game is intended to help them get through a Red Pill, Blue Pill moment.
• Number of participants: 6 to 50 (Has been playtested with 40 at XP Toronto User Group Meeting).
• Team size: 3 to 5 people per team.
• Duration: 90 to 110 minutes
• Materials: Game cards (can print or write by hand), pennies (15 per team), dice (two per team)
• Setup: (optional) video projector, tables for group work, whiteboard or flipchart.
• Credits: This game was created by Alistair McKinnell and Michael Sahota.

Session Timetable

1. Intro & Motivate Game [3 min]
2. Break into teams of four or five people. [2 min]
3. Setup Game [5 min]
4. Year 1 [30+ min]
5. Year 2 [20+ min]
6. Year 3 [15 min]
7. Debrief [15 min]

There is a backdrop story that motivates the game situation and is used throughout the game to provide entertainment and inject new rules.

What’s Your Choice?

Here is a photo showing the project choices available to management teams:

Game Narrative

Year One

Resources

• Sustaining Agility Game Options – PDF to print 3″ x 5″ index cards (one set per team)
• Sustaining Agility Score Sheet – Excel spreadsheet to print (one sheet per team)

Facilitation Tips

• It is useful to create memorable even stereotyped characters to help participants connect with the storyline. e.g. CEO has a Texan drawl, CFO is from NYC, Consultant is from California.
• Write Rule fragments on flipchart or whiteboard so everyone can see the rules. I suggest skipping text and just put keywords such as “Invest –>+1D6 Production Capacity”.
• If you have not played the game before, I suggest you playtest it on your own.
• It may be helpful to write up rules on flipchart in advance and then share them when it is time.

Feedback from first run (XPToronto)

• “Fantastic, Magical” – Jorgen Baker
• “Real pressures bottled up” – Alex Aitken
• “Good fun, valuable, opportunity to learn” – Tom Huras
• “Thought-provoking, Fun, Interesting” – Nick Faulkener
• “Lively, Interactive, Team-focused” – Hedi Buchner

Feedback from second run (Agile Games 2011)

• “This game relates hugely to my current work situation where we struggle daily to do thing the right way or increase our technical debt. This game can give great insight to our companies leader to make the right decisions as much as possible.” – A.F.
• “Very interesting game. I’m going to try it myself.” – A.J.
• “Good mix of presentation and game. Provided great thoughts about career goals, revenue and investing in production capability and the future.” – J.V.
• “Great, practical game about strategy and the impact of long-term choices and short-term consequences” – T.M.

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.

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.

Addendum

This is an update to this post where I need to clarify a few things:

1. I love Kanban and think it is great. We need more of it in the world.
2. 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).
3. I am not saying Kanban is incompatible with Agile. I am saying that they are complementary perspectives.

So What?

You may be burning with curiosity about what the implications of this are. Stay tuned for upcoming posts.