How to Make Your Culture Work with Agile, Kanban & Software Craftsmanship

Michael Sahota, https://agilitrix.com/

Introduction

Culture is an often ignored, misunderstood and yet a key dynamic in company performance. In this article we will introduce a model of culture that is simple to understand and apply. The model will be used to show that Agile, Kanban and Software Craftsmanship have strong cultural biases that limit the scope of their applicability. Finally, an approach will be outlined to select approaches that work with the culture in your organization.

Culture is the #1 Challenge with Agile Adoption

The results of the 2010 VersionOne's State of Agile Development Survey [1] are astonishing. The #1 barrier to further Agile adoption at companies is cultural change. To further underscore the importance, this problem is reported by 51% of respondents. Even this number may be understated because cultural impacts are challenging to identify.

So, how important is company culture? Edgar Schein, a professor at MIT Sloan School of Management, says "If you do not manage culture, it manages you, and you may not even be aware of the extent to which this is happening."

Agile is not a Process - it Defines a Culture

But what does this have to do with Agile?

Well, what is Agile? The consensus definition is provided by the now 10 year-old Agile Manifesto [2]. Agile is an idea supported by as set of values and beliefs. In other words Agile defines a target culture for successful delivery of software. (More on Agile's cultural model later on in this article).

Agile is commonly described as a process or a family of processes. This is true, but a dangerous and incorrect abstraction. (Mea culpa, I have communicated this misleading message many times.) If Agile were just a process family, then we wouldn't be seeing culture as a prevalent problem.

Even worse, Agile is bought and sold as a product. Companies have problems such as too slow time to market or bad quality and want a solution. Agile benefits are touted and a project is kicked off with Agile as the solution. Dave Thomas, coined the concept of the Agile Tooth Fairy where Agile Coaches can swoop in and sprinkle magic dust on troubled projects to correct years of atrophy and neglect [3]. This is a myth: Agile is not a silver bullet.

Such thinking is not new. Tobias Mayer has written about how Scrum is much more about changing the way we think than it is a process [4, 5]. Bob Hartman has a great presentation on this topic - Doing Agile isn't the same as being Agile [6]. Mike Cottmeyer wrote a series of great posts on how companies are adopting Agile, not transforming to Agile [7].

Michael Spayd conducted a Culture Survey of Agile [8]. His landmark results not only show that Agile has a particular culture profile, but identified the key elements as Collaboration and Cultivation. (More on this in the next section.) Independently, Israel Gat was speaking about the relationship between Agile and culture inHow we do things around here in order to succeed [9]. His observation was that Agile adoption will trigger conflict due to cultural mismatches.

In summary, to be successful, we need to start thinking about Agile as a culture and not as a product or family of processes.

In the next section I will introduce a model for culture that can be used to understand culture at your company. The following sections explain the unique cultures of Agile, Kanban, and Software Craftsmanship. In the last section, I provide a playbook so that you can assess how well a particular approach fits with your company's culture.

Understanding Culture through the Schneider Model

We need to define what we mean by culture before exploring Agile further. In this section, I will introduce the Schneider Culture Model based on William Schneider's book The Reengineering Alternative: A plan for making your current culture work [10]. Although there are many different ways of thinking about corporate culture, this model has been selected since it leads to actionable plans.

What is a culture model? A culture model tells us about the values and norms within a group or company. It identifies what is important as well as how people approach work and each other. For example, one culture may value stability and order. In this case clearly defined processes will be very import and there will be a strong expectation of conformance rather than innovation and creativity.

The Schneider Culture Model define four distinct cultures:

1. Collaboration culture is about working together.
2. Control culture is about getting and keeping control.
3. Competence culture is about being the best.
4. Cultivation culture is about learning and growing with a sense of purpose.

The diagram below summarizes the Schneider Culture Model. Each of the four cultures are depicted - one in each quadrant. Each has a name, a "descriptive quote", a picture, and some words that characterize that quadrant. Please take a moment to read through the diagram and get a sense of the model and where your company fits.

Another aspect of the Schneider model is the axes that indicates the focus of an organization:

1. Horizontal axis : People Oriented (Personal) vs. Company Oriented (Impersonal)
2. Vertical axis: Reality Oriented (Actuality) vs. Possibility Oriented

This provides a way to see relationships between the cultures. For example, Control culture is more compatible with Collaboration or Competence cultures than with Cultivation culture. In fact, Cultivation culture is the opposite of Control culture; learning and growing is opposite of security and structure. Similarly, Collaboration is the opposite of Competence.

"All models are wrong, some are useful" - George Box, statistician. All models are an approximation of reality and it is important to remember that we are ignoring minor discrepancies so that we can perform analysis and have meaningful discourse. Also, we may wish to consider other models such as Spiral Dynamics [11] if we wanted to understand cultural evolution.

Key Points about Culture

In the Schneider model, no one culture type is considered better than another. Please refer to the book for details the strengths and weaknesses of each. 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 (e.g. development vs. operations) may have different cultures. Differences can lead to conflict.

Agile Culture is about Collaboration and Cultivation

As mentioned earlier, 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. The results suggest that Agile is all about the people. Interestingly, the survey included Scrum, XP, as well as Lean-Kanban folks.

The Agile Manifesto and Principles Define Agile Culture

The Agile Manifesto and twelve principles - even after ten years - are still the reference for what is considered Agile. Consider the following diagram, where the values and principles are mapped to the Schneider model.

It can be seen that there is high density of values and practices that are aligned with Collaboration and Cultivation. Note that there were no elements related to Control culture and only one related to Competence culture. This is strikingly similar to the result obtained by Michael Spayd in his survey of Agilistas.

Analysis Approach (For the Curious)

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 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.

These results have been partially validated through group workshops where participants performed the same activity after having an explanation of the culture model. [12]

Culture Model Lets Us Ask Useful Questions

Agile is about people. OK, not such a startling conclusion. Seems we all know that. What is interesting is that when we start thinking about Agile as a specific culture we can now use this for asking interesting questions:

• What is the culture in my company now?
• How well is the culture aligned with Agile?
• What problems can I expect due to misalignment?

More on this in the section Working with your Culture below.

Kanban Culture is Aligned with Control

I am choosing an insightful post by David Anderson - The Principles of the Kanban Method [13] as the basis for my analysis. David is arguably the main leader of the Kanban/Software school with his book, very active mailing list and Lean Software and Systems Consortium.

As with the Agile manifesto, I have taken the Kanban principles and aligned them with the Schneider culture model. As can be seen in the following diagram, Kanban is largely aligned with Control culture.

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 does well. Control cultures focus on the company/system (vs. people) and current state (vs. future state). This is a good description for the starting place used with 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 Burrows made a very influential post [14] where 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 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 can be important in Kanban too, but this is secondary to the system. See CrystalBan [15] for ideas of how to integrate people into Kanban.

So is Kanban Agile? I used to think so. I don't any more. I can see now how the belief - that Kanban is Agile - is harmful since the cultural biases are different.

Kanban is a Good Tool

Sometimes when I share this analysis (where Kanban is linked to Control culture), I get a negative reaction since within the Agile community since Control culture is anathema. (Actually, it is anathema to knowledge work in general). To avoid any misunderstanding, I would like to clarify a few things:

1. I love Kanban and think it is great. We need more of it in the world. See my related blog post - Scrum or Kanban? Yes! [16] - where I argued that some situations are a better fit for Kanban vs.Scrum.
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 company has a Control culture, then Kanban is a good tool to help (vs. Scrum).

Software Craftsmanship as about Competence

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) [17]. This gave rise to the much needed community of Software Craftsmanship [18].

I have already established that the Agile community is focused on Collaboration and Cultivation at the expense of Competence. We as a community of software professionals do need to pay attention to Competence and technical excellence for long term sustainability. For further information on this, see Uncle Bob's recent article The Land that Scrum Forgot [19].

The diagram below relates parts of the Software Craftsmanship Manifesto to cultures identified in the Schneider model.

Not surprisingly, there is a big focus on Competence Culture. This culture achieves 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?

Why We Need to Care

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 creation and existence of a separate movement to support Competence culture that exists outside of the Agile, supports the assessment of Agile culture as focused on Collaboration and Cultivation and not Competence.

As a final footnote before departing the culture of Software Craftsmanship, I would like to reflect that the manifesto does not accurately reflect a key aspect of the movement: a deep commitment to learning and growth (Cultivation culture). This is a value that exists to support the goal of excellence in software construction.

Working with Your Culture

Consider the following diagram illustrating how Agile, Kanban, and Craftsmanship principles align with various cultures. The shapes illustrate the dominant culture for each of Agile, Kanban and Software Craftsmanship based on the analysis earlier in earlier sections.

The diagram can be used as a playbook to determine what approach builds on the culture at your company.

• Control Culture -> Lead with Kanban
• Competence Culture -> Lead with Software Craftsmanship
• Collaboration or Cultivation Culture -> Lead with aspects of Agile that align with the organizations culture. e.g. Vision and Retrospectives for Cultivation Culture.

Understanding Culture

The starting point for making culture work is to understand it. Schneider's book describes a survey you can give to staff [20]. The book suggests using survey results as a starting point for culture workshops with a diverse group of staff.

Management guru Peter Drucker says "Culture ... is singularly persistent ... In fact, changing behaviour works only if it is based on the existing 'culture'. The implication here is that it is not possible to just switch over from a Control culture to and Agile one.

A central premise of Schneider's book is that it is essential to work with the existing culture rather than oppose it. There are several suggestions for using cultural information to guide decision-making:

1. Evaluate key problems in the context of culture. Sometimes changes are needed to bring the culture into alignment with the core culture.
2. 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.
3. Consider the possibility of creating interfaces/adapters/facades to support mismatches between departments or groups.

What about Agile?

Consider the diagram below showing effective ways of working with culture

Option #1 illustrates that the easiest option is to work with the existing dominant culture (in this case Control). Option #2 is to carefully explore adjacent cultures in ways that support the core culture of the group. Choice of direction may be guided by what the secondary culture of the organization is. The idea here is to work with the culture, and not to fight it.

How to Change Culture is Another Story

Changing culture is difficult. See my series of blog posts on culture [21] for some details on how to change culture or wait for my upcoming eBook on InfoQ.

Conclusion

Congratulations! You now have the Schneider Culture Model - an easy-to-use tool for assessing culture in your company. Once you know your company's culture, you will be aware of how it is influencing many aspects of day to day work. More importantly, you can use the cultural fit model to decide what approach - Agile, Kanban, or Software Craftsmanship - will best fit with your organization.

References

[1] VersionOne, "State of Agile Development Survey", http://www.versionone.com/state_of_agile_development_survey/10/

[2] Agile Manifesto, http://agilemanifesto.org/

[3] Dave Thomas, "Dave Thomas Unplugged - Agile 2010 Keynote", http://agilitrix.com/2010/08/agile-2010-keynote-by-dave-thomas/

[4] Tobias Mayer, "The People's Scrum", http://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/

[5] Tobias Mayer, "Scrum: A New Way of Thinking", http://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/

[6] Bob Hartmann, "Doing Agile isn't the same as being Agile", http://www.slideshare.net/lazygolfer/doing-agile-isnt-the-same-as-being-agile

[7] Mike Cottmeyer, "Untangling Adoption and Transformation", http://www.leadingagile.com/2011/01/untangling-adoption-and-transformation/

[8] Michael Spayd, "Agile Culture", http://collectiveedgecoaching.com/2010/07/agile__culture/

[9] Israel Gat, "How we do things around here in order to succeed", http://www.agilitrix.com/2010/08/how-we-do-things-around-here-in-order-to-succeed/

[10] William Schneider, "The Reengineering Alternative: A plan for making your current culture work"

[11] Don Edward Beck, Christopher C. Cowan, "Spiral Dynamics : Mastering Values, Leadership, and Change"

[12] Michael Sahota - Workshop Results on Culture, http://agilitrix.com/2011/11/workshop-results-on-culture/

[13] David Anderson - The Principles of the Kanban Method, http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method/

[14] Mike Burrows, "Learning together: Kanban and the Twelve Principles of Agile Software", http://positiveincline.com/?p=727

[15] Karl Scotland, "Crystallising Kanban with Properties, Strategies and Techniques", http://availagility.co.uk/2011/08/03/crystallising-kanban-with-properties-strategies-and-techniques/

[16] Michael Sahota, "Scrum or Kanban? Yes!", http://agilitrix.com/2010/05/scrum-or-kanban-yes/

[17] Robert Martin, "Quintessence: the Fifth Element for the Agile Manifesto", http://blog.objectmentor.com/articles/2008/08/14/quintessence-the-fifth-element-for-the-agile-manifesto

[18] Manifesto for Software Craftsmanship,http://manifesto.softwarecraftsmanship.org/

[19] Robert Martin, "The Land that Scrum Forgot", http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

[20] Schneider Culture Survey,https://www.surveymonkey.com/s/VVNT5FB

[21] Michael Sahota, "Agile Culture Series Reading Guide", http://agilitrix.com/2011/04/agile-culture-series-reading-guide/

---

Related Agile Articles

Adopting an Agile Method

Creating an Agile Environment

Five Symptoms of Mechanical Agile

More Agile Knowledge

Scrum Expert

Agile Tutorials and Videos

Related Agile and Scrum Books

Coaching Agile Teams

Succeeding with Agile

---

Click here to view the complete list of archived articles

This article was originally published in the Winter 2011 issue of Methods & Tools