05 Value Stream Analysis, Regarding DevOps Transformation, Where Should We Start #

Hello, I am Shi Xuefeng.

The question of “how to implement DevOps” has always attracted a lot of attention. So, starting from today, I will talk to you about various aspects of this topic in a series of 16 lectures. As the first lecture of the “implementation practice” series, let me talk to you about the things related to DevOps transformation.

I believe you have heard of continuous delivery, right? Nowadays, almost every company implementing DevOps claims to have a continuous delivery platform or is in the process of building one. However, if you think that having a good continuous delivery platform is enough, then you are a bit outdated. Because many foreign companies that specialize in continuous delivery products are also focusing on another thing, and that is VSM, or Value Stream Management.

For example, CloudBees, the main maintainer of Jenkins, recently launched a product called DevOptics, which emphasizes VSM functionality. The VSM view of the classic continuous delivery product, GoCD, has also been widely praised. So what exactly is VSM?

To understand VSM, we must first understand what value is. Simply put, value refers to the core resources that contribute to the survival and development of an enterprise, such as productivity, profitability, market share, and customer satisfaction.

VSM stands for Value Stream Mapping, which is a visual representation of the value stream. It originated from the lean thinking in traditional manufacturing, and is used to analyze and manage the business flow, information flow, and transfer process of a product from production to delivery to the end users.

In simple terms, VSM aims to clarify the process of how raw materials are processed step by step, undergo quality inspections at each stage, and eventually deliver the product to the users after the demand is raised. By observing the flow efficiency and delivery quality of each stage in the complete process, we can identify inefficient or irrational steps and optimize them, thus improving overall efficiency.

It’s similar to ordering a dish at a restaurant. After the demand is raised, the process includes ordering, initial processing of the ingredients (washing vegetables), further processing of the ingredients (cutting vegetables), and cooking. Finally, the dish is served to the table by the waiter. However, sometimes the chef has already finished cooking and placed the dish on a small table by the kitchen window, but the waiter responsible for serving is busy and only brings the dish to our table after finishing other tasks, causing the hot steam to dissipate.

The same principle applies to software development. Due to the division of responsibilities within departments, everyone is focused on their own tasks, which leads to the fragmentation of the software delivery process. As a result, no one can clearly explain all aspects of the software delivery process.

Therefore, by using value stream mapping to model the software delivery process, the entire process can be visualized. This helps identify bottlenecks in the delivery process and dependencies between different stages. This is precisely what the first step, “flow,” of the “DevOps three-step work method” aims to solve.

Let me briefly introduce the “DevOps three-step work method.” It comes from “The DevOps Handbook” and can be said to be the main theme of the entire book. The highly abstract “three-step work method” summarizes the general implementation path of DevOps.

• Step 1: Flow. By visualizing the work, limiting the number of work in process, and injecting a series of engineering practices, the flow process from development to operations is accelerated, enabling low-risk releases.
• Step 2: Feedback. By injecting feedback capabilities into every step of the flow process, defects can be discovered as early as possible, and user and operational data can be presented in real-time, thus improving the organization’s responsiveness.
• Step 3: Continuous Learning and Experimentation. No culture or process is naturally perfect. By motivating the team to learn and share, continuous improvement is integrated into daily work, leading to the ongoing progress of the organization.

Key Elements #

You don’t need to spend a lot of effort studying how to play value stream analysis in the manufacturing industry. You just need to understand the key elements and core ideas of VSM. So what are the key elements and concepts in VSM? There are three points you must understand.

1. Lead Time (LT). Lead time is a very important indicator in DevOps. Specifically, it refers to the time period from the point when a requirement is proposed (typically when a requirement task is created) to the final delivery to the user. This time directly reflects the delivery speed of the software development team and can be used to calculate the delivery throughput. One of the core missions of DevOps is to optimize this duration.

2. Value-Added Time and Non-Value-Added Time (VAT/NVAT). In lean thinking, the most important thing is to eliminate waste, which means maximizing the duration of value-added activities in the process and reducing the duration of non-value-added activities. In the software development industry, there are many typical non-value-added activities, such as meaningless meetings, repeated changes in requirements, and rework caused by defects in downstream development.

3. % Complete/Accurate (%C/A). This indicator is used to indicate the quality of work, that is, how much work is rejected by downstream due to quality issues. This involves a lot of communication and rework costs, which, from a lean perspective, is also a form of waste.

In practice, companies often use requirements as a starting point to connect and integrate various links, and lead time is a natural product of requirement management. The difficulty of collecting lead time does not lie in the system itself, but in whether the operations at each link are timely and effective. Some teams also use requirements management tools, but the lead time is usually only a few seconds. The problem is that they are used to directly dragging the task status from the beginning to the end after going online, which loses its statistical meaning.

It should be noted that there are many interpretations of lead time, and it is generally recommended to use requirement lead time and development lead time as two indicators for measurement. You can have a basic understanding of the definitions of these two indicators.

Requirement Lead Time: The time period from requirement proposal (task creation) to the completion of development, testing, deployment, and final acceptance, which examines the team’s overall delivery capability and is the core perception period for users.

Development Lead Time: The time period from the start of development (entering the development phase) to the completion of development, testing, deployment, and final acceptance, which examines the team’s development capability and engineering capability.

Regarding the duration of value-added activities, my suggestion is not to be overly detailed in the early stages. It is recommended to prioritize the statistics of waiting time. For example, the time from readiness to entering the development phase for a requirement is considered as waiting time. Like lead time, many times, the development habits and practices can also affect the accuracy of data. For example, some developers like to put all the requirements into the development phase at once and then process them one by one, which makes it difficult to identify the actual waiting time. Therefore, if we rely entirely on manual operations to ensure the accuracy of the process, there will be a lot of variables. Combining the process and the platform to drive the automated flow of the process is the correct approach for DevOps.

For example, after the development is completed and the test initiation is submitted, the status of the associated requirements can automatically change from “in development” to “pending testing” instead of being manually modified, which can avoid the impact of human factors. By binding code, pipelines, and requirement platforms, the automatic flow of status can be achieved.

Regarding % Complete/Accurate, it can be temporarily ignored in the initial use of VSM. In fact, I have seen some companies start building quality control-related indicators after implementing the main process, such as the self-test pass rate of development, which objectively reflects the completeness and accuracy of VSM. I will spend some time introducing quality control in the column later, so don’t miss it.

Approaches #

Knowing the key elements of VSM is sufficient. So, as the first step in enterprise DevOps transformation, how do we conduct a successful VSM activity? Generally speaking, there are two approaches.

1. Organize an internal workshop or meeting to map the value stream process within the enterprise.

This is the approach I recommend. For large enterprises, it is possible to select a core business module within the improvement project and ensure that participants in the meeting cover all aspects of software delivery, including tool platform providers. Additionally, the participants should ideally be relatively senior as they have a deep understanding of the business they are responsible for and the upstream and downstream processes. This makes it easier for them to identify the underlying causes of problems.

However, implementing this approach can be costly. After all, it is difficult to get so many key roles together at the same time. Furthermore, in face-to-face communication, people tend to hold back a bit in order to save face, which can conceal many real issues.

Therefore, in general, opportunities like agile retrospectives within teams or version release summaries are suitable occasions. Only a few members who don’t usually attend the meetings need to be invited.

2. Internal personnel visits.

If the first approach is difficult to carry out, you can resort to the second one. Usually, enterprise DevOps transformation work has a lead person or even a transformation team. In this case, members of the team can visit the teams involved in various stages of software delivery. This approach is more flexible in terms of timing, but it requires high qualifications for the visitors. It is best if they are DevOps domain experts and internal veterans of the enterprise, as this allows for more in-depth and honest communication with the interviewees.

Regardless of the approach chosen, it is necessary to identify several key questions, narrow down the scope of the conversation, and avoid wandering aimlessly in discussions, striving for effective communication. For example, you can create a list of questions:

• What are the main responsibilities of your team in the value delivery process?
• Which upstream and downstream teams does your team have?
• How is value handled in the current stage and how long does it take?
• What are the key systems supporting value delivery work?
• Are there any waiting or other types of waste?
• What is the proportion of work that is sent back after flowing downstream?

To help you better understand these questions, I will provide you with an example of an interview with a testing team.

Through interviews and communication, we can develop a comprehensive understanding of the entire software delivery process. Based on the stages, upstream and downstream relationships, processing times, and identified waiting waste times, we can create a value stream map of the current department and identify typical tools for each stage, as shown in the following diagram:

Of course, the actual delivery process is quite complex and involves frequent interactions between various roles, which is a test for the DevOps transformation team. This requires not only a deep understanding of the software development process but also a thorough understanding of the concept and essence of DevOps. Effective communication skills are also crucial, as they enable the quick establishment of trust with unfamiliar individuals.

Value #

So why is Value Stream Mapping (VSM) the first step in an enterprise’s DevOps transformation? In fact, its value extends far beyond simply producing a value stream delivery diagram. VSM has a wealth of value, including the following aspects:

1. Seeing the big picture.

If we only focus on individual issues, we can easily fall into the trap of local optimizations. DevOps aims to maximize the efficiency of value flow, which means that even if a single point has strong capabilities, the impact of fragmentation and waste between these points on value delivery efficiency is unimaginable. Therefore, for process improvement, the first and most important step is to be able to see the big picture. Only by taking a global perspective can we identify bottlenecks that can be optimized and improve overall delivery efficiency.

Furthermore, modeling the global delivery is ultimately reflected in the construction of a software Continuous Delivery (CD) pipeline, as the pipeline represents the objective delivery process of the enterprise. It is also easy to understand why many companies that build CD pipelines have extended them to value stream delivery platforms. This is because there are similarities between the two, but at different levels of abstraction and presentation.

2. Identifying problems.

When discussing enterprise delivery efficiency, we often speak in general terms, which are subjective and unreliable since they depend on individual perceptions. In other words, even if delivery efficiency improves, we do not know why it improves.

The key metrics in VSM, such as lead time, value-added and non-value-added time, as well as completeness and accuracy, are measurable metrics that can objectively quantify improvements. When faced with such a value stream diagram, we can easily identify the most important current issues and areas for improvement.

3. Facilitating communication.

DevOps advocates improving delivery efficiency through communication and collaboration among team members, but the objective reality is that in many enterprises, team members are essentially “online friends”. Even if they work in the same building, they may sit in different places due to different departments. They mainly rely on instant messaging software and email for communication. Occasionally, they only meet each other briefly during meetings, and there is rarely any in-depth communication. If the team members are in a situation where they do not know each other and have not been acquainted, how can they effectively collaborate?

In addition, many times, when we conduct VSM analysis, teams for the first time truly understand the responsibilities, working methods, and the things that cause pain and inefficiency for upstream and downstream teams. At this time, we usually think from their perspective, “If we do a little more, we can greatly improve the survival situation of our sister teams.” In fact, this kind of empathy is very helpful in breaking down barriers to collaboration and can have a very positive impact on improving the internal culture of teams. This is also the fundamental reason why I recommend using meetings or workshops to promote VSM.

4. Driving measurement.

We all recognize the power of data to drive improvement. However, faced with such a complex data system, which data is truly valuable? VSM can answer this question.

During VSM interviews, we need to ask about metrics such as delivery cycle time and accuracy. If you find that a team hesitates and can only give vague answers, then you should pay attention, as there is a problem here. This indicates that the metrics in this stage are not clear or overly complex, and the team is not clear about the critical performance indicators.

Furthermore, if it takes a long time to extract the data, such as requiring manual counting, then this reflects a lack of platform-building capabilities in this stage. It cannot collect and analyze data automatically, and even some key data has not been accumulated in the data system and can only be managed manually and locally.

These are problems that need to be addressed in the process of DevOps transformation and can be prioritized for resolution. It can be said that VSM is a trial of team collaboration. The process of collecting VSM data itself requires integration and sharing of platforms, as well as automation, which helps in conducting measurement activities.

5. Value presentation.

For enterprises, any investment needs to have a return. To achieve a DevOps transformation, enterprises need to invest a lot of effort. So how can we make senior leaders understand the value of improving delivery efficiency for the enterprise? Value stream analysis is a good way to do this. Because VSM starts from value analysis and aims for value optimization, it is itself answering the question of value in DevOps for the enterprise.

Summary #

In this lecture, I introduced you to the first step of DevOps transformation - VSM (Value Stream Mapping), including its origin, three key elements, and two ways to implement VSM in the enterprise. Finally, I presented the five values of VSM, which are seeing the big picture, identifying problems, facilitating communication, driving metrics, and demonstrating value.

As we often say, DevOps transformation is an ongoing journey without an endpoint, and the process of mapping VSM will not always be smooth. Because the mapping of the enterprise value delivery process requires continuous iteration and optimization as our understanding deepens. However, a good start is half the battle won, and when we start mapping VSM, our focus will gradually shift to the DevOps mode and truly embark on our DevOps transformation journey.

Thinking Questions #

Finally, here’s a thinking question for you: What do you think is the biggest obstacle to clarifying the value stream within a company? Have you encountered any challenges when extracting data for the three key elements of a value stream map?

Feel free to write your thoughts and answers in the comments section. Let’s discuss and learn together. If you find this article helpful, please feel free to share it with your friends.