By now, most people in IT and product management understand DevOps. The power of DevOps, like Agile, is that there’s no strict rule set to follow, nor is there a standard to adhere to. It’s open to interpretation and adaptation according to your own corporate, customer, product, or cultural situation.

However, corporate culture sits square in the cross hairs of what DevOps aims to improve. With this in mind, is it better to change corporate culture at the time you adopt a DevOps practice, or wait for your DevOps practice to influence cultural change organically over time? As usual, the answer is: it depends. But here are some suggestions for a smooth transition.

Who does DevOps affect?

Typically, DevOps is cited as helping unite and influence the culture and work processes of an organization’s:

One goal is to remove barriers and silos that derive from IT’s role to keep things stable, developers’ role to disrupt (through new features), and QA’s role to uncover issues early and avoid risk. These obtuse goals can put people in these groups in adversarial positions (i.e. developers taking QA’s bug findings personally, and IT blaming developers for issues in the environments they’re responsible for). Therefore, it’s important to ensure everyone learns to work together towards the same end-goals: customer satisfaction and business growth.

Expanding the culture of DevOps

However, the three groups above aren’t the only ones your DevOps practice should focus on. Arguably, it’s just as important to include your customer support staff, product management, and even executives in your DevOps practice.

The biggest reason to include support staff is so that there are no surprises when new or modified features (even removed features) are released. I’ve heard horror stories of support staff getting customer calls on a Monday because of changes that occurred over the weekend, which they had no idea was even planned. When your own staff hears about application changes from your customers first, you should improve your culture of communication as soon as possible.

As for executives, there’s immense value in understanding the hidden business impact of top-down decisions. DevOps can also help influence future executive business direction based on feedback loops from within the organization as well as actual software users and customers. A culture where executives are disconnected from what happens on the front lines hurts morale, customer satisfaction, and ultimately the business.

[Eric Bruno will present the session Bimodal IT and DevOps: Speed AND Quality or Speed VS. Quality? as part of the DevOps track during Interop ITX on Wednesday, May 17, in Las Vegas.]

The DevOps turnstile: Continuous cultural improvement

Let’s look at some specific cultural changes you should enact ahead of time or expect over time with a DevOps practice. However, regardless of whether a specific cultural change is listed as either “before” or “after” DevOps is implemented, all of them should be considered subject to continuous improvement. For example, team building to instill trust isn’t something that’s done just once; it’s a continuous process. Let’s begin with some changes to enact when you begin your DevOps journey:

Exposure to real user feedback: It’s amazing how many organizations never hear from or know who their users are. I’ve experienced this multiple times myself. Understanding firsthand that the product they support has positive impact on real people can go a long way towards improving motivation. There’s no need to wait on this one; encourage communication with users right away.

Team building: As stated previously, this helps instill trust between teams, avoids finger pointing, and helps to align individual motivation. Teams that connect on a personal level tend to work more as a unit. This culture of cooperation will strengthen as everyone sees the benefits.

Create channels of collaboration: This goes beyond installing instant messaging or other real-time collaboration tools. It starts with team building and continues with cross-functional team meetings, and the encouragement of unofficial meetings and gatherings. Instead of working to silence disagreements or frustrations, help teams constructively voice their concerns or criticisms. Proper coaching can help teams grow stronger together even when they disagree at times, have differences of opinion, or get frustrated with one another.

Sharing roles: Have developers take part in IT staff procedures, such as software deployment and system monitoring. Additionally, include IT in software development sprint planning to provide feedback into software design and feature development. After all, both groups have valuable insight into system behavior, but from different points of view. The cross pollination eliminates bottlenecks, and helps people feel more valuable to the overall process.

The following cultural changes are best influenced over time, aftera DevOps practice is in place:

Design for testability: Including QA in sprints helps to build software for testability—even though the main goal is to meet customer needs—because a system that’s testable tends to be of higher quality. In fact, I once worked in a group that required a test plan along with each story. After all, if you don’t know how you’re going to test a new feature, how do you know you’re building it right? This culture of QA goes a long way towards increasing customer satisfaction through quality.

Create a culture of autonomy and mastery: In this change (https://devops.com/10-top-tips-devops-cultural-change/), each contributor has fewer dependencies on others to achieve personal and organizational success. In turn, each team member feels empowered to make a bigger difference. This is definitely a cultural change that takes time to develop and refine, especially since it varies by individual. The rewards are many, for both the team members and the organization, as this approach builds both confidence and velocity.

Reduced fear of failure: This is another cultural change that will take time in most organizations, and it’s best to build confidence in your DevOps practices before expecting everyone to feel comfortable with failure. Of course, failure is never the actual goal. However, in a true lean, agile organization, failure is encouraged early in order to make corrections sooner rather than later.

Encourage knowledge and skill sharing: It takes time to expect people to grow comfortable enough to share their knowledge and skills, and in effect level the playing field by losing what they feel makes them uniquely valuable. However, as a successful DevOps practice eliminates bottlenecks, no one will want to be identified as a bottleneck themselves due to lack of transparency. As team members witness first-hand the benefits of sharing and transparency, they’ll open up more and more, making themselves more valuable in the process.

Continuous maturity

As your organization matures along with its DevOps practice, you should see positive cultural improvements as a natural offshoot; it’s best not to force it. And although the goal is to better serve your users while growing the business, there’s no reason not to enjoy the process while doing it.