Culture is a huge part of the DevOps approach. But unlike other aspects of the methodology, like cloud-native tools and repeatable, automated processes, culture is much harder to define—and to implement.

The idea of making major cultural changes in your team may seem like an intangible, intractable task. But creating a way of working—and a way of thinking—that supports continuous improvement is a crucial piece of the DevOps puzzle.

Being open to failing fast, learning lessons, and making small, constant changes is the foundation of the DevOps philosophy. You can automate and iterate all day long, but if your team doesn’t have the right mindset, you won’t achieve the results that a successful DevOps practice can deliver.

Luckily, there are some useful organisational models out there that can help you get started by offering a framework and goals to aim for as you start to build your culture of continuous improvement.

One mode that’s particularly appropriate for DevOps culture is the Westrum Organisational Culture Model. Let’s take a look at what it is, why it works so well for DevOps teams, and how you can apply it to your own practice.

What is the Westrum Organisational Culture Model?

During his research into job satisfaction and workplace safety, sociologist Dr Ron Westrum came up with a typology for organisational culture. This typology predicts how well information flows within an organisation, and how it is steered by its leaders.

This flow of information, Westrum posited, directly impacts both the effectiveness and the contentment of an organisation’s teams. Based on his research, Westrum identified cooperation, a willingness to welcome new ideas, and the ability to treat failures as learning opportunities as central to creating an organisational culture that engendered success.

Distinguishing three types of organisational cultures, Westrum outlined the characteristics and attitudes that demonstrate how well an organisation processes and shares information.

In a Pathological (power-oriented) organisation, there is typically a lot of fear and threat. People might see information not as something to be shared for the greater good, but as a resource to be manipulated and used for their own ends.

In a Bureaucratic (rule-oriented) organisation, information is shared more openly, but only within siloed departments. These organisations are territorial and stubborn, insisting on doing things their own way, by their own rules, with little interest in collaborating outside of their orbit.

Finally, in a Generative (performance-oriented) organisation, the focus is on shared goals, with information flowing freely and teams working together to facilitate the best performance. The objective is key and any changes that can be made to get there faster are embraced.

Defining ‘good’ information

Before you charge headlong into oversharing territory, it helps to understand what exactly we mean when we talk about the flow of information. We’ve all heard the old adage: ‘garbage in, garbage out’. And anyone working in IT (or with data in any capacity) will be well aware that not all information is valuable. So how do you decide what information is worth sharing?

According to the Westrum model, a generative culture is at its core built on the effective flow of good information, which Westrum defined as being:

• timely
• answering questions that the receiver has asked
• presented in such a way that the receiver can use it effectively

How does the Westrum model apply to DevOps?

With its emphasis on informational flow and embracing change, the Westrum Organisational Culture Model is a natural fit for DevOps teams.

Its harmonisation with DevOps has been outlined in Google’s DevOps Research and Assessment (DORA) reports, which often state that high-trust cultures that prioritise the flow of information are more likely to achieve high standards of both software delivery and organisational performance.

A generative culture, as Westrum refers to it, is built not only on shared information, but also shared responsibility; a unified front in which everyone understands their role, has visibility into processes, and takes part in tight feedback loops.

Siloes are broken down and bottlenecks are eliminated. Accessibility of information is facilitated, changes can be made quickly, and failure is accepted as a chance to constantly improve.

This kind of culture is exactly what DevOps—the merging of development and operational processes—was designed to achieve.

What does a culture of continuous improvement look like?

The Westrum model is a fitting structure for teams aiming to build a culture of continuous improvement and strengthen their DevOps practice. If you’re looking to create a continuous improvement culture, adopting this model and leaning into the mentality it promotes is a good place to start.

The Westrum model signposts a number of values that, when practised within a DevOps team, help cultivate a generative culture. These behaviours are the cultural pillars that will enable you to bake continuous improvement into everything your team does.

Here are a few Westrum model principles to implement and encourage:

Practical tips for creating a culture of continuous improvement

Creating a generative culture that enables continuous improvement can be challenging. Old habits are hard to break, making instigating cultural change a far more arduous part of DevOps adoption than implementing new tools. But if you can tackle that shift in the way your team approaches software development, the potential pay-offs are huge.

Let’s refer back to Westrum’s list of characteristics found in generative organisations for some practical steps you can take towards building a performance-orientated culture.

Characteristic: High cooperation
Action: Create cross-functional teams
Build teams that contain professionals from all areas of software delivery. These integrated teams share more information, solve problems faster, and generate a sense of shared responsibility.

Characteristic: Messengers trained
Action: Support continuous learning
Bugs need to be found and processes need to evolve—so don’t punish the people who bring issues to your attention. If a ‘messenger’ comes to you with a problem, don’t assign blame, and don’t point fingers. Instead, encourage transparency, take every opportunity to do things better, and facilitate additional training if and where it’s needed.

Characteristic: Risks are shared
Action: Encourage autonomy
Embolden every member of the team to take responsibility for the quality, availability, reliability, and security of the product; to take risks safe in the knowledge that failure is the first step to success. Make sure everyone is invested in the triumph of the entire pipeline and is encouraged to take ownership of their work. From building to maintaining a product, it should be all hands on deck; no palming the product off to the next part of the assembly line and making it someone else’s problem.

Characteristic: Bridging encouraged
Action: Remove silos
Break down silos between software development sub-teams, figuratively and physically. Get teams together in the same place, and create digital spaces for them to connect, collaborate, and openly share information both formally and casually.

Characteristic: Failure leads to inquiry
Action: Conduct post-mortems
Holding post-mortems is a great way to identify pipeline issues and provide feedback that can be actioned the next time around. To get the most value out of these post-mortems, they must be conducted in a neutral way; purely fact-finding, without any blame being assigned or negativity seeping into the process. Again, this is about creating a culture with a progressive response to failure—one in which it is safe to fail so long as you can learn from it. Encourage teams to react to failure not with fear, but with curiosity.

Characteristic: Novelty implemented
Action: Encourage experimentation
Give team members the freedom and independence to experiment with new features or ways of doing things. This is what DevOps is all about: try, test, improve, repeat. Carve out time for developers to innovate and test their ideas so that they feel they always have space to do so, and their tinkering time doesn’t get overrun with other work.

Build a Culture of Continuous Improvement with RiverSafe

Our DevOps consulting services have been designed to match where you are at in your DevOps journey. From just starting out, to a fully integrated DevOps practice, our experts can help you to improve the efficiency of your software delivery process. We work closely with you to understand your unique requirements and implement solutions, tools and processes to deploy applications quickly and securely.

We’re trusted by some of the world’s biggest companies to help improve the efficiency of their software delivery process through the adoption of DevOps.

Find out how we can help you get started with continuous integration, wherever you are in your DevOps journey.

Book a consultation