|This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.|
This article describes how a company achieved a 20% true productivity improvement in a development group of about 100 people by discovering the true root cause of their challenges with value stream mapping and Lean’s ‘Five whys’ practice.
Value Stream Mapping
The value stream is the set of actions that takes place to add value for a customer from the initial request to the delivery of the value. The value stream begins with the initial concept, moves through various stages to one or more development teams (where Agile methods begin), and on through to final delivery.
The value stream map is a Lean tool that practitioners use to analyze the value stream. Value stream mapping involves drawing pictures of the process streams and then using them to look for waste. The focus is on improving the total time from beginning to end of the entire stream while maintaining this speed in the future (that is, you cannot take shortcuts now at the expense of future development).
One of the great benefits of value stream mapping is that it shows the entire picture. Many Agile practitioners focus on improving the team’s performance. Unfortunately, in many cases, the team is not the cause of the development problems—even when it looks that way. Value stream mapping shows how to “optimize the whole” by identifying waste: delays, multi-tasking, overloaded people, rework, late detection of problems, and so on, which affects quality and slows down delivery.
Using Value Stream Mapping to get to true root cause
At one of our Lean Software Development courses, we had two students from a medium-sized company’s development team. It was clear to the company that they had problems resulting from poor code quality which, therefore, was an issue for the development team. In a nutshell, when the company’s products were installed at their customers’ sites, they often had issues that needed to be fixed, which slowed down new development. They came to us for help because they could no longer just hire more developers to fix the problems.
Near the start of the course, students create an “as-is” value stream map. Figure 1 shows they map they drew.
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, the 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 showed the entire development process (including the marketing aspect). Second, a value stream map suggested geting to the root cause of the problem, which was system failure at the customer site. That is, we use value stream maps to identify problems and we use other Lean thinking to get to root cause.
The “Five Whys”
For root cause analysis, it is common in Lean to use 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.
In our students’ case, the technique started with:
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 many points. First, it’s not really always five whys. Five is often enough, but sometimes you have to keep questioning until you get to the root cause. In this case, sales was not informing the customers that the machines needed to be configured a particular way. Second, 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. Third, 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 highlights a critical failure in many Agile approaches that focus on the team: 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.
The ‘to-be’ value stream
Toward the end of the course, these two participants then created their “to-be” value stream map. That is, a map of their value stream as it should be done. 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 two participants 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.
It also illustrates how metrics and performance awards can be counterproductive. Sales people 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.
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.
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.
See Value Streams Main page for more.