DevOps and Culture, part 2

This article is part 2 of DevOps and Culture. See part 1 here. In this entry I’ll discuss how we can think of culture in a systematic way and how we can change it.

Once again, we return to Edgar Schein’s view on the matter. Schein breaks down culture into three major components:

Artifacts are the “phenomena that you would see, hear, and feel when you encounter a new group with an unfamiliar culture. Artifacts include the visible products of the group, such as the architecture of its physical environment; its language; its technology and products; its artistic creations; its style, as embodied in clothing, manners of address, and emotional displays; its myths and stories told about the organization; its published lists of values; and its observable rituals and ceremonies.”

Value and attitudes have to do with how the group is created. If the solution to a problem becomes validated the group will take on these values and attitudes. The espoused beliefs are transformed into plaques and mission statements. “… They serve the normative or moral function of guiding members of the group as to how to deal with certain key situations as well as in training new members how to behave. Such beliefs and values often become embodied in an ideology or organizational philosophy, which then serves as a guide to dealing with the uncertainty of intrinsically uncontrollable or difficult events.”

Lastly, the taken-for-granted underlying Basic Assumptions occur “when a solution to a problem works repeatedly, it comes to be taken for granted. What was once a hypothesis, supported only by a hunch or a value, gradually comes to be treated as a reality. We come to believe that nature really works this way.“ For example, a taken-for-granted assumption on an agile team is that no one wants to deliver buggy code.

As you can see from the pyramidal structure of the diagram, the basic assumptions make up the bulk of the culture. They are unarticulated and one must be told when entering a new culture “we don’t do it that way.” The values and attitudes are obvious but rarely followed in all cases. What’s interesting about values and attitudes is when a leader or manager is observed to not be following them. This can create cognitive dissonance for them and those that report to them. Lastly is a small set of artifacts which are the things we make and work with.

Now that we’ve discussed a way of thinking about culture, the next question that comes is how do we change it? Before we do that, we first need to address the way most companies think of their employees.

From Lean Enterprise, “In his revolutionary work Pedagogy of the Oppressed, published in 1970, Paulo Freire describes what is still the dominant model of teaching today. In this model, students are viewed as empty “bank accounts” to be filled with knowledge by teachers—not as participants who have a say in what and how they learn.” I’ve personally witnessed this in organizations. I went to a customer’s site to train them on Git, continuous integration and continuous delivery. The managers marched in the “workers” and then before I started, they left and only returned when I was done. “This is the implication when we speak of employees as “resources” and wonder how to increase their utilization and productivity with little regard for their personal development. This kind of behavior indicates an environment in which employees exist primarily as providers of labor, not as active participants in creating value. In contrast, high-performance organizations are effective at both developing and harnessing the unique capabilities of their people.”

“Organizations with a “bank account” attitude to employees tend to treat change in a transactional way. This all too common and flawed approach involves funding a change program which is expected to “fix” the organization so it is fit for purpose. Organizational change is treated as a product—sold by consultants, paid for by leadership, and consumed by the rest of the organization as directed.

These change programs commonly focus on reorganizing teams and reporting structures, sending employees on short training courses, and rolling out tools and methodologies across the organization. These strategies usually don’t work because they are ineffective at changing people’s patterns of behavior. As Mike Rother points out in Toyota Kata, “what is decisive is not the form of the organization, but how people act and react.” This is determined primarily by the actions of leadership and management.”

If you go back to Schein’s model, look at the arrow on the left side, it shows how the typical organization approaches changing culture. It starts with training which is somehow supposed to change the underlying assumptions, which then changes the values and attitudes which then results in changing the artifacts. This approach doesn’t work. From “How to change a culture: Lessons from NUMMI” a powerful lesson reveals the “way to change culture is not first change how people think, but instead to start by changing how people behave --- what they do. Those of us trying the change our organization’s culture need to define the things we want to do, the way we want to behave, and want each other to behave, to provide them training and then to do what is necessary to reinforce those behaviors. The culture will change as a result. This is what is meant by “It’s easier to act your way to a new way of thinking than to think your way to a new way of acting.””

A key concept to come from this is that we don’t change culture, we can only change behavior. Changing culture is epiphenomenal (a side effect).

As you’ll notice on the right side the diagram there’s a down arrow which shows this process. Let’s look at a practical and more relevant example. The way to build quality into software development is to setup Azure DevOps branch policies that all pushes must be accompanied by a pull-request. Then, the team is taught the importance of quality and how to do this process. Repeat this for other software development practices such as unit tests, security scans, static code analysis, etc. However, there’s a better approach to introduce quality into your software development efforts. That approach is called the Improvement Kata.

A Kata is a term that comes from Lean and essentially means form. Think the first time you learned how to drive. You were first told the rules of the road and then secondly given an opportunity to drive a car. You had to learn the form of driving by learning by doing. You also had to fail within a controlled setting until you could drive competently. Driving is the Kata.

The Improvement Kata is a process for learning by experimenting. The Improvement Kata looks like this:

You can read more here or better yet check out Mike Rother’s book called Toyota Kata.

So now that we’ve identified a way to think about culture and a means to change behavior, let’s turn our attention back to Martec’s Law. The first thing to realize is that no organization, group or individual can keep up with the Law of Accelerating Returns as it is growing exponentially. The good news is that each agile team doesn’t need to in order to deliver value to our customers. Agile teams can’t keep up with it and customers can’t accept that rate of change anyway. What we can do is change our culture through validated learning. See here:

This diagram shows the process we’re supposed to go through each sprint in a DevOps world. In the Monitor + Learn phase we’re typically talking about using telemetry and sending it to Application Insights so that we can see how our new features are being used. We can also do things like A/B testing to help us figure out which flavor of a feature either draws customers in or pushes them away. Another thing we can do is use the Improvement Kata to not only optimize this Kata but also use this validated learning to rapidly change our culture. You heard it! Remember what Schein said at the beginning of my first blog on this subject? He said culture is “accumulated shared learning.” This is a central concept in DevOps. The only twist here is that we need to be learning and adjusting on what we learn every sprint. That’s the Kata. We need to be learning about our customers so that we can rapidly change our team culture and pivot. This doesn’t mean we shouldn’t be learning about new technologies. We should. But we should be thinking within the bounded context of our product and our customers. If we can take this approach we can not only innovate rapidly but we can also change our team culture rapidly by following the Improvement Kata.