What's Holding Back Your DevOps Team (Besides Being Called a “DevOps Team”)

Overlooking agile development’s role in DevOps success means most enterprises will struggle to reach the highest heights of maturity.

The theory of DevOps is elegantly simple. Remove the traditional delineation between the development and operations groups to get closer to customers and to deploy more relevant features, more often. To innovate, in other words.

The reality is less so, and any organization that says it has a DevOps team has already made a fatal mistake. Spinning up a team is not the same as transforming your entire operating model to put the voice of the customer at the heart of your company strategy. And too many believe it’s just a question of tooling, overlooking the fact that without the right cultural support for DevOps in place, tools will never deliver maximum efficiency gains. Primarily, this culture is one of increased collaboration. To support this, there must be a sense of shared responsibility between development and operations teams (the famous “you build it, you run it” mindset immortalized by Amazon CTO Werner Vogels in 2006). Organizationally, there must be no silos between them, and they need to be allowed to function autonomously.

The process engine that can underpin this essential cultural development is another much experimented with, but poorly understood methodology: agile development.

Simply put, you cannot transition to a true DevOps model and culture without embracing agile practices. You can deploy as much DevOps tooling as you like, but without agile practices, you’ll simply be tinkering with the way you build the different stacks of your applications. You’ll build each layer with more automation on its way to the next checkpoint, but without removing those checkpoints completely your customers – and your developers – will ultimately see little difference.

How agile drives innovation

The traditional approach to innovation is a long and high-investment process. Product groups pitch the ideas they want to spend the next year working on and then receive a few million dollars to go and do just that. They might have regular gate reviews to re-evaluate aspects of the plan, but the goal is unlikely to change in any meaningful sense. So right away, they’re in for millions of dollars without knowing what the results might be, making the cost of failure extremely high.

This makes sense when delivering hardware – a partially built drilling rig or aircraft carrier isn’t much use – but it doesn’t make sense with software, where product features can be added and refined while the solution is in market.

Agile development reflects this by enabling the delivery of useful solutions over a shorter timeline and at a smaller investment. Instead of placing million-dollar bets with 18-month timelines, agile development allows you to place $200k bets on minimum viable products (MVPs) that can be delivered in three to six months. That way, the cost of discovering there isn’t a market for your features is much lower and teams can quickly pivot to where the demand actually is.

All of this is predicated on orchestrating people, process and technology to quickly deliver to customers working features that have value, gathering their feedback and then prioritizing development based on that feedback.

And this is where organizations that are struggling with DevOps tend to come up short.

Ineffective operating models undermine people power

Without adopting an agile operating model, it’s difficult to keep architecture, ops and engineering groups aligned, and their conflicting prioritizations will quickly derail efforts to get code out the door quickly. When set up as separate groups, these teams will always do their own thing on their own time, handing each layer off to the other in a waterfall fashion only when it’s ready.

Instead, agile’s vertically sliced teams bring together members of each organization in self-contained and self-directed groups, which can work to deliver specific features much more quickly.

Inconsistent agile adoption leads to half-baked processes

While we see plenty of organizations adopt some agile practices and much of the language, we see far fewer stay true to its principles. By following the letter of the law but missing the intent, they don’t apply the processes consistently or support them with adequate measurement or metrics.

The result is actually that more waypoints are inserted into the value stream (the number of steps between an idea and delivering a feature to the customer), meaning releases often take longer to deliver than they did before. When that happens, the team’s confidence in agile evaporates, morale plummets and customers are left empty handed.

Inadequate technology and tooling

Technology and tooling combine to present a two-fold challenge to providing an agile foundation for DevOps success. First, the codebase for your applications must be rearchitected around containers and microservices in order to enable deployment on a feature-by-feature basis. Without this, your teams can’t break down their “user stories” (an informal explanation of a feature’s objective told from the user's perspective) vertically, which is a key feature of DevOps.

When it comes to tooling, we typically see legacy change configuration management tools on the code side invariably leading to outdated change configuration management processes overall. And if you’re using outdated project management tooling then you definitely have the wrong tool suite.

The six critical success factors for agile-enabled DevOps maturity

To overcome these challenges and re-boot your DevOps strategy with agile processes at its heart, we recommend that technology leaders focus on delivering the following critical success factors.

1.     Don’t try to eat the whole elephant at once. Instead, identify a specific product to start with and then select/build one team to transform it while working to agile processes.

2.     Step up and enable agile from the top by taking the time to understand and become supportive of agile. Only with leadership’s buy-in can the voice of the customer be fed into the company’s strategic vision. Key to this is allowing technical teams to set the cadence for feature releases, by backtracking from hoped-for release dates to define the level of MVP that’s possible in the time allowed. (This will also lead to developers that are more engaged in their work and overall cultural improvements.)

3.     Conduct a value stream mapping exercise to understand how many steps it currently takes to carry an idea from inception through to the customer, and then leverage agile’s vertically sliced operating model to reduce them.

4.     Close your feedback loops by incorporating the voice of the customer at regular intervals. Timing is important since customers don’t feel heard if your timelines are too long. (The value stream mapping exercise will also help you identify where and when this feedback loop is happening – or if it’s broken.)

5.     Evaluate and baseline your DevOps and agile methodologies against best practices, and identify measurable outcomes and methods for tracking performance against these.

6.     Finally, treat transforming to a DevOps operating model as an agile exercise in itself by prioritizing continuous improvement. That means making a plan for enabling teams to learn from their performance and make the process behind every new release better than the last.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.