Tag Archives: lean

Resources on Set-Based Design

yellow woods

“Two roads diverged in a yellow wood,

yet I could travel both.”

—Not Robert Frost

 

A reading list on set-based design (part of lean product development).

 

Applied Fluid Technologies. Information on boat design.

 

Baldwin, Carliss, and Kim Clark. Design Rules, Volume 1: The Power of Modularity. MIT Press, 2000. ISBN 0262024667. Modularity and platforms, from a somewhat economic perspective; not overly focused on software modularity. (No volume 2 yet:(

 

Kennedy, Michael. Product Development for the Lean Enterprise: Why Toyota’s System is Four Times More Productive and How You Can Implement It. Oaklea Press, 2008. ISBN 1892538180. Business novel, touches on set-based approaches. 

 

Kennedy, Michael and Kent Harmon. Ready, Set, Dominate: Implement Toyota’s Set-Based Learning for Developing Products, and Nobody Can Catch You. Oaklea Press, 2008. ISBN 1892538407. Second novel, also touches on set-based approaches. 

 

Morgan, James, and Jeffrey Liker. The Toyota Product Development System. Productivity Press, 2006. ISBN 1-56327-282-2. Overview of lean product development, touches on set-based approaches. 

 

Poppendieck, Mary and Tom. "Amplify Learning." The importance of communicating constraints (rather than solutions) in set-based development. 

 

Shook, John. Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead. Lean Enterprise Institute, 2008. ISBN 1934109207. A3 reports as the heart of lean management.

 

Sobek II, Durward, Allen Ward, and Jeffrey Liker. “Toyota’s Principles of Set-Based Concurrent Engineering,” Sloan Management Review, Winter, 1998. Basic description and principles of the approach. 

 

Wake, Bill. “Set-Based Concurrent Engineering.” Overview of several variations of set-based design in software. 

 

Ward, Allen, Jeffrey Liker, John Cristiano, Durward Sobek II. “The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster,” Sloan Management Review, Spring, 1995. Looks at how set-based concurrent engineering lets Toyota do better than other carmakers. 

 

Ward, Allen. Lean Product and Process Development. Lean Enterprise Institute, 2007. ISBN 978-1-934109-13-7. Description of knowledge waste, set-based concurrent engineering, and a different view of the PDCA cycle.

 

This is based on a list originally prepared for Agile 2009 by Bill Wake and Jean Tabaka.

Review – The Principles of Product Development Flow (Reinertsen)

The Principles of Product Development Flow: Second Generation Lean Product Development, by Donald Reinertsen. Celeritas Publishing, 2009.

Lean product development can be looked at as flow-based product development. Reinertsen draws on a variety of areas (economics, queue theory, control theory, the military) to explore the consequences for product development. The book is organized as 175 principles, organized into chapters by area. Here are a couple examples: “B2: The Batch Size Queueing Principle: Reducing batch size reduces cycle time”; “F8: The Cadence Batch Size Enabling Principle: Use a regular cadence to enable small batch sizes”. Each principle gets a page or two of explanations; the diagrams are plentiful and helpful. (For an introduction to the topic, I still recommend Reinertsen’s book Managing the Design Factory.)

Set-Based Concurrent Engineering

One of the ideas in lean product development is the notion of set-based concurrent engineering: considering a solution as the intersection of a number of feasible parts, rather than iterating on a bunch of individual "point-based" solutions. This lets several groups work at the same time, as they converge on a solution.

People trying to describe Toyota's product development process seem to have settled on "set-based concurrent engineering" as a term for one key part. They see the approach as set-based because it's built around the idea of finding a solution as the intersection of a set of feasible choices, and it's concurrent because teams are trying to work "all at once," not in a sequential, hand-off style.

Reading the book The Toyota Product Development System has me considering these notions again. You can also see the Poppendiecks' Implementing Lean Software Development for more on this idea.

Twenty Questions

You probably know the game of 20 Questions. Let's try it "point-based":

I'm thinking of something.
Is it animal, vegetable or mineral? Animal.
Is it a schnauzer? No.
Is it a parakeet? No.
Is it a goldfish? No.
Koala? No.
Mini-lop rabbit? No.
Blue-tailed skink? You got it.

Instead, let's use a "set-based" approach:

I'm thinking of something.
Is it animal, vegetable or mineral? Animal.
Is it bigger than a breadbox? No.
Is it a mammal? Yes.
Is it a dog? Yes.
Is it curly-haired? Yes.
Is it a standard poodle? You got it.

The point-based approach proposes a solution, and then iterates by revising to a different point. In real design, there's more feedback than in the first game above, of course. But the point solution is in effect treated as "the right answer." If we find out it's not right, we move to a different point.

A set-based approach takes a different path. Instead of moving to a solution right away, it starts with options open, then narrows in on a solution.

Why might we want to take the set-based approach? Because it lets us:

  • defer decisions until the "last responsible moment," when we have the best information;
  • explore many possible designs at the same time; and
  • converge designs more quickly.

We'll look at three ways that software can use a set-based approach.

1. Consciously explore alternatives

One approach is to identify several alternatives, and spend energy to spike and/or analyze the choices. For example, should we use C++, Java, or C#? Should we use an object database or a relational database? Quicksort or insertion sort or radix sort or …?

In lean product development, they use tradeoff curves to record their findings. (See The Toyota Product Development System for more.) That's inspired me to produce the following diagrams. See the wikipedia article on sorting algorithms for many more algorithms and a fuller discussion.

 

 

Comparison-Based Sorting Algorithms

Algorithm O(n) O(n log n) O(n1.5) O(n2) Stable?
Bubblesort B     W yes
Selection sort       BEW no
Insertion sort B     EW yes
Shell sort     W   no
Heap sort   BEW     no
Quicksort   BE   W no
Key: B=best-case, E=expected-case, W=worst-case.
Default choices are italicized.

 

 

Here's another view of the same information:

You might make a matrix comparing several choices: (fake values; you're on your own here:)

 

 

Persistence Mechanisms
Approach Cost Familiarity Support Performance Risk
Hibernate Low Med Low Med to High Med
Custom layer Med High Med Low to High High
Toplink Med Lo Hi Med to High Med
etc.          

 

 

In each of these cases, we spend time identifying and exploring the alternatives, then strive for a clear, succinct way to present the tradeoffs involved.

These summaries can help you narrow in. For example, we might decide early on that we need sorting. A later decision might highlight that stable sorting is important. This would cut down the number of algorithm options. A later decision might highlight the need for consistent performance, cutting our options even more, until we're to the point where we can choose an algorithm.

This approach, of exploring, recording, and narrowing alternatives, feels closest in spirit to the Toyota product-development approach.

2. Consciously enable alternatives

A second approach is to use modularity: create designs that explicitly enable different alternatives. The book Design Rules, Volume 1: The Power of Modularity, by Baldwin and Clark, explores modularity from a non-software-specific point of view; Design Patterns (Gamma et al.), Pattern-Oriented Software Architecture (Buschmann et al.), and many other pattern and software books consider modularity from a software perspective.

Many examples of modularity are based around the ideas of abstraction and of an interface: two parts make a commitment to how they will "talk" to each other, but no commitment about what happens beyond the interface. Consider these examples:

  • Service-oriented architecture. For example, two systems communicate via SOAP, with no commitment about what technology or tool will be used on either side.
  • Network protocols.
  • Plug-in architecture.
  • Layered architecture.
  • Adapter design pattern.
  • Bridge (driver) design pattern. For example, we commit to using a JDBC driver but don't commit to whether we'll use SQL Server, MySQL, or Oracle.
  • Abstract class.
  • Machine-independent language.

Each of these patterns represents a "move" that is consciously leaving room for a set of alternative designs.

3. Incremental design as not blocking alternatives

Gordon Bell said, "The cheapest, fastest, and most reliable components are those that aren't there." Simple design (in the XP sense) suggests, "Don't add anything until you have a failing test that demonstrates you need it."

Each part you add removes flexibility – it either interferes with what you might have done instead, or it becomes dead weight, dragged along even though nothing needs it. And yet, if we don't add parts, our software doesn't do anything.

For example, you've decided on a persistence approach. You could "build the persistence layer," mapping out all objects from all the tables you already have. This creates a "point-based" solution – this is the way persistence works. It creates a drag, from the effort spent on objects you don't need yet. Each of those objects will have to be tested, refactored, and maintained, against that possible day in the future when all that work may finally pay off.

Instead, an incremental design might commit us a little now, but it leaves to the future the set of all possible ways to implement the objects based on the current structure. If we get an idea for a better approach, unmapped objects are free to use it when it's time to map them. (And if the whole approach becomes rejected, we only pay to change objects that were already needed.) 

I think of a simple design as set-based in this sense: Consider the program we have, doing just enough to support the current set of features. Some aspects of this program are a commitment to a particular design. But there is a set of programs out there – all those programs that extend the current program in a way compatible with the current design. By using "just enough design" – not implementing parts not needed to support functionality, we don't eliminate those programs that would evolve in a different way to support those future parts. By contrast, if we fully elaborate an implementation to support our guesses about future directions, we in effect are betting on a point solution, not a set of possible evolutions.

4. Carry Forward with Multiple Implementations

Kent Beck wrote:

I think there is another strategy that also fits the bill–duplicate implementation. The example that brought this home to me was a client of [someone]’s who reported that they were trying to decide between an HTML interface or a rich client interface. [His] advice was to implement both, keeping them in sync every iteration until it was clear which one was most valuable. The client said that they couldn't stand the idea of wasting all that effort, so they picked early and later regretted it.

This is the kind of strategy that is only possible when you have slack programming capacity, enough so you don't mind applying some to risk reduction.

This approach goes further than the first one – rather than evaluate the alternatives and make a guess, we carry forward on multiple implementations, thus seeing the real impact of our decisions.

Conclusion

There are several different design approaches that yield aspects of a set-based design:

  • exploring alternatives (and recording and using the results of that exploration)
  • designing in mechanisms that support alternative designs
  • committing to the minimal level of current design, to leave room for a variety of future designs
  • carry forward with multiple implementations

By applying these tools, you can help match the level of commitment to your solution to the level of understanding you have in the constraints surrounding it.

Resources

Further Reading

[November, 2006. Updated 12-20-2006 with Kent Beck’s fourth strategy. Updated 1/4/2014 to add link to more resources.]

Review – The Toyota Product Development System

The Toyota Product Development System, James M. Morgan and Jeffrey K. Liker, Productivity Press, 2006.
Toyota's lean manufacturing system has had a lot of press, but lean influences their product development approach as well. This book emphasizes the system aspects of their approach. Along the way it explores a variety of practices and tools: set-based approaches, use of a chief engineer, alignment, and more. I preferred this book over Kennedy as it feels both broader and deeper. (Reviewed Nov., '06)

Alistair Cockburn on Bottlenecks

"Two Case Studies Motivating Efficiency as a "Spendable" Quantity", by Alistair Cockburn.

A bottleneck limits the rate of production of a system. Clearly we want to improve its performance. But what should we do about non-bottlenecks? Alistair discusses several strategies, including the non-obvious one that the non-bottleneck may be better off deliberately spend extra time exploring alternatives before feeding into a bottleneck. He points out that there’s no single strategy that always works; it’s context-dependent.

Review – Lean Solutions

Lean Solutions, James P. Womack and Daniel T. Jones. Free Press, 2005.
These are the authors of The Machine that Changed the World. (The “machine” was lean production.) In this book, they expand on the idea of “lean consumption.” Their idea is that if consumers and businesses can better share information about current and future wants and needs, companies can build a supply chain that will have a lot less waste, and be simpler for everybody. This book is the background for their March, 2005 article in Harvard Business Review, expanding it with a number of examples in different industries. (Reviewed Sept., 2005)

Review – Product Development for the Lean Enterprise

Product Development for the Lean Enterprise, Michael N. Kennedy. Manning, 2004.
Toyota’s lean manufacturing gets a lot of attention. But there’s also a Toyota approach to product development that’s less well known (though Mary Poppendieck does talk about it). This book uses a “business novel” plus discussion approach which I found unnecessary. But the story did bring out key ideas: knowledge-based development, set-based concurrent engineering, and more. (Reviewed May, ’05)

Review – Office Kaizen

Office Kaizen: Transforming Office Operations into a Strategic Competitive Advantage, William Lareau. ASQ, 2003.
This book applies lean ideas to office work. Many of its ideas will be familiar to people in agile, but applied in the non-software world: charters, daily work group meetings, visual displays, and so on. Other ideas may feel less comfortable, e.g., numerical assessment. I particularly like that the explanation of waste has a number of categories added to cover intellectual work, and the attention to the challenges of transforming organizations.
(Reviewed Jan., ’05)

Push-Line/Pull-Line

Goal: Demonstrate the difference between push ("batch") and pull ("lean") approaches to assembly lines.

Time: ~30 minutes.

Preparation

  • Get ~50 sheets of white paper and a couple of pieces of yellow paper.
  • Set up four people at stations in a line, with a work area in front of each. The area between stations is the input/output area. A’s output area is B’s input area.
  • Teach the folders how to make an origami bird or a paper airplane. Arrange it so the first folder has a trivial job, the second folder has a fairly easy job, the third folder has to do the most work, and the last person has another trivial job (e.g., toss the airplane toward a target).
  • Explain that we’ll be using two different sets of work rules.
  • Start the line with the “push” rules, let the system run a while, and then stop them. Switch to the “pull” rules, let it run again, stop everybody, and debrief.

Push Rules ("Batch")

Each person uses the same rules:

  • If your work area is empty, take an item from your input area and work on it.
  • When you finish an item, put it in your output area.

Once a significant amount of work has piled in front of the third station, have the first station start to work on a yellow piece of paper and stop the system.

Pull Rules ("Lean")

Each person uses the same rules:

  • If your output area is empty and your work area is empty, take an item from your input area and work on it.
  • When you finish an item, put it in your output area.

Once a few items have come through, put a yellow piece of paper in and stop the system.

Debrief

What happened?
Bring out these points:

  • There were piles of inventory in the push system, no piles in the pull system.
  • Most everybody (except the person at the end) stayed busy in the push system; people were waiting around in the pull system.
  • The bottleneck person was equally busy in both cases.
  • The system output was at the same rate in both cases.
  • The yellow paper was way back in the push system.

Productivity

  • What is everyone’s productivity?
  • What is the system’s productivity?
  • Are they different?
  • How long from when a piece of paper starts until it pops out the other end?

What is waste in the two systems? The push system has wasted inventory and time wasted in work that’s not needed.

How can we improve?

How does this relate to software?

  • Whether everybody is busy or not says nothing about the productivity of the system as a whole.
  • Optimizing one part doesn’t optimize the system.

Could we get the system into balance…and keep it there?

How does each system respond to “shocks”?

What if…?

  • …we switched to making a different object (e.g., birds instead of planes)?
  • we used a batch size greater than one? (Will responsiveness improve?)
  • we had specialized developers?

Summary

  • Lean flow suggests a pull system, not a push system.
  • Constraints are exposed by people waiting (not by inventory piling up).
  • It’s not balance or batch size that determines whether the system is push or pull – it’s whether you’re driven by your input or your output.

Toyoda was inspired by three things in setting up lean systems:

  • knitting machines that stop automatically when there’s a problem
  • Henry Ford’s assembly line
  • American supermarkets where people push their cart around.

Rules Summary

Source:
[William C. Wake, 2004. This writeup was for the Scrum Gathering in Denver, October, 2004. I developed this exercise based on reading about lean manufacturing, but it turned out others have beaten me to the punch; see http://www.mba.wfu.edu/dsjie/Tips/billington.htm for an example. Added a picture of the rules, 9-11-2005.]

Review – Theory of Constraints

Theory of Constraints: What is this thing called Theory of Constraints, and how should it be implemented? Eliyahu Goldratt. North River Press, 1990.
Let me give my rare thumbs down review (usually I just ignore the ones I don’t like). I enjoyed The Goal a lot, but was totally disappointed by this book. Thirty of the 160 pages are copied from that book. The rest reads like an ad, with little technical material. Add in poor copy-editing and you have a disappointing combination.
(Reviewed Jan., ’04)

Lean Manufacturing and Software

Is writing software more like manufacturing cookies or more like designing cookie cutters? It's easy to wish that we could develop software like a factory stamps out cookies, but software has a design or creation element that is missing in that analogy.

But there are similarities: software is developed in stages, it is created in a process amenable to change, and it's developed in a team. Lean manufacturing is a different approach than a traditional assembly line, and offers some lessons for software development.

Value and Waste

A good starting point is to consider what value is, and what waste is.

What are things with value?

  • Raw materials
  • An end product that someone is willing to buy
  • Tools used by the team
  • The skills acquired by the team

What about intermediate products? They have some value in the sense that they give us the option to create the final product more cheaply than if we started from the beginning. They have no value if nobody is willing to buy the end result. And intermediate products clearly have a cost.

And what is waste?

If it doesn't add value, it's waste.
   –Henry Ford
 
Waste – anything other than the minimum amount of equipment, materials, parts, space, and worker's time, which are absolutely essential to add value to the product.
   –Fuji Cho, chief engineer at Toyota

Taiichi Ohno is known as the father of lean manufacturing, and he identified seven types of waste. We'll consider them and find an example of each applied to software:

Waste Software Example
Overproduction Features that nobody ever uses.
Waiting Time QA waiting for a feature to be written so they can test it.
Transportation Waste Time waiting for files to copy.
Processing Waste Software written that doesn't contribute to the final product.
Inventory Waste A feature for which development has started, but nobody is currently working on it.
Wasted Motion Doing a refactoring manually when the development environment can do it automatically.
Waste from Product Defects Bugs.

Ohno talked about a diagram of a boat that represents the pipeline translating raw materials to a finished product, traveling across the sea of inventory. Every waste in the system is like a hidden rock at the bottom of this sea, which may be a hazard to travel over, and which raises the level of the water and makes the boat travel further.

To make these rocks visible, we will lower the inventory. Then we can work to remove the visible rock.

A Traditional Line

Before we move to solutions, let's take a look at a traditional assembly line:

  

Visualize the first person as transforming raw materials (not shown) to A objects, which are passed down the line to someone who converts them to D's, then C's, then T's.

Kent Beck has pointed out that we can think of "undeployed decisions" as the inventory in software. If we think of A/D/C/T as Analysis, Design, Code, and Test, we have here a situation where the analysts are a bit ahead, the programmers are stuck waiting for some design, and the testers (with that pile of Code sitting around) are working on a backlog. (And when they communicate with the programmers, it's about something that was done a while ago.)

We speak of this as a push system: each worker produces their part, starting and finishing as soon as they can. Notice that the overall pace at which the system produces results is limited to the pace of the slowest worker.

We might try to balance the system: if everything is stable, and we get just the right proportion of workers, we might be able to create a balance. If there is any variability in the task size, this will be very tricky. Furthermore, in the software case, testing is often the part that's hardest to estimate, and it's the last step here.

The Solution

The lean approach has several techniques it uses to try to improve this overall system:

  • Radical Change ("kaikaku"), to get a factor of 10 improvement
    • Pull and Flow
  • Visual Control
  • People and Training
  • Incremental Change ("kaizen"), to get a further factor of 2 improvement

Radical Change to Pull and Flow

In the push system above, recall that the pace of the line is limited to the pace of the slowest step. A lean line lives with the same constraint. But the push line adds another constraint: everybody should stay as busy as possible, and we value high utilization of the workers.

Suppose the worker just before the slowest step were to first make the next piece that the slow step needs, and then sit around until there's just enough time to make the next piece ready when the slow step needs it. The overall pace of the line wouldn't change, but there'd be a lot less inventory sitting around at that stage.

The radical change is to put this discipline in place for the whole line: steps before the slowest step sit idle until they're asked for the next part. Steps after the slowest step will be idle when they're waiting for the slowest step, and busy otherwise.

The new approach is known as the pull approach: instead of making things when you're ready, you wait until the person after you requests it. When this discipline is in place, you have flow. To know when the person after you is making a request, many manufacturing lines use a card-based system of requests. You return the card along with the batch of items, so it can be reused.

Let's revise the line above to demonstrate flow. Think of a card as representing a request for action by the following step, and the circle as having the item currently being worked on.

In a lean line, every part in the system is there because someone needs to work on it. In effect, there's no other inventory.

Once flow is in effect, lean teams will continue to try to identify waste in the system, and try to improve the system further.

People

Nobody has incentives to make their own job go away. The lean approach recognizes this, and many teams will commit that nobody will lose their job because of future improvements.

To help people improve their own skills, some teams track via a job skill chart. It shows people's names on one axis, and skills on another. When someone has mastered a skill, a mark is put in the intersection. Some teams provide bonuses to people as they are certified in new skills, to recognize their effort and their increased value to the organization.

Teams may use job rotation as well: explicitly making sure that people get to do different jobs over time, so they maintain their skill in a variety of areas. It's easiest to balance work when people are able to be flexible about what they do.

Teams are given control over their process. They may work with management and experts to help revise and improve their process, but they have the responsibility for it.

A final approach lean teams may use is to develop smooth staffing, wherein the demand for products is managed to make the demand for people smooth. You can see signs of this in the software industry reflected in the attempts companies have made to move from a purchase model to a subscription model: a subscription must be paid when due, but a company may be able to avoid buying software by continuing to use an older version.

Visual Control

To make it easy for teams to know what is going on, lean lines use visual status indicators. (XP teams have an echo of this in their use of Big Visible Charts.) This way, everybody can see and agree on the data, and use their visual processing power to find trends and suggest ideas.

These charts may use color and position coding to provide information "at a glance." There's typically a wall or panel devoted to this information.

Another version of visual information is the use of lights on the top of equipment, indicating its status. When something goes wrong, someone can get there immediately and fix the problem.

Kaizen: Continuous Improvement

Once the radical changes have been made, a team will keep looking for improvements. (Agile teams using retrospectives are making a similar commitment.)

Teams will standardize their processes. They're willing to change them if they find a better way to do them, but until then they'll find the best way they can and apply it consistently. They'll document the process (often in a card at the workstation). The team seeks a better way: a way to simplify, combine, or eliminate steps.

Where possible a team will install foolproof mechanisms (poka-yoke) that make a part automatically move to the right position, or easily reject wrong parts. I see an analog of this in the way software teams apply tools such as configuration management systems, automated builds, and refactoring support. Keith Ray points out (here and here) that test-driven development is a form of poka-yoke.

Another improvement tool has become known under the name SMED: Single Minute Exchange of Dies. In car manufacturing, changing from making one part to another can be a lot of work. The traditional solution has been, "make a long run of parts after a die change," but this creates a lot of inventory. SMED encourages a team to be able to make a changeover quickly, so inventory is not necessary. For a software team, I wonder, "how quickly can you change direction?"

Even small things can help: teams focus on simple housekeeping. By keeping the area clean, it can be clear when tools or materials are out of place. Spending 5 minutes looking for a tool doesn't sound like much, but when you do it many times and in many places it adds up.

The last tool I'll mention is the ability of teams to "stop the line." Whenever a problem occurs, anybody is empowered to stop the line. When the line stops, people investigate. They do a root cause analysis by asking "why?" five times. Software teams can adopt this tool as well: make it a rule that anybody can ask for help or for the team's attention at any time, and don't settle for fixing immediate causes when you address a problem.

Application

So, ask yourself these questions:

  • How much work, that nobody is working on right now, do you have in your pipeline?
  • When a new requirement goes into the pipeline, how long does it take before it reaches the end?
  • Do you have a process for continually improving your process?

Further Reading

This paper has resulted from reading a lot of lean manufacturing literature, and relating it to what I do as part of a software team. The Machine That Changed the World, by Womack et al. describes lean from an auto manufacturing point of view. For lean approaches applied to software, I recommend Lean Software Development, by Mary Poppendieck and Tom Poppendieck. Kent Beck has also been a mover in this topic; there's a yahoo group, softwareinprocess for discussing it. A couple other books I recommend as starting points are Managing the Design Factory, by Donald Reinertsen, and Results from the Heart, by Kiyoshi Suzaki.


[Written October, 2003. Added pointers to Keith Ray's blog, 12-7-03.]

Bill Wake is the author of the Refactoring Workbook, and Extreme Programming Explored. He works as a software coach and trainer. Contact him at William.Wake@acm.org or 1-804-519-6799.

Review – Lean Software Development (Poppendieck and Poppendieck)

Lean Software Development: An Agile Toolkit. Mary Poppendieck and Tom Poppendieck. Addison-Wesley, 2003.
This book considers software development from the perspective of lean manufacturing, as popularized by Toyota. In lean approaches, there is a sense in which there is a constant striving to reduce all forms of waste, and by delaying decisions as long as possible (but no longer), we can reduce our need for inventory in all its forms.
The book is a toolbox for software managers – 22 tools in all, including such things as “The Last Responsible Moment,” “Iterations,” and “Leadership.” Though they have synergy, you can read most of them fairly independently.
I recommend this book; in addition to a set of useful tools, it will give you a way to tie ideas from agile software development to the broader trends in lean development. (Reviewed August, ’03)

Review – Thinking Beyond Lean

Thinking Beyond Lean, Michael A. Cusumano and Kentaro Nobeoka, Free Press, 1998.
The subtitle is “How multi-project management is transforming product development at Toyota and other companies,” and that pretty much says what it is. Once you have lean approaches, how do you balance your whole set of product lines? Do you treat them as independent projects, or transfer technology between them? The authors suggest that this should be a considered decision, and also suggest that a concurrent transfer need not be as problematic as you might expect (though it can be carried too far). This is definitely not the first book you should read on the subject of “lean,” but it does address a real concern, described in the context of the automobile industry. (Reviewed May, ’03)