What is a Value Stream

Traditionally, different roles focused on what they delivered, such as product managers focused on the delivery of product requirements documents, developers focused on the delivery of software code, and operations focused on the deployment of software products.

As DevOps and Agile evolve, they increasingly focus on delivering overall value rather than deliverables for a single role.

This is where the value stream comes in. The Value Stream is one of the key concepts of DevOps.

As the DevOps Essence explains, we can think of our work in an organization in terms of creating value in response to customer requests. The related actions that need to be taken to complete a request can be arranged in a sequence known as the Value Stream.

What is a Value Stream Map

A Value Stream Map is a visual value stream.

It looks something like this.

How do I draw a Value Stream Map

Drawing a Value Stream Map is simple:

  1. Identify the key steps for processing the request

  2. Analyze the three metrics required for each key step

    1. Lead Time, LT
    2. Process Time, PT
    3. The percentage of Complete and Accurate, %C/A
  3. Organize these steps into a sequence of activities that creates the desired result

Once the value stream is mapped, the most valuable information is the three measures for each step in the flow: Lead Time (LT), Process Time (PT), and the Percent Complete and Accurate, % C/A).

Lead time

Lead time is a term used in supply chain management, which refers to the time between the beginning of an order by the purchaser and delivery by the supplier.

Corresponding to our software development, it refers to the time from creation to completion of a task. As shown in the figure below.

The processing time

Processing time refers to the time it takes for a task to start and finish. As shown in the figure below.

Percentage of completeness and accuracy

Just because a task is done doesn’t mean it’s accurate.

To take a very simple example, when we read books and do homework, usually we can complete 100%, but not 100% correct.

This is also very common in software development, where a requirement is implemented but not as originally described.

The rework cost of the project can be analyzed by the percentage of completeness and accuracy (%C/A).

A few tips for drawing a Value Stream Map:

  1. Don’t over-detail the key steps. Roughly follow the columns on the Kanban one-to-one or slightly more.
  2. It is recommended that the number of key steps should not exceed 15.
  3. Each step can be drawn as if there is a buildup or a delay due to waiting.
  4. In practice, calculating the value of these measures is a big challenge. A more feasible approach is to take a few cards for each iteration and calculate the average PT. Lt looks at how many days it has waited to move from the previous step to the next step, and takes an average. %C/A is inevitably going to get A number on your head, which is inevitable.
  5. A key meeting could also be one of the steps. For example, release the review meeting.

Real Case Analysis Value Stream Map

The following Value Stream Map is from a real life example of mine.

Let me make a few remarks about the data on this graph:

  • Not all companies’ key processes look like this, and value stream maps are drawn differently from project to project.
  • Only 60% of the %C/A of the design review was due to the fact that the product manager of this project did not communicate with the business side frequently when designing the prototype, leading to the frequent rework of the design during the review.
  • The software development LT is 12 days long because many cards are ready and need to wait for an iteration, so the average wait time is 7 days. At many companies, that number may be longer.
  • Both the release application and the launch line LT are quite long, because the application needs to wait for the approval of the leadership, and the release needs to be scheduled, so the waiting time is also quite long.
  • Only 70% of the %C/A of user acceptance tests is also due to lack of frequent feedback from the business side during the development process, which results in A lot of cases that do not meet expectations during the user acceptance tests.

Here are some key takeaways from the data above:

  1. PT/LT is only 39.2%, which means there’s a lot of waiting time in between. Then we can analyze how to optimize each wait time.
  2. There is no wait time for both the build upload and test environment deployment steps, and the %C/A is 100%. Because in this case they were automated using the PIPELINE. Therefore, automation can help us increase %C/A and reduce waiting time.
  3. The average %C/A is 88.75%, meaning there is room for improvement. Then we can analyze in detail why we can’t reach 100% in each step.
  4. After analysis, we found that the reason why many %C/A cannot reach 100% is that people at this step do not frequently get feedback from the previous step to verify whether they did the right thing.
  5. Through analysis, we find that many LT leaders are long because some approval procedures can only be moved forward after the approval of the leaders, and the leaders often fail to approve in time. Some LTs are long because there is no visual Kanban, and people at different steps don’t know the work is ready.

In the example above, the proportion of working time spent on producing the desired outcome is only 39.2% of the total spent time. In regular IT departments, similar numbers are common, or even lower.

The above example produces a lot of reports based on the final analysis of the Value Stream Map, so I won’t go into details here. For each number, you can study the reason behind it and find ways to improve it.

Once we have a Value Stream Map, we can usually ask these three questions:

  1. Why is the %C/A value of these work steps less than 100%? How can we completely prevent errors from being passed from one step to the next (and wasting time and resources on rework)?
  2. In addition to the time it takes to develop a product, what specific factors contribute to lead time? How can we dramatically reduce the time wasted in queues and waiting?

3. How can we change working practices to reduce the processing time of each step?

Benefits of value flow diagrams

  1. The benefit of a Value Stream Map is that it gives participating team members a visual, statistical view of the entire process. And clearly know which step to start to improve.
  2. Second, the visual presentation of the process helps to focus on the value being created rather than the actions being performed. Employees and managers often have a good understanding of their daily tasks (what to do) and neglect the expected results (why).
  3. Third, Value Stream Maps can help identify and eliminate bottlenecks and avoid the pitfalls of local optimization: time and effort spent on constraints that are ineffective or even negative.
  4. Finally, an understanding of the value stream helps to realize the key idea of DevOps: to build a smooth, consistent, step-by-step value stream that allows us to deliver consistently, rhythmically, without unnecessary delays, and with an optimal use of resources.

Based on the theory of constraints proposed by Eliyahu Goldratt, in any system, at any point in time, there is one and only one real bottleneck that slows work down, and the energy expending on anything other than removing this bottleneck can be said to be wasted.

conclusion

To create a complete Value Stream Map, it’s important to study what the actual practices of the project look like, not just imagine them, but also don’t rely on documented information because they are often not maintained.

Value Stream Maps are a way to help us build DevOps better, but they’re not enough to do it well.

If you are interested in this topic, please leave me a comment and we will discuss more possibilities together.

Reference: The DevOps Essential