Am 14. & 15. Oktober 2013 ist es so weit: An diesen zwei Tagen habt ihr wieder die Möglichkeit, einen Workshop mit Don Reinertsen zum Thema “Second Generation Lean Product Development – Applying the Principles of Flow” zu erleben. Dieses Mal quartieren wir uns im INNSide Eurotheum in Frankfurt ein und ich kann nur sagen: Nutzt die Chance! Wer die agile Produktentwicklung wirklich verstehen und selbst gestalten will (und nebenbei eine Wahnsinns-Aussicht über Frankfurt genießen möchte), kommt um die Arbeit von Don einfach nicht herum. Die Teilnehmer von Dons erstem Workshop für bor!sgloger im letzten Jahr waren begeistert und auch mir hat es in vielen Themenbereichen noch einmal so richtig die Augen geöffnet. Ganz abgesehen davon, dass man mit Don wirklich viel Spaß haben kann :). Alle Details zu diesem Profi-Workshop und die Möglichkeit zur Anmeldung findet ihr übrigens hier.

Ich habe hier als kleinen Vorgeschmack ein Interview ausgegraben, das ich letztes Jahr mit Don vor dem ersten Workshop geführt habe.

When talking about the foundations of agile methods we usually refer to the Toyota Production System as providing key insights for redesigning knowledge work. Now we have reached the point of common understanding that what we are doing with frameworks like Scrum belongs to the world of product development. What are the main differences between lean product development and lean manufacturing?

Don Reinertsen: Lean product development is using the logic of lean manufacturing in the domain of product development. This requires understanding why lean manufacturing methods work and adapting these methods to the domain of product development. Because the domain of product development is quite different from the domain of manufacturing there are big differences in how these methods are used.

Manufacturing prod©torstenweidmann.com_20120416-106uces physical objects. It can make lots of money by producing an identical product every time. In product development we produce the recipes for products. If we produce the same recipe twice we have wasted our money. To innovate we must change the design, and changing the design introduces uncertainty. Eliminating uncertainty is critical to the success of manufacturing; adding valuable uncertainty is critical to the economic success of product development. The differences in economic leverage points affect which lean methods will be useful in product development.

The methods of lean product development can be grouped into three categories. In the first category there are lean manufacturing methods like WIP constraints and batch size reduction that can be applied with very little modification. The main challenge in using these ideas is learning to recognize how they apply to product development. It is easy recognize the batch sizes and WIP levels for the physical objects handled by manufacturing. It is more difficult to recognize batch sizes and WIP levels when they consist of  information which is intrinsically invisible.

In the second category are lean manufacturing methods that are potentially toxic to product developers. This includes ideas like eliminating all variability and using First-In-First-Out (FIFO) prioritization. Such ideas are a perfect fit with repetitive manufacturing where flows are homogeneous but they can do significant economic damage in product development. In lean product development it makes more sense to create processes that function well in the presence of variability and to prioritize work using non-FIFO approaches.

Finally, the third category of lean product development methods comes from domains outside lean manufacturing. The use of methods from outside domains is what distinguishes what we call Second Generation Lean Product Development from First Generation approaches which simply tried to copy the behaviors of lean manufacturing. These enhanced methods come from domains like telecommunications and computer operating systems, domains that routinely deal with non-homogeneous flows and high variability. Solutions from these domains are often much better suited to product development than lean manufacturing ideas.

So, in summary, lean product development differs from lean manufacturing in its economic objectives, in which methods it uses, and in how it uses these methods.

Why has effort estimation proven to be not as less useful than managing the aggregate WIP of a process?

Don Reinertsen: There are cases in which effort estimation is useful, however in many cases its benefits are low in relation to the effort involved. Imagine you are running a coffee shop like Starbucks. You roughly estimate the amount of work required for each individual customer. You assign a group of customers to a “sprint” and monitor the work to see if your baristas complete each group on time.©torstenweidmann.com_20120416-114_groekorr Any shortfalls are carefully analyzed at the end of each “sprint.” There is a cost associated with managing this way. You may assign one of your three baristas interview customers as they get in line and to assess work content of their order. You may assign another barista to analyze the backlog, assign it to “sprints,” predict the number of customers that will be served by the end of the “sprint,” and conduct retrospectives. Finally you may assign your third barista to serve coffee. The question you must ask is whether your investment in planning and estimating has created more benefit than you would get by having two more baristas available to serve coffee.

When the size of work items is quite small, as it is in this case, the benefits of estimation can be smaller than the cost. In such cases, managing aggregate WIP may be more effective. For example, at Starbucks we might not attempt to estimate the work associated with any individual customer, but instead set a WIP constraint of 12 customers. Whenever there are more than 12 customers in line we have all 3 baristas working, and even get the store manager to help as well.

In contrast, when the average size of work items is large, when they differ significantly in size, and when their size is feasible to predict, then estimation can produce larger benefits. Estimates of task duration can help us make better choices in work sequencing and it gives us a tool to throttle demand to prevent downstream congestion.

My point is that both WIP constraints and estimate-based systems have useful applications. It is wise to judge them on their costs and benefits in a particular situation, rather than to assume either one is always superior.

Do traditional project management and lean product development fit together? Or are these different ideas which we need to distinguish?

Don Reinertsen: At a certain level of abstraction traditional project management operates on an axis that is orthogonal to lean product development. In traditional project management we try to manage everything using the “horizontal” axis of timelines associated with project activities. We create a plan, and intervene to ensure performance matches the plan. This makes us very dependent on the quality of the initial plan, and makes it hard to respond to variability. Lean product development can be viewed as operating on the “vertical” axis of processes.  Rather than focusing on the testing tasks of each individual project we focus on managing a pool testing work which is derived from multiple projects. If we can manage this work well we can prevent queues. If we prevent queues, then timelines improve.

Let me use an analogy. Imagine we were managing the flow of cars into a major urban area. We could construct a timeline for each vehicle and try to manage the progress of each vehicle towards its destination. This is managing the “horizontal” timeline axis. Alternatively, we could recognize that congestion occurs in very specific areas along the route. We could monitor these areas that are prone to congestion and develop ways to©torstenweidmann.com_20120416-045_groekorr improve their flow. This focus on specific zones of the timeline, zones that are shared among many vehicles, is managing the “vertical” process axis. This is a fundamental difference between project management and process management.

It is useful to distinguish between these two approaches, but it is important to recognize that they are complementary rather than competitive. As you use process management to improve the management of queues you will discover that project management becomes much easier.

Can you give us a hint how your ideas about lean product development help ScrumMasters and Product Owners to understand and do their job better?

Don Reinertsen: Let me focus on one of the central tools of the course: the project economic model. This is a tool that allows you to calculate the financial cost of time on the critical path of a project. Is a month of delay worth €1,000,000 or €1,000? Approximately 85 percent of product developers cannot answer this simple question. As a result, when they make decisions to buy cycle time they have no basis to justify their choices. A project economic model provides a way to quantify the value of what we call “proxy variables.”  These are interacting goals like product cost, development expense, schedule, and product performance. Since these goals often conflict with one another we must express them in the same unit of measure to make tradeoffs between them. This is what a project economic model allows you to do.

Today, I find that most ScrumMasters and Product Owners are poorly equipped to discuss the economic consequences of their choices. They make philosophical arguments rather than economic ones. This places them at a disadvantage when communicating with management, because the preferred language of management is economics. This is where a project economic model is a big help. When you understand the economics of your project you can both make better economic choices and you can more easily and efficiently communicate the logic of these choices to higher levels of management.

„Mut“ ist jener Wert von Scrum, mit dem sich Boris Gloger am stärksten identifiziert. Er hat in seinem eigenen Leben keine Angst vor radikalen Entscheidungen und vor dem Glauben an eine Idee. Für kein Geld der Welt würde er sich Regeln unterwerfen, die keinen Sinn machen. Er glaubt an Scrum, weil es nicht nur bessere Produkte, sondern auch eine bessere und menschlichere Arbeitswelt schaffen kann.