Lean Projects Are Lean Projects
April 24th, 2005 by HalMary Poppendieck has published two new articles: Breaking the Quality–Speed Compromise and Managing the Pipeline. Mary is the co-author of the book Lean Software Development with her husband Tom Poppendieck. Mary has a great outlook on software development that comes from many years in the profession.
In Breaking the Quality-Speed Compromise, Mary explores the everyday understanding to increase the quality of design activity one must increase the time available for design. There are firms who break the time-quality trade-off and by doing so position themselves to take business away from others. Mary develops the case that high-quality software product development doesn't have to take time. She proposes:
"The most important thing we can do to break the compromises we impose on customers is to move testing forward and put it in-line with (or prior to) coding. In other words, find and fix the defects before they even count as defects."
This approach can apply to all design activity. The general principle is this: Establish the criteria for acceptance prior to doing the design work.
In Managing the Pipeline Mary proposes 6 Rules for reducing cycle time — guiding your projects based on queuing theory:
- Limit work to capacity
- Even out the arrival of work
- Minimize the number of things-in-process
- Minimize the size of things-in-process
- Establish a regular cadence
- Use pull scheduling
While Mary attributes these rules to queuing theory (from the field of Operations Research), we can find these rules in operation in the Toyota Production System. I don't argue with attribution. Rather, I suggest that all we need do is look to the world's most successful approach to product development and production for validation of Mary's proposals.
As usual, Mary writes well and persuasively. Have a look.
Related Posts
- Watch Out for the Toolheads When talking about lean this and lean that, so much attention is given to the tools -- 7 wastes, kanban, kaizen, kaika...
- Lean Construction Summit This is the super event...15 years running. It's here in the US...won't return for at least four more years. Don't m...
- Lean Project Management Brad Appleton reviewed Lean Project Management, by L Leach concluding, "I found Lean Project Management to be a fairly...
- Becoming Lean Isn’t about Lean It's not easy being lean if you can't manage the change project. "I don’t see organizations having a structured way t...
- Fault, Flaw, and now Fizzy One key objective of lean is reducing waste. Doing so requires paying attention to surroundings and assessing something...
April 27th, 2005 at 10:39 am
These articles really ring true based on my experience with new product development. It reinforces my commitment to continue to fight for serial rather than parallel development of multiple products, and to avoid 100% + utilization of people.
May 11th, 2005 at 3:34 pm
The second article can be generalized across many project domains. The first article seems to be specific to software development using agile processes.
Building spacecraft is different than coding .net web apps. I only get one chance to weld the proplusion system piping right. If its not right the system has to be ripped out and redone, delaying the launch. So requirements, design, build, test are sequential, with high cermony transisition processes. The software that controls the propulsion system has the same attributes.
The trouble I have with “general purpose” agile is it really is context free. The proponents many times fail to establish a specific context for their suggestions - assumping that all software is like their software. This is not only true it is misleading to the uninitiated.
The core concepts of agile - feedback, small increments, test as you go, customer engagment, plan for change - are applicable across a broad spectrum. Putting them into practice is not the same has understanding the principles.
As Yogi says “In theory there is no difference between theory and practice. In practice there is.”
Until we start putting our agile PM processes in a specific context, much of the discussion will remain around the theory not the practice.
May 21st, 2005 at 12:32 pm
I enjoyed checking out your blog, nice work. If you have some time, please check mine out. It’s focus is project management, resource management, document management, help desk and we can be found at http://www.pbcinc.ca/blog