Analyze R&D efficiency from the value stream map

What is value stream

In traditional work, different positions only focus on what they deliver. For example, product managers focus on the delivery of product requirements documents, developers focus on the delivery of software codes, and operation and maintenance personnel focus on the deployment of software products.

With the development of DevOps and Agile, they are increasingly emphasizing the delivery of overall value, rather than the delivery of a single role.

Therefore, the meaning of value stream is reflected. Value stream is one of the key concepts of DevOps.

According to the "DevOps Essentials" explanation, we can consider the work in the organization from the perspective of creating value in response to customer requests. The related actions that need to be implemented to complete the request can be arranged in order, which is called a value stream.

What is a value stream map

A value stream map is a visualized value stream.

It looks like the picture below.

How to draw a value stream map

Drawing a value stream map is actually very simple:

1. Identify the key steps in processing the request

2. Analyze the 3 measurement data required for each key step

   1. Lead Time, LT
   2. Process Time, PT
   3. The Percent Complete and Accurate, %C/A
3. Organize these steps into a sequence of activities that create expected results

After the value stream is drawn, the most valuable information is the 3 measurement data for each step in the stream, namely the lead time (LT), processing time (Process Time, PT), and the percentage of completeness and accuracy ( the Percent Complete and Accurate, %C/A).

lead time

Lead time is a term in supply chain management, which refers to the time from the purchaser's order to the supplier's delivery.

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

Processing time

Processing time refers to the time it takes for a task to be completed from the beginning. As shown below.

Completeness and accuracy percentage

The completion of a task does not mean that it is accurate.

To give a very simple example, when we do homework when we are studying, we can usually complete it 100%, but it is not 100% correct.

This is also very common in software development. A requirement is fulfilled, but it is not consistent with the original description.

The completeness and accuracy percentage (%C/A) can be used to analyze the rework cost of the project.

A few tips for drawing value stream maps:

1. Don't over-detail the key steps. You can roughly follow the columns on the kanban one-to-one or slightly more.
2. It is recommended that the number of critical steps should not exceed 15.
3. You can draw each step according to accumulation or delay due to waiting.
4. In practice, calculating the values of these metrics is a big challenge. A more feasible approach is to take a few cards in each iteration, and then calculate the average value of PT. LT looks at how many days it has waited from the previous step to the next step, and also takes the average value. %C/A will inevitably get a value by tapping your head, which is inevitable.
5. A key meeting can also be one of the steps. For example, the release review meeting.

Real case analysis value stream map

The following value stream diagram is from a real case of mine.

For the data on this figure, I will make some explanations:

• Not all companies’ key processes look like this. Different companies have different projects and draw different value stream maps.
• The %C/A of the design review was only 60% because the product manager of this project did not communicate frequently with the business side when designing the prototype, which led to frequent rework when reviewing the design.
• The LT for software development is as long as 12 days, because after many cards are ready, they need to wait for a certain iteration, so the average waiting time is 7 days. This number may be longer in many companies.
• Both the release of the application and the release of the online LT are quite long. It is also because the application needs to wait for the approval of the leader and the release needs to be scheduled, so the waiting time is also quite long.
• The %C/A of the user acceptance test is only 70% because the business side's feedback is not frequently obtained during the development process, which leads to many situations that do not meet expectations during the user acceptance test.

From the data in the above figure, we can get some key information:

1. PT/LT is only 39.2%, which means there is a lot of waiting time in between. Then we can analyze in detail how to optimize each waiting time.
2. There is no waiting time for the two steps of building uploading and testing environment deployment, and %C/A is 100%. Because in this case, they are all automated using pipeline. Therefore, automation can help us improve %C/A and shorten waiting time.
3. The average %C/A is 88.75%, which means there is room for improvement. Then we can analyze in detail why 100% is not achieved in each step.
4. After analysis, we found that the reason why many %C/A cannot reach 100% is that people in this step did not frequently get feedback from the previous step to verify whether they did it right.
5. After analysis, we found that many LT leaders are because there are some approval processes that must wait for the leaders to review before they can continue, and the leaders often cannot approve in time. Some LT is long because there is no visual Kanban, people at different steps do not know that the work is ready.

In the above example, the proportion of work time spent on creating expected results is only 39.2% of the total time spent. Such a situation is quite common in conventional IT departments, or even lower.

In the above example, there are many reports based on the final analysis of the value stream map, so I won't go into details here. Each number can be researched on the reasons behind and improved solutions can be found.

With the value stream map, we can usually ask these 3 questions:

1. Why are the %C/A values of these work steps lower than 100%? How can we completely eliminate errors from one step

Was passed to the next step (and wasted time and resources due to rework)?

1. In addition to the time to develop the product, what are the specific factors that cause the lead time? How can we drastically reduce queues and waiting

How long does it take to wait?

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

Benefits of value flow graphs

1. The benefit of the value stream map is to allow participating team members to have a visual and data-based understanding of the entire process. And clearly know which step to start to improve.
2. Secondly, the visual presentation of the process helps to focus on the value being created rather than the action being implemented. Employees and managers often understand his/their daily tasks (what to do) well, while ignoring the expected results (why).
3. Third, the value stream map helps to identify and eliminate bottlenecks, and avoid the trap of local optimization: that is, time and energy are spent on eliminating constraints that have no effect or even bring negative effects.
4. Finally, an understanding of the value stream helps to realize the key idea of DevOps: to build a smooth and consistent value stream that goes through all steps, so that we can continue, rhythmically, without unnecessary delay, and optimize The way resources are used to deliver results.

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. This bottleneck slows down the work, and at the same time, it is spent on anything other than eliminating this bottleneck. All of his energy can be said to be a waste.

to sum up

To draw a complete value stream map, you must study what the real practice in the project looks like. You can't imagine it out of thin air, and don't count on certain recorded document information, because they are often not maintained.

The value stream map is a way to help us build DevOps better. To do well in DevOps, this alone is far from enough.

If you are interested in related topics, you can leave me a message and we will discuss more possibilities together.

Reference: "DevOps Essentials"