You Already Understand Many of These Values

An organization will get what it values, and the Agile Manifesto does us a great service in shifting our perception of value from process to people, from documentation to code, from contracts to collaboration, from plans to action.

Tom and Mary Poppendieck, Lean Software Development: An Agile Toolkit

Does it surprise you that you’ve already encountered many of the Lean values and thinking tools? It shouldn’t. Lean is an important part of agile. When the Poppendiecks were adapting ideas from lean manufacturing to software development, they borrowed from other parts of agile, including XP. But more importantly, the manufacturing ideas that they used have been an important part of engineering and quality management for decades. Ken Schwaber drew on many of the same quality ideas when developing Scrum—we saw this when learning about how the Daily Scrum is a formal inspection.

Because this book covers several agile methodologies, we’ve already covered some important parts of Lean. We’ll go through them here—the only reason they don’t take up much space in this chapter is because you’ve learned about them in depth already. They’re still core elements to lean thinking.

Figure 8-1. You already know a lot about Lean, because there’s a lot of overlap between the values of lean thinking and the values of Scrum and XP.

Take another look at the list of Lean values. At least one of them should jump out at you: decide as late as possible. Both Scrum and XP heavily rely on the idea of making decisions at the last responsible moment. This Lean value is exactly the same idea. Scrum teams apply this idea to planning. So do XP teams, and they also apply it to design and coding. Lean practitioners do this too—in fact, this value even has a thinking tool called the last responsible moment, which is identical to the concept that you’ve already learned about.

There’s another value that you’ve learned about already: amplify learning—and you know that you’ve already learned it because its first two thinking tools are feedback and iterations.These are exactly the same concepts that you learned about with both Scrum and XP. This value also has two other thinking tools: synchronization and set-based development. Synchronization is very similar to continuous integration and collective ownership in XP, and we’ll cover set-based development in just a minute.

Finally, you’ve also learned about the value empower the team, and its thinking tools self-determination, motivation, leadership, and expertise. These ideas are almost identical to the ideas behind the XP practices of whole team and energized work—especially avoiding long days and long nights because they have a severe and negative impact on the software. You learned in Chapter 4 that Scrum teams also value this, as part of the Scrum value of focus. A team whose members have control over their lives will build better software. And you’ll learn later that an important aspect of seeing the whole is sharing information about the project with everyone, including managers—this is exactly why Scrum teams value openness.

Commitment, Options Thinking, and Set-Based Development

Here’s something we said back in Chapter 4—it’s worth reading again:

Plans don’t commit us. Our commitments commit us: the plan is just a convenient place to write those commitments down. Commitments are made by people, and documented in project plans. When someone points to a project plan to show that a commitment was made, it’s not really the piece of paper that the person is pointing to. It’s the promise that’s written down on it that everyone is thinking about.

So what does that really mean? It means that when you make a plan, first you make the commitment, and then you write it down.    

Now have another look at Figure 8-1. We added a footnote to commitment about how it’s part of Lean and XP, because even though it’s only explicitly called out in the Scrum values, commitment is an important part of both the XP mindset and lean thinking. But Lean goes further and adds nuances to the ideas of commitment: options thinking, or seeing the difference between something that you’re committed to and something that you have the right (but not the obligation) to do; and set-based development, or running a project in a way that gives you more options by having the team follow several paths simultaneously to build alternatives that they can compare.

Use a Value Stream Map to Help See Waste Clearly

In Lean Software Development, Mary and Tom Poppendieck recommend a simple pencil-and-paper exercise to help you find waste. It’s called a value stream map, and you can build one for any process. Like many techniques used in conjunction with Lean, it originated in manufacturing, but it makes sense for software teams as well.

It shouldn’t take you more than half an hour to build a value stream map for your project. Here’s how to do it. Start with a small unit of value that the team has already built and delivered to the customers or users. Try to find the smallest unit possible—this is an example of a minimal marketable feature (MMF), or the smallest “chunk” of the product that the customers are willing to prioritize. Think back through all of the steps that the unit went through from inception to delivery. Draw a box for every one of these steps, using arrows to connect the boxes. Because you’re drawing the actual path that a real feature took through your project, this will be a straight line—there are no decision points or forks in the path, because it represents the actual history of a real feature.

The concept of a minimal marketable feature is important here. Luckily, it’s a concept that you’ve already learned about. When the Product Owner of a Scrum team manages items in the backlog, those items are typically MMFs. An MMF often takes the form of a user story, requirement, or feature request.

Next, estimate how much time it took to do the work for the first step, and how much time elapsed before the next step to start. Repeat this for each of the steps, and draw lines underneath the boxes to represent the work and wait times.

Figure 8-2 shows an example of a value stream map for a real feature going through a traditional waterfall process.

Figure 8-2. This value stream map shows how a feature in a software project moves through a traditional project management cycle. A team can use it to see more clearly where time is wasted.

The value stream map clearly shows how much wait time was involved during the process. It took a total of 71 days from the time the team started work on it to the time that it was deployed. Of those 71 days, 35.5 were spent waiting rather than working. That waiting time could be caused by many different things: the requirements document may take a long time to circulate to all reviewers, or an estimation meeting had to wait because everyone’s schedule was booked, or plans are always reviewed by a committee that only meets once a week. The value stream map shows the cumulative effect of those delays on the feature, without bogging you down with the details of why those delays happened. Seeing the overall impact helps you delve into which delays are waste, and which ones are necessary for the project.

To the team, it may not have seemed like they were waiting a long time for the plan to get approved, because they were probably working on another feature during the waiting time. But the customer who needs the feature doesn’t necessarily know about all of the other priorities that the team is focusing on. And, to be honest, he doesn’t really care—all he knows is that for his feature, a total of 71 days elapsed between the time the team started building it and the time that it was delivered.

Imagine how the boss might react when he sees how much waiting was involved, especially if he had to deal with the increasingly impatient and angry customer. If the team can find a way to cut down on waste and reduce the waiting time, they can significantly improve the delivery time for future features. That will make the customer happier, which will make the boss happier too. And that’s how visualizing the waste makes it easier to convince everyone—especially the boss—that something needs to change.

See the Whole

When you work on a software team, you don’t work in a vacuum. How your team and your company are structured can have a big impact on how you do your work. And there are all sorts of barriers and stumbling blocks in any organization that can impact your projects as well. For example, you may need to get half a dozen specification approvals from managers before you can start working on a new feature of your software. Maybe a few negative comments from a user cause a product owner to panic and start scheduling your weekends for you. Your boss could fall in love with an overly complex workflow in a ticketing system, and now you need to push every ticket through eight phases before you can start working on it. These are just a few examples—you can probably think of your own examples of inefficient activities that are baked into the way you and your team work.

We saw earlier how these things are waste, but we also saw that sometimes they serve a purpose that may not benefit your project, but are needed by the project or the company. For example, you and your team may waste time (from the project’s perspective) filling out reports that don’t help the project, but if they’re required by a regulator then they’re worth it to the company. How do we know which activities are genuinely useful?

That’s where the next Lean value comes in: see the whole. To really understand whether your team is working efficiently and effectively, you need to take a step back and understand the whole system, because you need to see the whole objectively: it’s easy to become emotionally invested in a solution. For example, say a project manager created a timesheet system that requires every developer to fill out a daily timesheet in 15-minute increments. She might be really happy with the constant status updates that she’s getting. But she might not be aware of how taxing it is on the team—and it’s a lot easier to convince her to give up those extra updates if you can show that they’re costing the team, say, 5% of their productivity.

But while recognizing the nature of the system that the team works in may sound straightforward, it isn’t always easy to do. Each person on a team may feel good or bad about a project depending on how satisfying it was to work on, or how they see their individual contribution. For example, a developer might find a project very satisfying if she solved an interesting coding problem. A project manager will be more satisfied with a project if the team came in ahead of every deadline—but if the developer had to give up her nights and weekends to meet that deadline, she might feel like the project was less successful.

This is why Lean teams take measurements—another Lean thinking tool—so that everyone can see the project the same way. There are many things that a software team can measure, and choosing the right measurement helps the team get a better picture of the project. They’ll take different measurements depending on what problem they want to solve. Everyone on the project has a different perspective, and taking objective measurements helps get everyone to see the project on the same terms.

For people who haven’t spent a lot of time measuring a system—especially the system that a team uses to build software—this can seem very abstract. Let’s make it concrete with an example.

Users care very much about how responsive teams are to their needs. Businesspeople and users want their requests to make it into the software quickly. They’re much happier when a team can give them one new feature a month than when they have to wait three months for all three features. This is why both Scrum and XP use iterations, and it’s why agile teams use shorter feedback loops.

Imagine that you’re a business owner paying for a software project. How do you know if you’re spending your money wisely? Let’s say that you’ve gotten a steady flow of status reports from your project manager telling you that the project is coming in on schedule and under budget, and that everything is going very well. He has many dashboards, reports, and completed tasks on project plans that are full of green dots to show how each of the past four releases has been almost entirely on track.

This sounds like incontrovertible evidence that the project team is building software very well, and is delivering features that the users requested. Even more, the project manager can point to buffers in the schedule, a tidy risk register, and a ticketing system to show that the project is fully under control, and that allowances have been made for known and unknown risks in the future. As the boss, this gives you a warm, fuzzy feeling: you have control over the project, a good idea of how it runs, and a way to handle unexpected problems that pop up.

But what if you hear from several of your customers who use the software that they made simple requests months ago, and still have not seen them added as features to the software? What if you’re starting to lose customers because they’re switching to a competitor that they perceive as more responsive to their needs? Would you say that the project is a success? Clearly there’s a serious problem, and you need to work with the team to fix it.

How would you work with the team to get them to respond to the most important requests more quickly? Let’s say that you try to confront the team, but they point to their positive status reports and tell you that the project is going just fine for them. How do you get them to see the problem?

An objective measurement can help with this. Many teams will measure lead time for each feature. This is a measurement of the average time elapsed between when a feature is requested and when it’s delivered.

Here’s how to calculate it. Any time a user makes a request, record the start date. When a version of the software is released that includes that request, record the end date. The amount of time elapsed between the start date and the end date is the lead time for each request. Add up the lead times for all of the requests in the release and divide by the number of features to calculate the average lead time for the release.⁶⁷

If you ask all the team members what they think the average lead time will be, what do you think they’ll say? If the team releases software every month, they’ll probably guess that it’s between one and two months. That could be an acceptable lead time—most of your users could be satisfied with that, and maybe you just heard a few “squeaky wheel” stories from especially disgruntled users.

But what if the lead time turns out to be a lot longer than your users will accept? What if it takes six months for even a simple user request to make it into the software, and this is not acceptable? Is it the team’s fault? Is it something that you’re doing? Or is the long lead time an unavoidable side effect of how your business is run? You don’t know yet. But now you know that there’s a problem, and because you took measurements, you can help the team understand that there’s a problem too.

Now when you confront your team about the complaints, if the project manager points to the status reports and tells you that there are no problems, you can point to the objective lead time measurement and prove to the team there is a problem after all. This is much better than just saying, “I’m the boss, fix it,” because now there’s a clear, objective goal that everyone can work toward. It’s not an arbitrary decision, and it’s not magical thinking.

Find the Root Cause of Problems That You Discover

Taking measurements and seeing the objective truth about your project and your team is only the first part of seeing the whole. The second part is understanding the root cause, or the actual reason that the problem is happening.

Back at the end of Chapter 6, we said that we’d get back to root-cause analysis, because in addition to being an important part of lean thinking, it’s also one of the corollary practices of XP teams. XP teams and Lean teams both utilize a technique called Five Whys to figure out the root cause of a problem. Like much of lean thinking, this technique originated with Japanese auto manufacturing, but has found a home among agile teams. In this simple practice, the team members ask why a problem happened, and when they answer the question they continue to ask why (usually around five times) until they discover a root cause.

In our example, the team can use the Five Whys technique to find the root cause of their long lead time by asking questions like this:

• Why is the average lead time so long? Because it’s taking over six months for most users’ feature requests to make it into the software.

• Why is it taking over six months for users’ requests to make it into the software? Because those feature requests are almost always pushed back to make room on the schedule for last-minute changes.

• Why are there so many last-minute changes? Because before the team can release software to the users, they need to do a review with senior managers, and those senior managers almost always ask for basic, foundational changes.

• Why do the senior managers almost always ask for basic, foundational changes? Because they all have very specific opinions about how the software should look, how it needs to function, and sometimes even the technical tools that should be used to build it, but the team doesn’t hear those opinions until after they’ve built all of the code and have demoed it to the senior managers.

• Why doesn’t the team hear those opinions until after they’ve built all of the code and given a demo? Because the senior managers are too busy to talk to the team early in the project, so they’ll only attend the final demo—and send the team back to the drawing board after the software is finished.

Aha! Now we know why it takes so long for the team to respond to user requests. Taking measurements and looking for the root cause helped us to see that this wasn’t the team’s fault at all. It turns out that the team finishes many of the features, but when they give the demo to the senior managers, they’re asked to make a lot of changes. Maybe it turns out that these changes are necessary, and those managers had good ideas. But even necessary changes require that this particular project manager do an impact analysis, update her project plan, and reschedule the changed features for a later release. This is what led to the very long lead time that was measured. And it gets worse—some feature requests were already scheduled for the next release; now they need to be bumped to the following release to make room for the changes made by the managers. And it turns out that those requests’ especially long lead times caused some of the users to switch to the competitors.

Understanding the root cause of the long lead times gives us several potential solutions. The team can build software more iteratively, and ask the managers to attend demos at the end of each iteration, rather than at the end of each major release. Or the managers can delegate their approval to someone (like a Product Owner) who stays more involved with the project and meets with the team more often, and trust that person to make the right decisions. Or the team and managers can keep building software the same way and live with the long lead times, but bring in account managers to work with the users and clients to manage their expectations.

To sum up: the team started with a problem—not responding quickly enough to users’ feature requests. By taking measurements and looking for the root cause, they were able to see the whole. They understood where their project fit in with the rest of the company, and could identify several possible fixes that would lead to a long-term solution. And most importantly, the team and the boss now both have the same objective information, and can make decisions together.

Use an Area Chart to Visualize Work in Progress

How do you know if you’re delivering as fast as possible?

Lean thinking gives us an answer to this question: measurement. And an effective way to measure how your team delivers valuable products is to use a work-in-progress (WIP) area chart. This is a simple diagram that shows how the minimal marketable features are flowing through your value stream.  

If you’ve created a value stream map, then you can build a WIP area chart, which is an area chart that shows how features, products, or other measures of value flow through every part of the value stream. This works best if you use MMFs, because they represent the minimally sized “chunk” of value that’s created.

Let’s take a look at an example of a value stream map that shows how a web development shop handles most of their MMFs.

Figure 8-3. We’ll use this value stream map to build a work-in-progress (WIP) area chart.

The goal of the WIP area chart is to show a complete history of the work in progress—all of the valuable features that the team is currently working on. The chart will show us how many MMFs were in progress on any date, and how those MMFs broke down across the various value stream stages. The work in progress is a measurement of features, not tasks. In other words, it shows the number of features or parts of the product that are being worked on, not the specific tasks that the team does to produce them. Back in the Scrum chapter, you saw how features relate to tasks when the team broke stories down into tasks that moved across a task board. A story is a good way to represent an MMF because it’s a small, self-contained “chunk” of value that’s delivered to the user. The story would appear in the WIP area chart; the tasks that the team uses to build the story don’t.

To build the WIP area chart, start with an x-axis that shows the date, and a y-axis that shows the number of MMFs. The chart has a line for each of the boxes in the value stream map. The lines divide the chart into areas for boxes in the value stream map.

There are no MMFs in progress before the project starts, so there’s just a single dot at X=0 at the lefthand side of the diagram (day 0). Let’s say that when the project starts, the team starts working with the users on nine user stories, and they’re using those user stories as MMFs for their project. Then a few days later, they add three more stories. You’ll draw a dot at 9 for the first day, then another at 9 + 3 = 12 when those new MMFs were added, and you’ll connect them.

Figure 8-4. Start building up the WIP area chart by creating a line chart of MMFs (like user stories) in the first stage of the value stream, and shading the area underneath it.

A few days later, the programmers start working on creating the design wireframes for four of the stories, so those four stories have progressed to the next stage in the value stream. The total number of MMFs in the system is still 12, but now they’re divided into 8 still being worked on—or waiting, because the value stream map tracks both work and wait time—in the first stage of the value stream, and 4 in the second stage. So you can add dots at 4 and 12 to represent this.

Figure 8-5. When work progresses to the next stage in the value stream, a new line for that stage is added to the WIP area chart, dividing it into two areas. The top line still represents the total number of MMFs in in progress, and the space between it and the new line represents the number of MMFs in the first stage.

As MMFs move through the value stream, the total number of tasks grows, and over time the WIP area chart acquires stripes for each stage in the value stream map.

Figure 8-6. The WIP area chart shows you how work in progress changes over time.

What happens when MMFs are completed? If you keep them on the chart, eventually the number of “done” MMFs grows to a size that dwarfs all of the other columns. This makes the active MMFs resemble a ribbon on top of a mountain.

Figure 8-7. When a team wants to show the boss how much work they’ve accomplished, they’ll leave the “done” tasks on the chart because it looks impressive. Unfortunately, that makes it a lot more difficult to use the chart to measure work in progress.

This is showing growth, not flow. And while it makes for a great status report item to impress a senior manager—because it shows that the team has gotten an enormous amount of work done—it’s not particularly useful for managing flow. Removing the “done” work from the diagram gives a clearer visualization of how value flowed down the value stream over time.

Figure 8-8. It’s useful to remove the “done” tasks from the chart, and use different shades for each stripe to make it easy to figure out which columns they correspond to.

This is why most WIP area charts do not include completed tasks. That way, if your project stabilizes over time, your WIP area chart looks stable too.⁶⁸ When a MMF moves from one stage in the value stream to the next, the stripe for the old stage it moved from gets thinner, and the stripe for the new one to gets thicker. This makes it easy to spot trends—like when many MMFs move from one column to another (or out of the value stream entirely) at the same time.

Figure 8-9. The WIP area chart helps you see how the work flows through the value stream, and makes it easier to spot delays and other potential waste—like stories that took a very long time to deploy to production.

Control Bottlenecks by Limiting Work in Progress

An important idea that uses queuing theory is called the theory of constraints, introduced by a physicist turned management guru named Eliyahu M. Goldratt. One of the ideas behind the theory of constraints is that a particular constraint (like work piling up behind an overburdened team) limits the total amount of work that can get through the system. When the constraint is resolved, another constraint becomes the critical one. The theory of constraints tells us: every overloaded workflow has at least one constraint.

When a constraint causes work to pile up at a specific point in a workflow, people will often call it a bottleneck. Removing one bottleneck from the system—maybe by changing the process or adding people—will cause work to flow more smoothly. The theory of constraints tells us that there will still be another critical constraint or bottleneck somewhere else in the system. However, we can reduce the total amount of waste by systematically tracking down the critical constraint and eliminating it.

What does it feel like to work on a team that has to deal with one of these constraints on a day-to-day basis? In other words, what does it feel like when you and your team are the bottleneck?

When you’re the bottleneck in the system, you’re always expected to multitask, constantly switching between your normal full-time job and many smaller part-time ones. Keep in mind that plenty of healthy teams usually have many tasks due at the same time but don’t call it “multitasking”; people typically use the term “multitasking” in order to mask the fact that the team is simply overloaded. Splitting the work up and telling the team to multitask often keeps you from recognizing that you simply have more work than time, especially when you consider the extra time and cognitive effort required to switch between tasks.

For example, a team that already has 100% of their time already devoted to development work may have a boss with magical thinking who asks them to “multitask” and spend several hours a week that they don’t have on support, training, maintenance, meetings, or other work. It’s difficult for them to necessarily see that they have more work than time, especially if that extra work is added a bit at a time. They’ll just start to feel overloaded, and because it’s called “multitasking” they won’t necessarily realize why they feel that way; it will just feel as if they have many part-time jobs that they’re having trouble keeping up with. We can help that team by applying queuing theory to gain insight into the problem. Now we know that more and more of their work is piling up in a bottleneck somewhere in their workflow, and that growing pile of work is weighing on them.

Pull Systems Help Teams Eliminate Constraints

And I have a philosophy that I live by. Everybody that works with me knows this; it’s on the wall: “If stupid enters the room, you have a moral duty to shoot it, no matter who’s escorting it.”

Keoki Andrus, Beautiful Teams (Chapter 6)

A pull system is a way of running a project or a process that uses queues or buffers to eliminate constraints. This is another concept that originated with Japanese auto manufacturing, but has since found its place in software development. Car manufacturers—specifically Toyota in the 1950s and 1960s—started to look at their warehouses of parts, and tried to find ways to reduce the number of parts that they needed to have lying around. After a lot of experimentation, they discovered that even if you had almost all of the parts needed to assemble cars available in the warehouse, a shortage of just a few parts could hold up the entire line. Entire assembly teams would end up waiting for those missing parts to be delivered. The cost of delay became important: if a part was in short supply, a delay in getting that part to the assembly line was very expensive; if the part was abundant, the cost of delay was low.

Teams at Toyota found that they could reduce their costs and deliver cars much more quickly if they could figure out which parts the teams needed right now, and deliver only those parts to the line. To fix this, they came up with the Toyota Production System (or TPS)—this was the precursor of lean manufacturing, which the Poppendiecks adapted to create lean software development.

At the heart of TPS is the idea that there are three types of waste that create constraints in the workflow and must be removed:

• Muda (無駄), which means “futility; uselessness; idleness; superfluity; waste; wastage; wastefulness”

• Mura (斑), which means “unevenness; irregularity; lack of uniformity; nonuniformity; inequality

• Muri (無理), which means “unreasonableness; impossible; beyond one’s power; too difficult; by force; perforce; forcibly; compulsorily; excessiveness; immoderation”

Anyone who’s been on a poorly managed, poorly run software project—especially one that used an ineffective process—is intimately familiar with the ideas of futility, unevenness, and unreasonableness. This is true of ineffective waterfall processes, but anyone who’s been on, say, a team that was only able to get better-than-not-doing-it results (or worse) by forcing Scrum or XP practices on a team with the wrong mindset will also recognize these things.

Do any of these things feel familiar?

• It takes a very long time to get everyone to sign off on a specification, and in the meantime developers are sitting around waiting for the project to start. Once it does start, they’re already late.

• It takes management forever to secure the budget. By the time the project is given the green light, it’s already late.

• Halfway through development, the team recognizes that an important part of the software design or architecture needs to be changed, but that will cause very large problems because so many other things depend on it.

• The QA team doesn’t start testing the software until every feature is complete. They find a major bug or a serious performance problem, and the team has to scramble to fix it.

• The analysis and design take so long that by the time coding begins, everyone needs to work nights and weekends to meet the deadline.

• A software architect designs a large, beautiful, complex system that’s impractical to implement.

• Even the smallest change to a specification, a document, or a plan needs to go through a burdensome change control process. People find ways to work around the process by putting even sweeping, large-scale changes into a ticketing or bug tracking system instead.

• The project is running late, so the boss adds extra people to the team for the last few weeks. Instead of making the project go faster, this move creates confusion and chaos.⁶⁹

Think back to your own projects that ran into problems because of things that you knew were stupid. They may have been stupid rules that you had to live with (or work around) that were imposed by a boss or were part of your company’s culture. Maybe there were stupid, unnecessary deadlines that were arbitrarily set in order to motivate you.

These things aren’t random. Take a minute to look back at the definitions of muda, mura, and muri. Then look at the list of familiar project problems, as well as the problems you’ve seen on your own projects. See if you can fit each of these problems into one of these three categories. Were there things you had to do that were futile, useless, or superfluous? This is muda—work you had to do that didn’t add value. What about times when you were sitting around idle, anxiously waiting for someone to get back to you so you could get your work done? This is mura—unevenness, or work that happens in fits and starts. Those times that you had to stay late or work weekends because you were expected to do more work than was humanly possible? That’s muri—overburdening, or being expected to do unreasonable or impossible things.

Even though there are many differences between software development and car manufacturing, the Poppendiecks recognized that these ideas from lean manufacturing also affect software projects. So it stands to reason that if software teams face problems similar to those in manufacturing, the solutions that worked for manufacturers will also work for software teams. For manufacturing, that solution is a pull system (also known as “just-in-time production”).

The manufacturing team at Toyota in the 1950s, led by engineer Taiichi Ohno, recognized that it was difficult to predict in advance which parts would be in short supply in the future—it often seemed like different parts were in short supply. This was an important root cause of waste (muda, mura, and muri). So they came up with a system where stations on each assembly line would signal that they’re ready for more parts, with a team set up to deliver parts based on those signals. Each station would have a small queue of parts that they needed. Instead of having a warehouse that pushed parts onto a line, they had a line that pulled parts from a warehouse, and only took parts when the queue got low.

This is called a pull system because it consists of independent teams or team members that pull only those parts that they need (rather than having a large stockpile of parts pushed on them and routinely topped off). Toyota and other car manufactures found that it made their entire assembly process much faster and cheaper, because it cut out a huge amount of waste and waiting time. In fact, every time a specific bit of waste was identified, they were able to make a small change to their process in order to eliminate it.

Pull systems are very useful for building software—maybe not surprisingly, for exactly the same reason that they’re useful in manufacturing. Instead of having users, managers, or product owners push tasks, features, or requests down to a team, they’ll add those requests to a queue that the team pulls from. When work backs up and causes unevenness partway through the project, they can create a buffer to help smooth it out. The team may have several different queues and buffers throughout their project. And as it turns out, this is a very effective way of reducing waiting time, cutting out waste, and helping users, managers, product owners, and software teams decide on what software is built.

Here’s a very simple example of how a pull system might solve a familiar problem: the software team that has to wait until every single feature is written into a large specification that must then go through a cumbersome review process. Maybe the process is a way to get all of the perspectives from every person; it may just be a way to provide CYA to bosses and stakeholders who are afraid to make a real commitment; or it might just be how the company always did business, and it never occurred to anyone that it’s wasteful. What would it look like if we replaced this with a simple pull system?

Figure 8-10. This value stream map shows the waste that happens when the team is waiting for a large specification to be created and approved.

This is a very familiar problem, and in the real world many teams have found ways to work around it. For example, the designers and architects might do “prework” based on an early draft of the spec, and their best guess as to what they’ll eventually be building. But while the team will find ways to eliminate the waste from the project—“shooting stupid when it enters the room”—they can only do so much. There will still be waste, often a lot of it, especially if they guess wrong and now have to undo some of the prework.

A pull system is a better way to remove this unevenness and prevent the overburdening.

The first step in creating a pull system is to break the work down into small, pullable chunks. So instead of building a large spec, the team can break it into minimal marketable features—say, individual stories, and maybe a small amount of documentation to go with each story. Those stories would then be approved individually. Typically, when a spec review process is held up for a long time, it’s because people have problems with some of the features. (Can you see how breaking the work down into smaller MMFs gives the team more options? That’s options thinking.) Approving individual MMFs should allow at least a few features to get approved quickly. As soon as the first MMF has been approved, the team can start working on it. Now the team doesn’t have to guess. Instead, there’s a real discussion of the work that needs to be done. There may be a real reason for the approval process (like a regulatory requirement, or a genuine need to get everyone’s perspective); now the team can get a real sign-off before starting the work.

This is how all the parts of lean thinking—seeing the whole, identifying the waste, and setting up a pull system of eliminate the unevenness and overburdening—can come together to help a team improve the way they do work. But that’s just the beginning. In the next chapter, you’ll learn about how to apply the mindset of Lean to improve the way your team builds software.

Here are a few things that you can try today on your own or with your team:

• Identify all of the MMFs on your project. How are they managed? Do you write user stories on cards or sticky notes and put them on a task board? Do you have individual requirements in a specification? Find a larger feature or story and see if you can break it down into smaller chunks.

• Look for waste in your project. Write down examples of muda, mura, and muri.

• Find any MMFs that you and your team completed already and create a value stream map for them. See if you can get your whole team to do it together. Then create a value stream map for another MMF. What are the similarities and differences between the two value streams?

• Find a bottleneck that your team routinely hits. (Your value stream map can be very helpful for doing this.) Have a discussion about what you can do to alleviate it in the future.

• Look at the dates that you and your team are currently committed to. Have you really made the commitments that you think you’ve made? Are there options to deliver something different, while still meeting those commitments?