At my first Lean Software Development workshop, I 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. The map that they drew for their organization is shown here:

The loopback shown in the figure occured 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 par-ticularly 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 getting to the root cause of the problem, which was a 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 an actionable cause.

We say “actionable cause” because getting to the root cause is not really possible. You could keep going back forever. 

But an “actionable cause” is something that we can correct. And there are often more than one – then we can choose which one would be easiest to correct the problem with.

Lean uses the technique called “Five Whys” to get to cause. 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 the question, “Why are we having to rework the system?”
A:  Because the programs do not function properly on our customers’ servers.

Q: Why do the programs not function properly on our customers’ servers? 
A: Because the servers were not configured properly.

Q: Why are our customers’ servers not configured properly?
A: Because our customers are not following our guidelines for server configuration.

Q: Why are our customers not following our guidelines for server configuration?
A: Because they aren’t aware of the guidelines.

Q: Why aren’t these customers aware of them?
A: Because sales, who is supposed to make sure they know of this con-figuration requirement, isn’t telling them.

Q: Why isn’t sales telling our customers they need to do this?
A: Because when a customer is ready to buy, sales people tend 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.

It is important to observe that there are two causes. The first was clear – the code was not robust enough to detect or withstand poor server configuration. The second one was the lack of proper configuration. We could fix either of these. In this case it was clear to just fix the lack of proper configuration. In general, we can pick the action that fixes the problem with the best cost-benefit.

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.

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 analysts looked at the bigger picture. They focused on how the customer would react. They felt that most customers would see that the company was acting responsibly and putting the customer’s interests first. And if they lost a fewcustomers 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 coun- terproductive. Sales people were being rewarded on systems sold. The rewards should have been based on the 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.

The Results

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 with-out 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.

Associated Workshops

If you want to learn more about this approach, check out these two online, Amplio workshops:

Amplio Community of Practice

In this every other week series Al Shalloway will discuss topics he thinks are important but either overlooked or done poorly. These will include topics like dealing with complexity, the risks of using frameworks, and how the lessons of engineering can be useful in product development. He will also talk about his own approaches to the team, enterprise, SAFe, and being a coach.

Amplio Development Masterclass

This workshop is primarily for coaches who want to go to the next level and transcend particular approaches but instead think for themselves. It is also useful for people in an organization who are responsible for how effective their coaches are.