In a recent DevOps Days keynote, Peter Coffee, VP of Strategic Research at Salesforce, spoke on transforming organizations for the digital world. He argued that the phrase ‘digital transformation’ implies the end-goal is technology adoption. But in reality, Coffee expanded, “the outcome of your transformation must be transform-ability, that you must evolve from wherever you were to a new state, in which continuous transformation is part of that new behavior.”

 The ability to transform extends to all corners of a business. Companies lean heavily on IT teams to deliver on digital transformation. And just as the apps and products they deliver help businesses continually adapt and transform, they too need to continually optimize their processes to support the business needs. As companies push agile dev teams to deliver faster and faster, how does IT foster continuous improvement? That’s where value stream mapping comes in.

What is value stream mapping for DevOps?

Evolving from the Lean movements in manufacturing and healthcare, DevOps emerged to help IT reduce waste and maximize value. DevOps practices empower teams to collaborate, giving developers visibility into each other’s work. But like any process, as teams grow and scale, DevOps, too, must grow and scale as well. To do this, DevOps follows the five lean principles:

1. Identify value
2. Map the value stream
3. Create flow
4. Establish pull
5. Seek Perfection

In order to continuously improve, teams must identify the value they provide and understand how they deliver this value. These process flows are called value streams, and they help visualize the steps and resources needed to deliver value.

Value stream maps (VSM) are visualizations that help teams identify both value and waste within processes. A VSM includes each significant step in a process and quantifies how it is (or isn’t) adding value to the customer. By focusing on value throughout the software delivery process, teams gain efficiencies by assessing bottlenecks, resourcing issues and other “waste.” 

How to map your software value stream

One challenge in improving the process of software development, or any knowledge work, is that you can’t see it. It’s easier to understand Lean practices in manufacturing, since you can actually see raw materials coming in, an assembly line transforming them, and finished products going out. 

So before we can improve our development process, we need to make it visible. The most important thing to visualize is the value stream itself. 

Even if your team is working hard, they may still struggle to deliver quality work on time. Since you cannot physically see where breakdowns in your process are happening, you need to map out each stage of your delivery process: planning, architect review, development, testing, change approval, and release.

Value Stream visualizations should go one step further than process stages. Within each process stage, invisible work is happening. For example, within the development stage, you may have frontend development and backend development workflows. We call these “process blocks.” They are parallel work types happening throughout your delivery process. Another example is manual and automated testing. Both are occurring within the testing stage, but they aren’t interdependent on each other.

Why is it important to identify process blocks? They help us more granularly assess the delivery process. To truly identify bottlenecks or process inefficiencies, you need to visualize and quantify the full process.

Estimating Time in Each Stage & Process Block

For each stage and process block of the value stream, start by documenting how many user stories are in progress and how many people are working within each.

Next, estimate how much time a user story typically spends in each process block. This estimate is called lead time and should include wait time, not just work time. In addition to estimating the full lead time of a process block, also document the active time for completing the user story. This is called the processing time, and it accounts for working time only, excluding wait times.

Lead time is important, but it doesn’t tell the whole story. Lead time is typically much longer than processing time for two reasons: people multitask and work sits idle. Often there is a period where work sits in an “inbox” before being started, or sits in an “outbox” waiting for the next phase.  The time work sits in an inbox or outbox is what’s considered “idle time.” 

Let’s go back to the development stage example. A single user story may sit in “ready for development,” or the “inbox” for five days before a developer actually begins work. Once a developer begins work, they may complete their work in only four hours. This results in a four-hour piece of work sitting in the development stage for more than five days even though the actual work time is minimal. 

Assessing lead time vs. processing time is essential in understanding strengths and weaknesses within your agile delivery process. The agile process is built on the idea of reducing the size of work to accelerate your delivery process. If you’re seeing large amounts of idle time, you can infer that you either have too many user stories or your user stories are too large to move quickly.

Estimating Quality in Each Stage & Process Block

No development team produces 100% usable work — some work is defective or isn’t used. You may even have team members who report quality issues with other members’ work.

Thus, it’s important to capture quality metrics as well. To estimate quality metrics, ask your team to report:

• how often they receive work that is defective, missing information, or inaccurate 
• when in the process they notice defects being introduced

Prior to mapping the value stream, you may know that defects are being released, but you may not be able to pinpoint when these errors are being introduced into the code. By tracking the percent of complete and accurate work at each stage and process block, you start to understand where rework is occurring and when work is being sent backwards in the process. Understanding where these challenges occur helps quickly assess what areas to address to improve quality.

Summarizing the Metrics Across Stages

Aggregating these metrics for each stage and process block allows you to see the bigger picture and quantify waste and forecast ROI for making improvements. 

When summarizing the quality metrics, we look not only at individual stages and process blocks but across the full process to understand how quality and lead time compound across the process. For example, if each process block is only 75% complete and accurate, after six stages only 18% of the pieces will have passed through without having quality issues. 

While looking at each step helps key in on specific issues, looking across the full stream helps quantify the actual value delivered and risk for not addressing issues. Just like a sales team is losing potential revenue by letting opportunities sit in qualification, Salesforce development teams are losing potential revenue when they deliver work less frequently or at low qualities. 

Automating the Value Stream Mapping

Mapping metrics to the value stream can be time consuming. When self-reporting, you may encounter inaccurate metrics and you’ll need to survey the team frequently to continually assess progress. 

Tools like Copado Value Stream Maps take the manual work out of delivery management by automatically monitoring and aggregating key metrics.

The benefits of using a value stream map are two fold: 1) You can easily configure your stages and process blocks, adjusting your value stream as needed, and 2) your data becomes a whole lot more accurate. By linking your value stream directly to your agile management data, you can automatically aggregate actuals, not estimates. 

See how Copado Value Stream Maps accelerates your time to value here.

‍

DevOps Resources

Click here to Learn more about DevOps 360.