Recently, Agile Coach Michael Sahota has been exploring the impacts of organizational culture on Agile transformations. We caught up with Michael and asked him to answer a few questions for our readers.
InfoQ: What got you thinking about organizational culture and how it affects Agile?
Michael Sahota: One of the things that I do is sense-making and understanding. I try to make sense of my universe. So it's trying to make sense of the other things that I'm seeing in the community. Making sense of certain things that have happened and trying to understand what was going on: what was working well and what wasn't working. The real connection came when I noticed that there's a smell; like stuff is going wrong. People are experiencing failure. There have been significant Agile failures in this community and we weren't really talking about it.
InfoQ: What would you define as an Agile failure?
Michael Sahota: There's a couple of ways. You can finesse the question by having people self-referentially define. Fist of five voting: say everyone vote between zero and five. Vote on how much failure you experienced in your career transitioning companies and teams to Agile. The numbers I got at Play4Agile in Germany were mostly around twos and threes. When I reran that same question at the XP Toronto meeting, it was a little bit more favorable, maybe it's closer to about three on average, but there's also lots of twos, maybe with more fours. But there was not a lot of uniform success across the board.
So what's going with these failures, right? Is it because people don't know Agile? Is it because they don't know how to help companies with Agile? Is it because it's the wrong environment and we're just trying to push stuff that doesn't fit? So that's where I became really, really curious about what was going on. I had to unearth the problem and I was looking for a way to explain it. I've known about the Schneider Culture Model for some time, Michael Spayd had introduced it to me when I had a private seminar series with a coaching group that I was a part of.
When I read the book, it's like a penny dropped and it's like, okay, I get it. And that became a model for explaining some of the stuff that was going on with the failures in the community.
InfoQ: You referred to the Schneider Model, can you tell us a little bit about what that is?
Michael Sahota: Okay, before I get into the Schneider model, I want to say there's a caveat, which is, all models are wrong, some are useful.
In this case, I think the Schneider models are a very useful first model for explaining corporate culture. I don't think it's the ultimate model. I think there are other models that are more useful for a second deeper look at culture and how to shift it in a larger perspective. But as a first way of understanding culture and understanding the difference between Kanban, Software Craftsmanship, and Agile, it’s a very good starting point.
The Schneider model is very simple. It says there are four key types of culture. From an Agile perspective, the most common one is the collaboration culture, where we succeed by working together and it's all about the people working together as the source of success. Things like teamwork, cooperation, things like that are going on in that type of culture.
The other part of Agile culture is about growth and cultivation. About learning, about personal growth, about finding a point of view or basis where they can do great work by letting them figure out what they need to do to be successful and giving them vision and purpose in their work and letting that drive success.
The most common culture in the corporate world is a control culture. Where there are standards, there's a process, there's hierarchy, where companies succeed by getting and maintaining control.
And the final culture is competence culture. It's all about being the best. And that's the model of Software Craftsmanship. It's all about developing a notion of excellence and succeeding through talent and capability. So those are the four core models within the Schneider model. It says that typically in the company, there's a primary culture and then a secondary supporting culture.
Now, companies are not uniform. It could be that every division has its own culture. It could be even within a division there are different cultures. For example, development may be much more collaboration and creative and the operations folks may be much more about control because they have to keep the systems up and operational. You can see this cultural difference play out and create challenges between different functional groups within a company. And that's why things like DevOps have been created to help span that. It creates a larger system of concern of how do we be successful in development and be successful in managing our operational side.
InfoQ: You also mentioned in your blog post how the quadrants are laid out and how some are opposites are to each other. Can you explain how competence and collaboration are actually opposites in the model?
Michael Sahota: All right. This is kind of an interesting one. So the collaboration model is all about people succeeding by working together. The competence model, which is its opposite, is about succeeding through craftsmanship and quality and being the best. So the notion of being the best is like a personal goal. It's like, "I want to be a software craftsman". I want to be a capable quality developer or a capable quality person who generates user stories or requirements or a person who is really competent at testing, or exploratory testing, or automated testing or what kind of business to collaborate on. So that's about learning and growing as an individual and about being the best. So that's quite at odds with collaboration culture.
If we look at Scrum, it doesn't really have the notions that Extreme Programming has of competence. Extreme Programming very much tied into it lots of notions that one must be a software craftsman, one must get better at things like unit testing, test driven development, refactoring, and that's kind of why XP spawned this whole notion of software craftsmanship, because the whole Agile movement has been sort of warped by the Scrum view of the world, which is much more about collaboration and cultivation.
Although in all fairness, it's not just the fault of Scrum and the popularity of Scrum. If we actually look back at the Agile Manifesto and look at the values and principles and plot them to the Schneider quadrants we can actually see that there's a very strong bias in the Agile Manifesto principles towards collaboration and cultivation with only a token nod towards competence culture.
And that's why, I think it was in 2009, Bob Martin claimed and announced the 5th value of the Manifesto, Craftsmanship over Crap, right? So that was done in response to the fact that there's an imbalance in the Agile community that even though Agile is really about creating and shipping quality software, we often hear people talking for hours and hours and hours and no one ever mentions software. So this is kind of an indicator of the imbalance.
InfoQ: Is there a challenge based on the quadrants and their opposites? Is it even possible to have collaboration and competence?
Michael Sahota: Yes. In fact this is necessary. It could sound something like this: "We need compentent world-class people. But that's not enough. We only succeed by working together, so people who are not team players have no role here. In fact, we see collaboration, pairing, mentoring, and a learning culture as the way we cultivate world-class people." Actually, that's tying in cultivation culture too. So, it is possible, but perhaps only for teams and companies built from the ground up where this is at the core, at the foundation. You can't just take an existing organization and make it work.
InfoQ: Can an organization change its culture?
Michael Sahota: The line that I have for management consultants is that culture in large organizations can take 10 years to change. I was looking for examples in the community of companies that have amazing Agile success stories. And I thought I found one with salesforce.com. Okay, great. Looking at it closely though, they're saying, the founders viewed adopting Agile as returning them to their core values that they'd strayed from. I'm going, oh, okay? So this is not an example of how Agile can be used to transform companies. I think there are people who maintain that it can, but I haven't seen people explain that adequately.
At a conceptual level, I can see how it could be where people start to get shifts and then get more shifts. I know and I certainly believe within a team or software group, it's possible to create like a little envelope, like a protective little cocoon where within that you can grow a different culture. This is sort of like the idea that the overall organizational culture is control within the company, but you have a visionary leader that says, "well, I am going to support my group. I will shield them, I'll help the team create a barrier around them, a facade so that the rest of the organization doesn't come in and attack them". Where within this they can establish cultivation, collaboration, and competence culture and they can actually really do all the amazing things that Agile supports them to do and can get great results. And we can do that by creating a barrier around it so that the rest of the organization doesn't reject it as a foreign organism.
So I think it is possible to get a transformation of the parts. Whole transformation is like 10 years. It's very difficult for a large organization. And really, what do you need? Well, you need a sense of urgency, where everyone in the company says, "well, we've got to change what we're doing or we're gonna fail. We're going out of business. We have to make a change."
InfoQ: is it worthwhile to try and change your culture? Is there a value?
Michael Sahota: There's no alternative to changing culture. I think that Agile practices induce a culture shift and that's what creates a lot of backlash against Agile transformations. People keep saying, well, these rules are stupid. We don't want to follow them anymore and the organization says, oh yes you will. And then there's smoke, noise, and explosions. This is what has caused challenges with Agile adoptions. It's that people have been inducing culture change without being aware that that's what they're actually doing.
I refer to this as part of the unconscious incompetence model for Agile transition and change agents. It's that people are not really consciously aware of what they will see during transformation or they're adopting practices and they're not really aware of, let's say, what the culture of the organization is. In my mind, this basic understanding of culture, the Scheider model, is really mandatory for people to understand where they are today and what they're really trying to accomplish and how they want to accomplish that in a way that's safe, that doesn't involve backlashes against Agile or very bad cases of Scrumbut where people are actually put in a worse position because of the extra visibility of Scrum.
InfoQ: What role would an Agile coach play in each of these types of culture?
Michael Sahota: The role of coach or change agent is about helping companies make changes that help them get to where they want to go. Either help them improve their practices by adopting some Agile practices and doing that in a way that's safe within their culture and having them help companies find a way to fit that in harmoniously. In cases of transformation, we're making sure that companies know what they're signing up for, making sure there is strong management support at the outset, making sure that there's a sense of urgency in change.
In part it might be something like executing the Kotter model. I know there's one coach who has a set of story cards you can use for each of the eight phases of the Kotter model, where it says in Phase One you need to do this and here are all the different things you need to have happen in order to do that. So that could be one approach to supporting a transformation effort. I think that in some ways Agile coaches are getting above their pay grade, right? Like there's a lot of learning and knowledge that they need to understand how Agile works and organizational transformation is a completely other area, right? So there's the Kotter model, there are other models, like complex adaptive systems, and other ways of influencing change in organizations. In addition to all the other things that a coach needs to know Agile, facilitation, consultative skills. Organizational change is a whole other area of skills that need to be learned for those coaches that want to go after that and help companies effectively in that area.
InfoQ: Let's say you're an Agile coach, you're dropped in an organization, you know the Schneider model, and you suddenly realize that you're in a cultivation organization. How would you approach that differently, then say a collaborative organization?
Michael Sahota: If your an organization that focuses on cultivation, it means that there's some really good things in place. It means that going after or making sure that people have that sense of vision and purpose with all the team members. It's kind of like in grade one Agile projects. Make sure you have a vision and a mission and all that sort of stuff and a set of values with the team. That's a really great place to focus on and really key in on and use that as the main point of leverage for driving things and say, well, if we want to get to our vision, if we want to get to our goal, then we need to do some other things to support it, like working together, like focusing on technical practices, and things like that.
It's really about teasing out those other cultural elements that are not part of the core culture as a way of supporting the core culture. The way we can sustain our growth and sustain our learning is by, let's say, working together. Let's say pairing, as an example, could then be a way to allow people to grow at a faster rate.
InfoQ: Let's take the flipside, let's say the same coach wakes up the next morning and finds himself in a control culture.
Michael Sahota: On a control culture side, it's more about, what game are we playing? Are we playing the game of where we are just going to cherry pick a few small practices to make the current system less painful? Are we going to try to create a protective umbrella around an area and within that area grow a different cultural organization and then have an explicit practice of focusing on what things we need to create a facade or barrier or firewall around the team or group in order to function effectively?
It changes the focus of what the nature of the activities are. Because if we're doing something very different from the rest of the organization, we have to make sure that we keep in sync with them so that we don't lose them, right? So I have been in situations dealing with things like the PMO. Maybe the best thing for team to do is create a Gantt chart. From the team's point of view, it's a waste. Somebody has to waste five hours a week doing this and maintaining it. On the other hand, that five hours buys the team the space that they need where they can be really productive and work together and be a really high performing team. Then that's probably worth it to get those benefits. It's thinking about those things instead of "Well, that's a waste that we're going to fight up to the end". It's a bit pragmatic in saying look, you know what, we're in this bigger culture, we have to fit in, and this is the cost of doing that. And the price of doing that is worth the benefits that we're getting out of it.
InfoQ: You have an e-book coming up. What's it about?
Michael Sahota: I've always liked InfoQ and their publishing of e-books. Most memorable for me is Henrik Kniberg's very first book, Scrum and XP from the Trenches. It was quite memorable for me. I liked it because it's very real-life connected and it was just there, it was easy to consume, it wasn't that long, it wasn't a huge investment and it's very specific and targeted. So I had the idea of doing a book on something and not really sure what it would be. It might be just a big cat of my entire blog into something meaningful and that's kind of this vague notion that I had for the next year or two.
Then I actually had the opportunity to do this work on culture and this actually feels like a nice coherent entity. I'd actually like to be able to reach more people and put this together into a coherent story that people can read and actually use this to help guide their use of Agile in the real world. So it's a survival guide for Agile change agents and people who have been using Agile so that we can use Agile for good and not for evil. We can use it to create value either through adopting practices or transformations while not doing harm to companies. Because I've seen a lot of harm out there and I want it to stop.
About the Interviewee
Michael Sahota works as a trainer and Certified Scrum Coach at Agilitrix in Toronto to help businesses accelerate the delivery of value. With software teams, this may include introducing modern software delivery techniques such as Scrum or Kanban. He helps Product Managers collaborate with stakeholders and customers to identify innovative and valuable products through Innovation Games®. Michael is internationally recognized as an Agile thought leader through regular conference presentations and selection as a top Agile blogger. Michael's passion unleashing creativity and achieve breakthrough results through Play. In addition to a variety of games and simulations, he is also trained in StrategicPlay® with Lego® SERIOUS PLAY®.