I’m excited with all the publicity and interest in DevOps I see in different companies. Unfortunately, it also often seems misguided with too much emphasis on new technologies, tools and infrastructure. In this article I will argue that what is really needed is emphasis on culture, communication and ways of working.

Traditionally, software developers have been very isolated from people in operations. Developers have largely focused on finishing a project, after which they move on and then the software is dropped to ops for maintenance. As if this wasn’t bad enough, typically the developers' incentives have also been directly opposed.

Software developers are often measured by the amount of new features they produce. Operations people, instead, are rewarded by frequency of issues or lack of them in production. Each new feature has the potential for causing production issues, so no new features is often the best that the ops team can hope for.

Defining DevOps

DevOps was coined after it became obvious to many that it would be beneficial for both parties to collaborate. Since then the field of software development has evolved and the meaning of DevOps has changed to encompass everything that is good and awesome to quickly delivering quality software.

The State of DevOps Report has an excellent and concise definition of DevOps:

"DevOps is a set of principles aimed at building culture and processes to help teams work more efficiently and deliver better software faster."

So for a company whose core business revolves around software development, DevOps basically means applying awesome lubrication to the gears of their software factory.

Tools can’t solve culture

Unfortunately, DevOps is often considered a technical exercise. A surprisingly small part of delivering better software faster is about tools. Having an enterprise-wide Jenkins does not make your company DevOps. And buying any software that has DevOps in its name does not bring you DevOps. Don’t get me wrong, every high-level DevOps organization leverages lots of technology and automation, but their advancement is not driven technology-first.

Instead, you should aim to create and nurture practices and processes that work for you. Then you can pick tools and technologies that support those processes and practices. Unfortunately, it’s very easy to do exactly the opposite. For example, you buy an issue tracker and instead of configuring it to serve you, you force every team to adapt their practices to serve the great issue tracker.

Growing a culture with hands-on consulting

To improve a system, you have to understand it. Here is where value-stream mapping proves really helpful. You map a recently delivered software feature from idea all the way to end-users’ hands. How much did each step consume calendar-time and how much did it produce value? This will help in figuring out where to focus your efforts in improving processes and practices. If value-stream mapping is a new tool for you, there are plenty of examples to be found in lean-management literature. Value-stream mapping can be a real eye-opener for the whole organization.

To change your company’s working culture, habits, processes and practices, I would argue that you need two things. First, you need someone to lead or champion the change. Second, you need enough people around the champion to buy into and eventually own the change.

The champion needs to produce results, feelings of accomplishment, and/or improvement in order to encourage others to follow. It doesn’t matter if the champion is an external consultant or internal employee, the perfect end goal is that the so-called champion is eventually made redundant, as enough people see the value in the new way of working and continue on that path.

I believe the best way to get buy-in for change is getting your hands dirty, and leading by example. Sometimes it will be technical efforts like building a deployment pipeline or containerizing that first app. Sometimes it’s showing a can-do attitude, building bridges, and introducing the right people to each other. Just like with a basketball coach, no matter how well you talk, if the points don’t start racking up, you won’t get people to follow you.

Though I strongly believe that changing habits and culture is done starting from the bottom and moving up, the State of Devops Report and other resources emphasize the importance of support from the top management.

Measuring progress

The key objectives of DevOps transformation are speed, quality, and business agility. After putting a lot of effort into improving the ways of working, is your team or company now better at producing high-quality software faster? How do you know? It is quite common to see big agile transformations where everything seems to change but in the end you have no idea if you and your business are any better for it. This is generally a typical pitfall for top-down led transformations of any kind.

Improvements can be tracked and visualized by choosing key metrics and measuring them. Herein lies another trap, though. Vanity metrics are statistics that look spectacular on the surface but don't necessarily translate into any meaningful business results. For example, measuring how many tasks a team finishes encourages the team to split tasks into smaller and smaller tasks. This is good so long as each task still has business value.

So, what would be good measurements for your DevOps progress? Google’s DevOps Research and Assessment (DORA) is the largest academic study exploring DevOps principles and their practical application. Over 7 years, the DORA researchers tried to find the factors that differentiate high-performing DevOps teams. In the end, they narrowed the list to just four DevOps success metrics:

• Deployment frequency

• Lead time for changes

• Mean time to recovery (MTTR)

• Change failure rate

The first two can help you measure delivery speed. The latter reflects overall stability. Combined, these four key metrics for DevOps give you an objective way to assess your performance and track progress over time.

Even with the above DORA metrics, you can still end up cheating yourself. For example, you can have high deployment frequency but be unable to use it for fast business decisions if those are, for example, made by a committee that meets once a month.

Conclusion

So can you buy DevOps? Yes, to a certain extent you can. But it’s not the tools your purchases should focus on – it’s on pathfinders and champions who will encourage you to find new, improved ways of working. DevOps’s end goal is always to change the ways an organization works through countless small improvements and a-ha moments, for brilliant insights and discoveries lead to real change in a working culture, whatever your business.

Janne Sinivirta is a hands-on architect, agilist, programming language nerd, kickboxer, mountain biker, proud father of two and Principal DevOps Consultant at Polar Squad.