DevOps is about creating business impact. In her book "Accelerate," Nicole Forsgren cites four metrics with a direct correlation to organizational performance: reduced lead time, more frequent deployment cycles, lower time to recover, and fewer unsuccessful changes. Improving these metrics involves tools, processes, and culture.
In this article, I will focus on culture – specifically, on the most common cultural sticking points that companies encounter. Let’s start with the most important one: outcome.
1. With DevOps, outcome is more important than output
For many years, IT productivity has been measured by outputs. It starts with an idea, moves to defining a set of functional requirements, sets a budget and a deadline, and finally, the project is handed off to the engineering team. From this point on, success means delivering the scope on schedule and on budget. Little or no customer involvement happens before the launch date, and productivity is measured by the number of features built within a specific timeframe.
[ Are you focused on the right priorities? Read also: 3 DevOps skills IT leaders need for the next normal. ]
The result almost always ends up inflated, with some useful features and a lot of unused ones – a complex product that took more money and energy than necessary to build, and that will consume even more resources to evolve and maintain.
Measuring only output does not consider the value or impact of your work. By focusing on outcomes instead of output, you’re able to measure more meaningful results that better quantify the processes you’ve implemented.
In DevOps, lead time and short deployment cycles play a key role in the digital delivery process. The goal is to move to production more frequently and without disruption. This is possible only by breaking user stories down into smaller pieces.
To do this, you must be able to prioritize and focus on what matters most. Telemetry from a technical and business perspective is also paramount. Releasing a simple version of the product, with an embedded customer analytics strategy, will clarify top priorities to stakeholders.
Sometimes it’s most effective to tweak or A/B test an existing experience than to build a new one. The result? A smaller, simpler product that better fits your customers’ needs. Once you try this approach, it changes the way people evaluate success.
2. Build in quality through automation
As your company’s adoption of DevOps matures, you may notice a change in how people see the quality assurance process. It’s part of the development process, it’s automated, and it covers not only functional aspects of the product but also performance, security, and other non-functional requirements.
When productivity is measured solely in terms of features delivered by a specific deadline, it sends a clear message to the engineering team: Code the feature as quickly as possible; time spent on test automation is overhead.
And it’s a vicious cycle: A lot of bugs may appear during the UAT phase. To meet deadlines, the team must close bugs and work on new features, and at this point, test automation is out of the question – there’s no time to spend with code that’s not related to new functionalities. Closed bugs create new ones. New features are unstable because of the push and long hours.
Does this scenario sound familiar to you?
When teams develop a culture in which coding tests are part of the scope and automated processes move software frequently to production, they won’t go back to the old way of delivering software. But this requires an outcome-driven approach.
3. Failure happens, and that's OK
DevOps can drastically change the way people think about failure. If your company has a few dozen microservices and moving to production more often is important to your business goals, you probably need to assume that things will fail in production. That’s fine – but plan ahead for it.
The traditional development mindset is to analyze, anticipate, coordinate, and align with different areas and stakeholders about changes before production happens. In this approach, there is no room to break things. CAB (change advisory board) meetings happen every week to reduce the risk of new deployments.
I question whether these meetings have ever been effective – and I am convinced that they are not only unproductive but also damaging to how we operate today.
Unless your company uses only a handful of monolithic systems, it’s irrational to think that you can create previous alignments and mitigate all risk preemptively. It’s safer to assume that failures can happen, and if they do, the impact will be low and there is a tested plan to quickly roll back changes.
Top performers leverage techniques like feature flags, canary releases, and/or blue/green deployments to minimize impact and roll back if needed. They deploy frequently and in small batches to minimize risk. They conduct a blameless post-mortem analysis after each issue and have a process in place to incorporate the lessons learned into automated checking processes. Some companies are also effectively implementing chaos engineering, in which they intentionally introduce disruption to check their architecture’s resiliency.
In any case, I am confident that we have reached a point of no return: How many of us will miss those long, unproductive CAB meetings?
4. Cross-functional teams, not silos
Every time I talk to elite DevOps performers, they point out that there is almost no distinction between their business and their IT teams. They understand that digital is part of the business now, and so is the technology team.
The prestigious CTO of a cloud-native company based in San Francisco once told me, “DevOps doesn’t make sense anymore.” When I asked why, she explained that each “pod” (her word) was responsible for one aspect of the product, end-to-end, so each team was responsible for the business, design, customer experience, development, security, and operations aspects of the value stream. I’m not suggesting that this formula would work for every company, but it’s certainly a model to think about.
On the other hand, IT departments that are driven solely by cost efficiency and are organized around specialized silos don’t provide the speed required to stay competitive. And while this approach may work for internal systems, it certainly won’t work for customer-facing digital experiences. These companies tend to think of DevOps as some automation in the delivery process, or sometimes a team or internal division. (Full disclosure: I’m part of the group that believes that it doesn’t make sense to restrict DevOps to a team or department.)
Organizations that operate in a digital-native way realize that business and technology must share goals and act as a single team – and they don’t miss all the handoffs and friction between silos.
If you are stalled in your DevOps journey, consider whether any of the above sticking points are to blame.
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
