Ways to Make Progress with Culture Gaps
Ways to Make Progress with Culture Gaps
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
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
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.
Published at DZone with permission of Michael Sahota , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.