Today, Ola Chowning talked about culture. But, rather than just talk - she’s walking us through some real examples that revolve around scaling DevOps in an organization.
Scaling DevOps starts with teams, and we have a lot of lessons learned that remind us how culture affects organizations.
First, Chowning shares a statistic: 53% of companies report that organizational culture is at odds with values of DevOps. So what would these people change? The culture!
At least a layer of the DevOps’ culture of identity needs to be writ large across the organization. Even if you can’t do DevOps everywhere, you can adopt some level of DevOps value. Otherwise, you end up with part of the organization that’s the “cool kids” and everyone else is on the other side.
Culture is the attitudes, customs, and rules that distinguish groups of people. It’s really about social behavior. It’s not something you take a class on; it’s more about actions and reactions of individuals within a team and across the org.
Changing culture requires shifting behaviors. And that’s all about how we act and how we react.
We have individuals that are very different. Both leaders and team members have to adopt those DevOps behaviors that in turn enable DevOps values.
The Importance of Leadership Buy-In
What behaviors enable DevOps values? In an example shared by Chowning, a company was using a lot of the right tools. They were using lean, they were in the cloud. It was great.
But the team members that were manning the brick and mortar stores didn’t really see how DevOps values could help them, nor did they know how to react to them. What these teams found was that without leadership changing their behaviors, the endeavor wasn’t working. Leadership behavior didn’t support DevOps.
So let’s look again at the elements of behaviors in the image above. For this client, regarding the value of the team having authority, they found that the decisions were made up higher up the authority chain.
For example, let’s say that you decided to expense your lunch today. But your leader, through the company’s norms and unwritten rules regarding behavior, expected you to ask for permission to expense. In this case, you’re closer to the column on the left than the right. Decision making is still at the higher levels.
Once you find these elements and behaviors, you’ll know what the company needs to work on. If you share examples of empowerment and decision-making, then people can refer to those to understand what expected behaviors look like.
It was valuable to define the decision making behaviors to clearly exemplify how leaders and team members should behave. This exercise was done for all of the elements of DevOps values. It actually became a game, where people added what was good and what was bad.
How Do You Change Behavior?
First, it’s not good enough to say “this is how I expect you to act.” Chowning mentions that you have to give people the opportunity to practice. And then you have to measure.
In regards to measurement, it’s not to judge or grade. Rather, it’s a way for teams to improve their ability to practice these behaviors.
Then what does practice look like?
Within the practice sessions, first you must create a space of psychological safety. These sessions should be led by people who are certified coaches or with backgrounds in psychology. This is important, as you will be pointing out poor behaviors.
Next, recognize that there’s a psychology to human dynamics. Everyone is different. We communicate and learn differently. So focus on how behaviors are enacted in different ways.
These practice sessions should focus on two to three different behaviors and include role playing and social activities. The key is good coaching.
Good coaching results in success. Independent voices can point out how behaviors affect results and examples of how poor behavior highlight what could change.
Next, we have to measure culture.
First, measuring culture is equal to measuring behavior. We have to be able to observe the behavior. And since it’s reliant on perceptions of behavior, we need to cast a wide net to make sure all viewpoints are included.
In these practice sessions, surveys were used to get a sense of where people were on the chart.
Did their beliefs lead them closer to the right (authority, non-DevOps values) or to the left (autonomy, transparency)?
These surveys helped determine where teams needed more practice. The results weren’t used to try to get the high score. They were used to find areas where the team could focus on improvement.
Some teams even used self-directed culture sprints to help each other. They would take time out of their schedule to focus on applying DevOps behavioral techniques. This let them practice the behavior that would allow a shift in culture to the values that they were trying to promote.
For cultural transformation, identifying the desired state of cultural behaviors was key. And defining how both leaders and team members should react made the learnings real.
Eventually, the divide between the cool kids and the not-yet cool kids went away.
Having great coaching provided great results. Additionally, this process resulted in a surprise—the teams adopted these practices on their own and worked to improve. Ultimately, they took on the authority to change their own behavior because they saw the benefits of the process.
This session was summarized by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.