How DevOps Can Optimize Continuous Delivery with Value Stream Mapping

As DevOps teams optimize their continuous integration and continuous delivery (CI/CD) pipeline, they may struggle to identify and prioritize improvements that add value to the end customer. On the surface, determining which improvements will yield the biggest impact might seem straightforward. The reality, though, is that it can be hard to pinpoint which improvements matter, especially in complex software environments, with all the tools, processes, and people involved, all the different relationships and dependencies they all have, and all the data they all generate. Value stream mapping (VSM) provides delivery teams with a flexible, visual way to understand what is and isn’t working from the value delivery perspective, helping prioritize where and how they invest time in improving delivery of value. 

What adds or removes value? The answer might not be what you think.

While the DevOps goal of reducing waste in the CI/CD pipeline is clear, identifying what is actually wasteful might not be so easy. The idea that when you’re deep in the trees, it’s hard to see the whole forest definitely applies to the software development lifecycle (SDLC). 

Consider the case of automating a test suite, for example. Running an automated test is clearly faster than running it manually. An automated test can be re-used whenever it’s needed. Automation reduces the opportunity for errors. Without even analyzing all the details, we might all agree that it adds value to the customer. 

You might think that automating everything you can in testing would eliminate all the bottlenecks. But consider this scenario: Engineering sends a feature to QA. QA starts its automated testing, finds a defect, stops the testing, and sends the product back to engineering. Engineering fixes the issue and resends to QA. QA begins their automated testing again, confirms the issue has been resolved, and continues running through tests. Now QA finds a new defect, testing is paused, the product is sent back to engineering, and the whole process repeats. QA has automated much of its testing, but their process is to stop testing as soon as a defect is found. How much time is spent waiting for each cycle? What might change if QA ran through all its tests first, before sending any defects found back to engineering? Is there a more effective way to move the feature through the cycle and add value to the end customer?

Some steps might seem beneficial on the surface, but prove to introduce too much friction when examined more closely. For example, consider an organization that has experienced upset customers after several failed deployments. In response, the organization started a regular deployment review process between product engineers and a Change Approval Board (CAB). That review process added five days to the timeline, so the engineers responded by creating an automated report for the CAB that they can quickly generate as needed. Creating the report and then running it for every CAB review adds time to the engineering load, and distracts them from coding. On the surface, both the CAB and the automated report seem quite reasonable. But what if one or both steps actually introduces friction or waste without delivering any value to the customer? What if the deployment issues remained, and customers grew increasingly frustrated? What if the deployment issues were resolved, and the CAB review process remained, even though it didn’t actually contribute anything to the resolution?

Value stream mapping and how it can help

First used in lean manufacturing as a way to identify and remove waste in an assembly line, a value stream defines the series of steps involved in the continuous delivery of value to the end customer. Value, in this case, is defined as anything the customer is willing to pay for. Value stream mapping (VSM) visually maps the value stream from idea to production, making it easier for teams to identify and agree on what is and isn’t working. 

Like a flowchart, VSM maps tasks and information flows using a set of standard metrics. VSM, however, results in much more than a flowchart. A value stream map provides comprehensive information about all the steps, with as much or as little detail as you need, including the people involved, time needed to complete, quality of work and value added, or not added, in each step. 

VSM works across many domains and industries. Applied to assembly line manufacturing, VSM can help identify where materials are being wasted or component delivery delays impact available inventory. Applied to a service industry like healthcare, VSM can pinpoint how treatment protocols impact patient care quality. 

Applied to DevOps, VSM helps the business optimize the entire process of customer value delivery, from idea to deployment. Visualizing the process in this way helps DevOps teams quickly identify where their efforts can make the most impact, prioritizing anything that adds customer value. Increasingly, software development and delivery teams rely on VSM to track how effectively and predictably the organization delivers on customer needs. In fact, organizing people and processes around value streams is an integral part of SAFe.

You can create a value stream map for each individual product and service or for a specific set of features. A single organization is likely to have several different value streams. In SAFe, a portfolio contains one or more development value streams, and each value stream is focused on building and supporting a set of solutions.

How to get started with VSM

VSM can be as lightweight or as detailed as you need it to be. We recommend you start simple and small, and keep your value stream maps tightly focused. Creating your map doesn’t have to be complicated. Start by sketching it on paper or a whiteboard. When you’ve got the general idea down, use a mapping tool such as LucidChart (which provides a very useful DevOps template example here) or Miro (which we often use). Remember that the level of effort you expend on your mapping should be relative to the savings or return on investment you expect to achieve. The intention of VSM is to add value, not to add unnecessary work.

1. Define the problem or challenge you want to tackle, from the customer’s perspective. Do customers complain about bugs taking too long to get fixed? Is it taking too long or too many steps for customers to complete an important process like new account creation or order submission? Be as specific and detailed as you can be in defining the problem. Once defined, solicit as much feedback as possible from the critical stakeholders in the process, and refine as needed until everyone agrees on the problem and the priority.

2. Define the scope. You might cover your entire development and delivery cycle, or just a specific stage like deployment or QA. We recommend that you keep the scope limited to a manageable set of 10 to 15 steps overall, especially when you’re just getting started.

3. Map each step in the value stream’s current state. Keep your map clear and simple, working with your team to clearly understand and define the value of each step. 

4. Track the data for each step. For DevOps, consider tracking:

a. Number of people involved

b. Process time: amount of time that a person or team spends working on that step of project 

c. Lead time: total time it takes a person or team to complete a step from start to finish, including time spent waiting in the queue and process time.

d. % complete/accurate: percentage of the work that is complete and accurate the first time and requires no re-work by downstream steps.

5. Once you’ve got your current-state map documented, review it closely. Does each step create or detract value? Are there steps that are too long? Are there dependencies between teams that are adding too much time? Are there steps that your team values that don’t add value to the customer? Can you identify steps that you can control and improve that would add value to the customer?

Look for signs of wasted effort or time. You might have once had good reasons for doing things a certain way; if that way doesn’t add value or adds waste, this is a very good time to be ruthless. LucidChart offers a handy way to categorize waste in DevOps, using DOWNTIME as an acronym:  

• Defects: mistakes, bugs, and rework

• Overproduction: producing more than is necessary, like extra features

• Waiting: delays and the amount of time the product spends in queue

• Non-utilized talent: not including all relative employees in the improvement process

• Transport: handoffs from developers, to testers, to deployment

• Inventory: partially done work

• Motion: individual task switching

• Extra processing: relearning or reworking, such as undocumented code

6. Based on your assessment and current customer needs, define a future-state value stream map. Make sure it solves for the problem statement, and aligns with your business and customer needs. Identify the KPIs you can use to track and report on progress toward your future state. Make a plan for how you can evolve to the future-state over time, while continuing to assess how well it’s working. Everything is always evolving, whether it’s your customer needs, your team and team needs, your tools, or technology, so you can expect that your value stream map will always be evolving, too.

Improving the customer experience by optimizing value delivery

With VSM, DevOps can more easily identify bottlenecks, find new opportunities for automation, eliminate redundant or wasteful steps, and improve communication and collaboration across teams. As important, DevOps can use VSM to show the business how it impacts the delivery of value to the end customer. VSM helps DevOps teams focus on continuous integration, continuous delivery, and continuous improvement in service of the business.