In the previous two blogs I made a compelling case for Lean Product Development being the business opportunity of the century, and then gave an example of how and why we focused on the wrong end of the value chain. Hopefully by now you’re convinced that some form of Lean or Agile product development process is worth pursuing. But let me warn you about what you’re about to find…
There are dozens, if not hundreds, of options for starting points. And there are already stories of companies that have tried the wrong things and failed. That is tragic when you consider the opportunity that is being missed!
Even though Lean and Agile are fairly new topics in terms of hardware product development methods, there are already dozens of books on the subject. And because this is a new topic, there’s not a lot of consensus yet on where to start. Instead, there are a bunch of stories on what individual companies have done—and those stories vary a lot.
Why?
Well, here’s a partial list of topics you can choose from…
A3’s, Batch Sizes, Build Measure Learn, Cadence, Collocation, Constraints, Cost of Delay, Critical Chain Project Management, Decentralization, Early Learning, Fast Feedback, Flexible Product Development, Flow, Kanban, Knowledge Driven Product Development, LAMDA, Lean Six Sigma, Multitasking, OODA, PDCA, Project Economic Models, Queueing Principles, Rapid Learning Cycles, Risk Management, Scrum, Set-Based Concurrent Engineering, Standup Meetings, Value Stream Maps, Visual Project Boards, WIP Constraints.
And I’m sure there are many more that I left out.
With so many options to choose from, it’s no wonder there’s confusion. And while it’s impossible for me to say what’s best for your particular situation, I can share what we have found to be the most useful starting point.
I buy a lot of books—more than I have time to read. So if it’s a “good” book, I’ll actually finish it. If it’s a “really good” book it will have ideas in it that I’ll want to find later, so I’ll mark those pages with a piece of sticky note. Most of the really good books get just a few pages marked. However, Managing the Design Factory (MDF), by Don Reinertsen, has forty-six notes in it…! There got to be so many pages marked that I started putting the stickies on the side of the page so I could tell the new ones from the old ones.
And if you look closely, you can see I even used an orange card to mark what must have been the final good idea I found. I’m certain I read the whole book at least six times within the first year or two after buying it. And somewhere along the way I loaned it to Paul and Eric so I don’t really know how many times we read it altogether. But it was so many that the corners are worn out like a classic college text book.
Speaking of “text books”… As full as this book is with good ideas, there is another that actually beats it in terms of density. Don Reinertsen’s third book is called The Principles of Product Development Flow: Second Generation Lean Product Development.
Fortunately, he broke it into sections representing eight key principles of Lean. Each section has numbered principles, and there are 175 in all. (That would have been a lot of sticky notes!)
People often ask which they should read first. That depends on your experience with Lean Product Development and your reading and learning style. MDF is more like a typical book that’s easy to read. Flow is more like an encyclopedia where you can easily find information. But it’s also well written and Don Reinertsen speaks a little more strongly when he talks about how present day product development methods are backwards.
It would be difficult to outline the forty-six (or 175!) good ideas here, but I’ll briefly summarize what every product developer should know.
Don Reinertsen points out that we’re in business to make a profit, so decisions made during the development process should be made by considering how they’ll impact profit. This can be done by creating an economic model that everyone on the team understands and buys into. For most companies, the biggest impact to profit is the cost of delay.
With the importance of speed in mind, we need to understand what slows down projects. There are many causes, but a common one is that work sits idle for long periods of time (in a queue) before it’s worked on. These queues are caused by common practices that create large batch transfers of work that create large wait times. But they can be managed by reducing batch sizes. Closely related is the fact that high capacity loading has a serious impact on cycle times. But it can be managed with WIP constraints.
The R&D factory isn’t creating a product, it’s creating knowledge, which comes from information that is understood. So we need to optimize the rate at which we’re creating economically useful information. And we do that by studying information theory and systems theory.
One of the challenges that R&D has that manufacturing doesn’t is that most of the work is invisible, which makes it difficult to see the queues. And queues are leading indicators of system slowdowns so it’s important that we monitor them.
Finally, decentralization is a key principle for managing and optimizing complex systems.
As great as these ideas are, we borrowed a few other methods from other sources—Agile, and Theory of Constraints. I’ll give you time to start reading either of Don Reinertsen’s books and will cover these other two topics in my next post.
Stay tuned for Part 6 where we look at other key Lean Product Development principles.
If you’re wondering how Playbook utilizes these good ideas, you can watch a demo and look for these key points…
Guide to Lean Project Management
Guide to Lean Product Development
Science and economics behind “failing fast”
Lean Product Development the Opportunity of the Century.
Lean Product Development Case Study
Principles of Lean Product Development
Lean Product Development Value Chain
Get started with Lean Product Development
Lean Product Development: Cultural Resistance
4 ways to Ensure Your Lean product Development Initiative Won't Fail