Managing the Design Factory, Donald Reinertsen. Free Press, 1997.
Reinertsen comes at managing design from the manufacturing product development side, but a lot of his tools seem appropriate for software product development as well.
“When we begin a design we make investments in creating recipes. However, a recipe does not generate profit until it is completed. During the time the recipe is incomplete we are holding an investment that is earning no money. We call this investment design-in-process inventory (DIP).” (p.11) (Sounds similar to software-in-process, no?)
The book is a set of tools useful in managing the challenge of DIP.
First set: thinking tools.
- Economic models let you make rational profit-seeking decisions.
- Queueing theory can show you how smaller batch sizes improve your turnaround.
- Information theory can demonstrate how “iterations generate early information.”
- Systems theory shows the value of feedback.
Second set: action tools.
- Organizational structure trades efficiency vs. speed. “Colocation is the closest thing to fairy dust that we have to improve communications on the development team.”
- Design the design process: match it to the economic objectives. “… technical risk can be substantially reduced by pulling system integration to an earlier phase of the process.” “In the uncertain world of product development the best product portfolios will have a mix of large and small batch size projects.”
- Product architecture: modularity, segregating variability, interface management
- Product specification: understand the customer, create a good specification
- Use the right tools
- Measure the right things. “Drive metrics from economics.” Controls can be focused on expense, cost, performance, or speed, at the project or business level.
- Decision trees, testing can help manage market or technical risk.
Part 3: next steps – section headers are: [quoted]
- Do your math
- Use decision rules
- Pay attention to capacity utilization
- Pay attention to batch size
- Respect variability
- Think clearly about risk
- Think systems
- Respect the people
- Design the process thoughtfully
- Pay attention to architecture
- Deeply understand the customer
- Eliminate useless controls
- Get to the front lines
- Avoid slogans [Yes, he knows.]
I recommend this book wholeheartedly; it isn’t the whole answer, but it’s a great contribution to “what does it mean to manage an agile software team?” (Reviewed Dec., ’02)