Mary Poppendieck Seven Wastes Explanation

Last week, I invited the readers of shmula to pose questions to Mary and Tom Poppendieck ¹, the authors of Lean Software Development: An Agile Toolkit for Software Development Managers (Paperback), which won the Software Development Productivity Award in 2004 and, the sequel Implementing Lean Software Development: From Concept to Cash (Paperback).  Several questions were submitted and, over the next several weeks, I’ll be posting Mary and Tom’s responses.

Be sure to read our other interviews in our leadership series.

Here are Mary Poppendieck’s other responses to readers’ questions:

• Original Article to Ask Mary Poppendieck Anything
• Mary Poppendieck’s Answers to ALL Readers’ Questions
• Should Lean be Top-down or Bottom-up?
• An Interview with Mary Poppendieck with Pete Abilla
• Mary Poppendieck on the Handoff and Waste

Below is the first question-and-answer in the series:

John D. Heintz said,

November 15, 2007 @ 1:43 pm

Many Agile methods suggest a division of responsibility between the Customer and development team. The Customer is responsible for understanding and prioritizing the business needs and the dev team is responsible for estimating and implementing solutions.  This business/technology division of labor seems simple, visible and I can understand the daily responsibilities of each side.  The downside to this is (paraphrasing you from the lean development list) a we/they divide leading to local optimizations.  An alternate structure is the Chief Engineer who is responsible for the total business success of a product and leading the engineering as well.

My question: How does the division and delegation of responsibility differ when a Chief Engineer is responsible for the business success?  A Chief Engineer must have broad business and technical experience, but this person can’t be responsible for everything, all the time.  The best guess I can think of is to characterize the two styles into:

• Vertical Style: business/technical sides with a communication contract.
• Horizontal Style: A central figure that uses set-based design to constrain the next levels of work.

Interested in your experience and thoughts,

John

MBP >>

I recommend that you check out the book Lean Product and Process Development by Allen Ward (Lean Enterprise Institute, March 2007).  Allen Ward spent years leading studies of Toyota’s product development process.

He claims in the book that the biggest waste in product development is found at hand-offs.  A handoff occurs whenever you separate responsibility (what to do), knowledge (how to do it), action (actually doing it), and feedback (learning from results).  The problem with a we-they relationship between the business and the development team is that it creates a huge handoff, and embedded in that handoff is significant lost knowledge, and hence serious waste.  The development team should not be separate from the business, it should be a part of the business.  In this book Ward also discusses the role of what he calls the entrepreneurial systems designer (ESD), and he gives a good explanation of the role.

But to address your question directly, in a culture with product champions (as we had at 3M) or Chief Engineers (as at Toyota), the focus of activity is on a specific value stream (product & its support structure), while the focus of knowledge creation is on the horizontal (functional) organization.  This is to say if your company distinguishes itself by being really good at User Interaction Design, or test frameworks for hardware, or highly resilient transaction processing, or whatever, you had better develop and protect an unassailable technical capability in the areas that constitute your competitive advantage.  This technical capability will be applied to products (led by a product champion), but needs to be protected as an organizational core competence (perhaps under the guidance of a functional manager).

TDP >>

When a new engineer joins Toyota, they spend their first six months working in a factory building cars.  They spend the next few months working in a dealership selling cars.  Toyota considers well worthwhile this investment in providing the people who design their products with a deep, first hand understanding of the human consequences of their design decisions.  There are no strictly technical or strictly business decisions.  Each area both enables and constrains the other.  The chief engineer holds the vision of how the customers can be profitably served, and collaborates with the team members to iteratively refine the vision into a collection of features and implementations.  Each team member ensures that from their specific functional perspective the result will deliver sustainable value. Tradeoffs often cross functional boundaries.