I owe a special thanks to Don Reinertsen, both for the influences of his recent, groundbreaking book Principles of Product Development Flow: Second Generation Lean Product Development, and for writing the foreword to my book, which is included below.
====================================
by Don Reinertsen
Why do product development projects miss their economic objectives? Studies show that 80% to 85% of project failures are due to incorrect requirements. Experienced developers know that managing requirements is a greater challenge than technical execution. And, although we have known this for decades, we really haven’t gotten much better at it. Why? At first, we were functionally organized, so we simply displaced the problem outside the boundary of engineering—we blamed marketing and product management. Later, as we adopted cross-functional teams, we told these teams to listen to the voice of the customer and assumed that this would solve the problem.
It didn’t. We never challenged the idea that it was feasible to develop valid requirements up front—we just told people to try harder. We just told them to pay more attention to what the customer was asking for. We ignored the fact that many customers don’t know what they want. We ignored that fact that even when they know what they want, they can’t describe it. We ignored the fact that even when they can describe it, they often described a proposed solution rather than the real need. For example, customers told us that they wanted suitcases that were easy to carry and asked us to make them lightweight. We did this, but they rejected our elegant designs and bought the heavier designs of our competitors—the ones with wheels on them!
The sad truth is that there is no one “Voice of the Customer.” It is a cacophony of voices asking for different things. Even at a single customer, we need to balance the needs of technical decision makers, end users, system operators, and financial decision makers. All of these actors weigh different attributes differently, and they change their weighting as they acquire more experience using the product. We also need to understand the needs of distributors, regulators, manufacturing, and field service. If we focus only on the user, we could miss what Dean calls the “nonfunctional requirements.”
And this problem is dynamic, not static. In the course of our development effort, the context constantly changes; competitors introduce new products, and customer needs evolve. If it is not feasible to develop valid requirements before we begin design, what is our alternative? In my opinion, we should start with the belief that that even the best requirements will contain major errors and that these errors grow exponentially with time. This shifts our focus. Instead of believing that we are hearing a high-fidelity signal coming from the customer, we recognize that it is a noisy, low-fidelity signal—a signal that must be continually checked for errors. Rather than using heavy front-end investment to create perfect requirements, we invest in creating processes and infrastructure that can rapidly detect and correct misfits between our solution and the customer’s evolving needs.
What better test for this alternative approach than the development of large systems? Many of the methods that work superbly on small projects break down on large ones. For example, in small systems, costs and benefits are typically local. System performance does not suffer when a team makes locally optimal decisions. This is not true for large systems where we must deal with economic effects that are dispersed physically, temporally, and organizationally.
We need better approaches to understanding and managing software requirements, and Dean provides them in this book. He draws ideas from three very useful intellectual pools: classical management practices, agile methods, and lean product development. By combining the strengths of these three approaches, he has produced something that works better than any one in isolation.
First, although it might be unfashionable to say this, classic management practices still offer us some very useful methods. Not all of our predecessors were stupid dolts, incapable of recognizing a working solution. For decades I have seen relatively simple concepts such as technology and product roadmaps producing great results. They ensure work on technology begins early enough to keep it off the critical path. They create strong logical links between technology efforts and the programs that they serve. We don’t need to blindly accept all traditional practices, but we’d be foolish to rediscover everything our predecessors already learned. Dean shows you how to apply some of these great ideas at the program and portfolio levels.
Second, the agile community has developed a very powerful set of ideas that has already produced impressive results. These methods have grown rapidly for very good reasons—they work. Agile decomposes the large batches of the waterfall model into a series of timeboxed iterations. These smaller batches dramatically accelerate feedback, producing enormous benefits.
Since much of Agile’s success has occurred in smaller projects, it is natural to ask whether it is equally useful in large systems. While I deeply respect the value of agile methods, I think Dean is correct in recognizing that these methods must be extended to meet the needs of large system development. It is quite risky to assume that large system architectures will naturally emerge and that any shortcomings can be refactored away. For example, a naval warship is designed for a 30-year operating life. Good naval architects anticipate evolving threats, emerging technologies, and changing missions. We do not create such systems by letting architecture “emerge.” Once we recognize the unique challenge of managing at the system level, we can start investing in the organizational infrastructure needed to meet this challenge. Dean shows you how to do this with agile method extensions such as architectural runways.
Dean also draws upon the ideas of what I call “second-generation lean product development.” Many of the initial attempts to use lean in product development focused on ideas such as standardization of work and variability reduction. They lacked agile’s intrinsic appreciation that developing great new solutions requires learning to thrive in the presence of uncertainty. These lean product development methods have now evolved, and the results are impressive. For example, today’s “kanban” approaches are limiting WIP, accelerating feedback, and making flow visible to all participants. You can see the influence of these ideas on Dean’s approaches at the program and portfolio levels. Dean has also recognized the importance of the new emphasis on economics. This emphasis helps us make better decisions, and it enables us to explain our choices to management in terms they readily understand.
As you read this book, I suggest paying attention to several things. First, try to understand the reasons why certain of these approaches work, not just what they are. If you understand why things work, then you can more easily adapt them to your own unique context. Second, treat these ideas as a portfolio of useful patterns rather than a rigid set of practices that must be adopted as a group. This will reduce the batch size of your adoption process, produce less resistance, and provide faster results. Finally, as you use these ideas, strive for balance. You will have a natural tendency to prefer certain ideas; they address issues you feel are important, and they feel comfortable. You may have given other areas little attention for a long time. Often the areas that have received little attention hold great untapped opportunity.
Don Reinertsen
Redondo Beach, California
July 19, 2010
Author of :
The Principles of Product Development Flow: Second Generation Lean Product Development
Scaling Software Agility 