Playbook_Logo.png
Free Trial
Watch Demo

David Paulson

CEO

Inquisitive, provocative and results oriented, David is willing to dig into problems until their true essence is understood and the solution is executed. We love that at PLAYBOOK!

Search Result

Posts containing:

Lean Product Development (part 6): The other key principles...!

David Paulson- 04/25/17 05:00 PM

In my previous blog post I introduced two of Don Reinertsen’s books and explained how they contained dozens and dozens of great ideas around Lean Product Development and Flow principles. Either of those books would keep you busy for a long time and have enough content to make great improvements in any new product development process. But as good as they are, we found a couple other sources that contribute greatly to the big impact as well.

Note, this is Part 6 of a Series of posts on Lean Product Development. In part 1, we cover the science and economics behind “failing fast” and the optimum rate of failure when learning. 

In part 2, we discuss why Lean product development really is the opportunity of the century. 

In part 3, we share an incredible case study that demonstrates the unexpected results that can be achieved when you apply the proper set of Lean product development principles. 

In part 4, we discuss the Lean product development value chain and why in hardware development we have spent too much time focusing on the wrong end. 

In part 5, we share tips on how to get started with lean product development

In part 7, we discuss why cultural resistance in not the key barrier to Lean adoption.

In part 8 we share 4 ways to ensure your Lean product development initiative won't fail.

In this post, part 6, we highlight some other key principles of Lean product development.

Agile Hardware Development

Eric covered the difficulties in applying Agile methods to hardware product development in a previous blog series, but one of the Scrum methods that did translate well is the practice of daily (or frequent) standup meetings. Teams meet in front of a visual project board full of sticky notes that represent the tasks they are working on. 

 

Manual project boards Kanban boards

This approach has several benefits.

Communication – If you meet daily, any new issue is communicated to the team within twenty-four hours instead of in a week (or two) at the project status meeting.

Visibility – Only when all of the work in the system becomes visible can you begin to manage it. And systems loaded to high capacity states have very long cycle times. However, by managing WIP (work in progress) you can reduce loading and keep the active work flowing much faster. And you can see and monitor it at the daily meetings.

Focus – If you’re visibly managing the number of active tasks, and have made commitments to your teammates, you’re highly discouraged from multitasking—which is one of the worst forms of waste in most product development environments. (Not to mention that it literally lowers your IQ…!)

So at the end of the standup meeting, everyone has clear priorities for the day. (Clear priorities are a great accomplishment! But be carefulwithout PLAYBOOK, those “clear” priorities might not actually be “correct” priorities…)

Theory of Constraints

The other major source of methods for PLAYBOOK is Theory of Constraints (TOC). TOC was introduced to us by Eli Goldratt in his book The Goal way back in 1984. Even though the methods were quite different than Lean, many manufacturers used them to improve operations at the same time as many other manufacturers were adopting Lean. The fact that the book sold over six million copies attests to its popularity. But one of the topics developed from TOC that interested us was Critical Chain Project Management (CCPM).

Critical Chain Project Management

At a very high level, CCPM does a few things differently than traditional project management. One of the first steps is to “load level” the team members. This makes sure they don’t have more work than they can do in a given period of time. (Obviously, right?!) 

It also uses the concept of project buffers. Instead of each person adding their own buffer to their estimates, the task durations are “best case” and a shared buffer is created at the end.

 

 

This  shared approach works great in the uncertain world of hardware product development because it’s difficult to accurately predict how long things will take. And, besides the inherent uncertainty in a task duration, there are two additional causes of work taking longer than planned. 

First, Parkinson’s Law tells us that work fills up to take the time allotted. And second, Student Syndrome explains that people (not just students!) usually don’t focus on something until right before it’s due. 

Student syndrome time vs. effort graphed

 

The advantages of CCPM are that the plan is more accurate, team members are bought into it, and overloading and multitasking are reduced.

7 Key Lean Product Development Principles 

So now if you combine the key points from Agile and TOC in this blog post, and the key points from Don Reinertsen’s books in my previous blog, you can see why we selected these as driving principles of PLAYBOOK and how they benefit Lean Hardware Development teams.

  1. Decentralized planning
  2. Shared project buffers
  3. Standup meetings
  4. Prioritized backlogs
  5. Pull
  6. Visible queues
  7. WIP constraints 

These principles give us the first level benefits of visibility, communication, fast feedback, no multitasking, and early warning of delays… 

And all of those combine to give every team member clear and correct priorities each day…

Which means that projects are consistently completed 30-50% faster!

Next week I’ll cover some of the biggest challenges most companies encounter on their journey into Lean Product Development, and then the keys to success. Be sure to subscribe to this blog to get the rest of the story!

 

If you are ready to see how these principles are supported in PLAYBOOK, watch this video and take a product tour.

Take a Product Tour