Value Streams
A value stream begins, ends, and hopefully continues with a customer. A value stream is the set of actions that take place to add value for customers from the initial request through realization of value by the customers.
In Disciplined Agile, we discuss three kinds of value streams.
- Development value stream is the sequence of activities involved in creating the operational value stream and in ensuring the operational value stream can continue to function and operate successfully.
- Operational value stream is the sequence of activities needed to deliver a product or service to a customer. It represents the flow value delivery to the end customer (internal and/or external). They correspond directly to a specific value driver which are often expressed in OKRs. The operational value stream directly affects the customer experience. Operational value streams are supported by development and support value streams.
- Support value stream is the sequence of activities involved in supporting the organization and the development and operational value streams. Examples include building databases, setting security, learning management systems.
Our particular focus for improving agility is on the development value stream. And attend to the operational and support value streams.
Improving the Value Stream
Improving the value stream involves improving the system, to reduce the total time from beginning to end of the entire stream while sustaining this speed in the future (that is, you cannot take shortcuts now at the expense of future development).
Figure 1. Waste and delays
In particular, we want to focus on delays and waste including delays in finding resources, waiting, and getting information, multi-tasking, overloaded people, rework, late detection of problems, hand-offs, unread requirements which affects quality and slows down delivery.
Improving a value stream involves three steps.
- Be clear about the questions we want to answer. Such as:
- Who is our customer?
- What are we doing now (the current state)? What is our flow of value delivery?
- Where is there waste – and especially delay in flow?
- Create a picture of the process. A value stream map is a lean tool that practitioners use to analyze the value stream. While we can use a current state (“as-is”) value stream mapping approach, for knowledge work it is often more helpful and pragmatic simply to begin with the idealized development value stream or to use one of the many development value stream patterns, make adjustments to the map to fit our context, and then use that map to have conversations.
- Plan for steps forward.
- See the challenges. Use the value stream map to have conversations about the current state and to identify areas of waste. The DA Browser describes options for visualizing the existing process and for identifying potential improvements.
- Identify actions. Identify areas for improvement using Guided Continuous Improvement and the options offered in the DA browser. To facilitate conversations and analysis, techniques such as Wicked Problem Solving might also be helpful.
- Create an improvement backlog, focusing on a vital few improvements.
- Execute and deliver the improvements from the backlog. Don’t stop after analysis. Do the work and make the improvements.
- Keep improving.
Depending on the level of change required, we may need to use the Transformation Roadmap.
Example: Using Value Stream Mapping to Get to Root Cause
Be Clear About the Questions
A medium-sized organization was suffering with quality problems in their software product. They were plagued by poor code quality and so this became an issue for the development team. In a nutshell, when the company’s products were installed at their customers’ sites, there were often issues that needed to be fixed and this slowed down new development.
Leadership wanted to reduce the quality problems and the delays in new development caused by rework. They wanted to take a whole-system view.
Create a Picture of the Process
They began by developing a basic current state (“as-is”) value stream map as shown in Figure 2.
Figure 2. The basic current state value stream map.
The loop-back shown in the figure occurs when a customer has a problem that requires work to go back through development. The queues (shown with triangles) indicate that work was often in a wait state, both for development and for deployment. The loopback was particularly disruptive because development teams would start work on the next project only to be pulled off to work on the previous system that had gone awry.
In some sense, this value stream map presented little new information. It illustrated what was known: Developers had a quality problem and were having to do a lot of rework. But the value stream map presented a new perspective. First, it helped to show the entire development process which included sales and marketing. Second, it helped to focus conversations about the root cause of the problem, which was system failure at the customer site.
Plan for Steps Forward: Analysis
They used the value stream map to identify problems, used lean practices to get to root causes, and then could make decisions about going forward.
A common technique for root cause analysis is the “Five Whys.” This technique, credited to Sakichi Toyoda, the founder of Toyota Industries, involves asking why something happened and then why that happened and then why that happened, continuously exploring the cause-and-effect relationships underlying a particular problem until it drills down to the root cause.
Here is what they did.
Question 1: “Why are we having to rework the system?”
Answer: “Because the programs do not function properly on our customers’ servers.”
This led to:
Question 2: “Why do the programs not function properly on our customers’ servers?”
Answer: “Because the code was designed one way, but the servers are configured for another way.”
Question 3: “Why are our customers’ servers being configured differently from how it was expected?”
Answer: “Because our customers are not following our guidelines for server configuration.”
Question 4: “Why are our customers not following our guidelines for server configuration?”
Answer: “Because they aren’t aware of the guidelines.”
Question 5: “Why aren’t these customers aware of them?”
Answer: “Because sales, who is supposed to make sure they know of this configuration requirement, isn’t telling them.”
Question 6: “Why isn’t sales telling our customers they need to do this?”
Answer: “Because when a customer is ready to buy, sales tends to shut up and just get the contract signed. Closing the deal seems to be the most important thing to sales.”
This series of questions illustrates several points.
- Keep asking questions until you get to the root cause. Sometimes, five questions is enough and sometimes you have to keep questioning. In this case, they finally discovered that sales was not informing the customers that the machines needed to be configured a particular way.
- The problem may not be what you think it is. In this case, the assumption was that code quality was the problem; in fact, the problem was that the code was not flexible enough to run on misconfigured servers. Either the code could be fixed or the servers could be configured properly.
- The origin of the problem is not always where you think it is. In this case, the company was fairly sure that this was a development team problem (which is why two people from the development organization were there), when in fact, the problem lay in sales department.
This last point is significant. The problem may not be with the team even though many agilists say to start there. A value stream map enables us to see the whole picture and to question our assumptions. In this case, sales was a significant part of the problem.
Note: The DA Value Stream Consultant course goes into a lot of detail about removing delays in the workflow and how to use current state, to-be, and the idealized value stream maps.
Plan for Steps Forward: The ‘To-Be’ Value Stream
The organization then created their “to-be” value stream map: the value stream as it should be done.
Configuration checks are part of the sales process.
This new value stream map required that their customers were aware of running configuration checks.
The conversation about this change grew quite animated. There was fear that sales would not like this new requirement. After all, here is a customer ready to pay money, but before they can pay, they have to do some additional upfront work. This would seem contrary to sales’ desire to close the deal as quickly as possible. Probably, they would not like any perceived impediment to the deal.
But the value stream analysis looked at the bigger picture. It focused on how the customer would react. The leadership felt that most customers would see that the company was acting responsibly and putting the customer’s interests first. And if they lost a few customers who did not want to make that upfront commitment, then that was OK. By having all customers either follow the new process or cease to be customers, the organization would remove the bottleneck and be able to deliver more value more quickly. They saw that their problem lay not in having enough customers; it was the waste in their process. The fact was they had more customers than they could support.
Metrics can be counterproductive
It also illustrates how metrics and performance awards can be counterproductive. Salespeople were being rewarded on systems sold. The rewards should have been based on systems installed. Metrics and rewards that focus on only part of the value stream are often counterproductive.
Perhaps most interesting is that this company experienced a significant team performance improvement without changing what the team was doing at all.
Conversations build trust and a culture of improvement
Implementing this “to-be” value stream map resulted in significant conversations across the organization. Everyone, including sales, learned and started to see benefits. Development was pleased not to have to make unnecessary changes to their approach.
Plan for Steps Forward: Continuous Improvement
A few months later, the company did a second round of value stream mapping. They started with the previous “to-be” map. Armed with a better understanding of their process, they applied the lean principle to defer commitment as long as practical and to move significant server analysis downstream, doing it just in time for development. They could see exactly where to do this to maximize the needs of development without unnecessarily hampering sales. This reduced delay in their work stream even more! It is also interesting to note that they didn’t lose any customers. They cleverly presented the “requirement” of pre-configuring the systems as a service the company offered the customer as the step just before installation.
November 2022
Related Resources
- Common Lean Practices
- DA Value Stream Consultant Resources
- Disciplined Agile Value Stream Consultant (DAVSC) Certification
- Evolve your WoW - Identify Potential Improvements
- Evolve your WoW - Visualize Existing Process
- Explore Scope
- The Idealized Value Stream of the Effective Organization
- Mapping Your Value Stream
- Value Streams
- Value Stream Management Micro-Credential
- Wicked Problem Solving