How to break through your DevOps bottlenecks

The beauty of DevOps is that it can eliminate the bottleneck between code commit and deploy, accelerating software delivery speed. Building and deploying products has never been faster.

Yet there is also a beastly assumption about DevOps: that it is only about "build and deploy." That's just one stage of the software delivery process, however. Unless you connect all of your teams and tools in the planning, building, and delivery of enterprise software at scale, it’s likely that you’ll only move any bottleneck upstream.

And, ironically, without an integrated end-to-end value stream, you won’t be able to see where that bottleneck is. To reduce uncertainty, you need to be able to see and trace the product journey from your customers’ lips to their computer screens.

You need an omniscient view of this value stream so you can truly measure, analyze, and optimize the flow of work. Only then can you begin sharing the beauty of DevOps with the wider business.

Here's how to avoid bottlenecks and accelerate your DevOps.

 

 

How to Build a DevOps Toolchain That Scales

Get the right metrics

While best-of-breed tools make practitioners more productive, they also create data silos. Vital collaborative information (artifacts such as product features, epics, stories, and defects) cannot flow between tools, because these systems do not naturally integrate.

Consequently, there’s no automated way to get the real-time end-to-end data required to produce meaningful reports for targeting bottlenecks. You can track technical metrics such as the number of open defects and story points delivered, which are useful for go/no-go decisions and improving a given team’s performance. But those don’t show the whole picture.

[ Special Coverage: DevOps Enterprise Summit 2018 London ]

It’s a bit like measuring a sports team based on number of hours practiced rather than how many wins it has had. Instead, it’s more powerful to measure outcomes based on four categories: cost, time, quality, and productivity.

In this way you begin to collect higher-level business-value metrics in addition to technical metrics. 

The four categories for measuring outcomes.

Since this article is about bottlenecks, I'll focus on time. Or to be more specific, I'll focus on the flow of time across all teams and stages, from customer request to delivering business value. Think of it as a relay race with a complex series of handoffs.

Delivering business value: Think of it as a relay race. 

Delivering business value: Think of it as a relay race. 

1. Understand and connect your value chain

To track the flow of time from beginning to end, you need to consider how value flows through the system and the dates associated with various milestones. For example, say you use:

  • An ITSM tool to manage and approve product/feature/fix
  • A bug-tracking tool to manage technical components and artifacts
  • A source-code management tool to build, verify, and deploy

Traceability in these tools is generally manual, and therefore problematic. For example, after a product or feature request is approved in your ITSM tool, someone has to create a new feature in your bug-tracking tool so you can track it on that side.

Not only does that administration take time, but what if the request changes? Will someone change that request in the bug tracker? If not, won’t the business still expect what's defined in the ITSM tool, while developers build something else based on old information in the bug tracker?

2. Automate traceability

To ensure that your information is always up to date across your disparate tools, you need to automate the flow of information to provide end-to-end traceability through value stream integration.

When a request is created and approved in the ITSM tool, this information automatically generates a new feature in the bug tracker—including any future change. This way everyone knows exactly what to develop and test against. From there, developers can break down the feature into epics, which can be tied to the demand right through release and deployment.

3. Create product-relevant reports

Once you have a defined value stream and have built automated connections, you can extract the data you need to measure flow time. But measuring that flow is not just about how long it takes from customer request to production; you need to know other key dates along the way, such as how long:

  • Until the product request was approved.
  • Until the product was broken down into epics.
  • Until the epics were approved and scheduled.
  • Until deployment, from development.
  • Until the product was deployed in production,

By looking at the data at each stage to see where the time lags are, you can begin to dig into potential reasons for long flow times. To do this, look at the artifacts in each tool, and access the details to build appropriate reports, such as:

  • What ID and names are associated with this particular epic?
  • What were the key dates and deadlines?
  • Were those deadlines met?
  • Was this particular deployment successful?
  • Was the deployment delivered on time?

Ultimately, it’s all about getting information to flow across the value stream and aggregating that data into a database. From there you can use your analytics tools to produce actionable reports. If a request took six months from request to development, you can look into where the holdup was.

Once you know the "where," you can begin to work on the "why." And once you know the "why" and have fixed the bottleneck, you can be confident that your DevOps team is building and deploying a product that is accurate, on time, and delivering business value.

Meet Dominica and see her presentation, "Conflicting Priorities: How to Visualize Impacts to your Workflow & Metrics" at DevOps Enterprise Summit 2018 London in June.

Topics: DevOps