Kobayashi Maru Thinking provides an approach to solve intractable problems.
Requisitioning nine women
Perhaps you have heard the following riddle.
If it takes one woman nine months to produce a baby, can nine women produce a baby in one month?
Many people come to the conclusion that there is not a clever answer to this riddle. In addition, they find a bit of humor in the way the riddle is presented.
How long will it take to complete my project?
This riddle is based on a statement from the classic book The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks, Jr. While at IBM, Brooks added more programmers to a project falling behind schedule. The rate of progress on his project didn't improve. He concluded:
“The bearing of a child takes nine months, no matter how many women are assigned.”
The statement is used to support advice commonly known as Brooks' Law
"Adding more people to a project that is already late will make it later." - Brooks' Law
Brooks' Law suggests that a no-win situation exists when a project is late. Possible options seem to be limited:
- Add resources
- Don't add resources
One argument for adding resources is that new specialists will enable other team members to focus on assigned tasks and the project tasks will be distributed so that everyone's workload will be more manageable.
Typical concerns about adding people include:
- The people added to the project will consume precious development time.
- The new people will detract from the productivity of the existing team members while they are becoming familiar with the project.
- Adding more people to the project will increase the communication overhead and keeping the project synchronized will be more difficult.
Typical arguments for not adding resources include:
- An acceptable outcome can be achieved through persuasion. The proper incentives will increase productivity.
- Maintain the budget. There is a perception about saving money in the short term. There are suggestions that shortcoming can be addressed later or by some other group.
- Changes will be disruptive. Making changes will have negative impacts on the current efforts.
Problems that may result from not adding resources include:
- An overworked team will not be able to complete all the required tasks.
- There will be other negative consequences.
- Additional mistakes and will be made.
- Individuals are more likely to suffer from fatigue.
A problem with too many new product development projects
It is common for new product development projects to be late (or to fail) for many reasons, When choices are made to add resources, unsophisticated decision makers are likely to make sub-optimal choices that may produce some of the following results:
- Promised project completion dates must be re-evaluated
- Death march conditions for the development team
- User experiences degrade for users of the product. Disappointed users write negative product reviews.
- Extra work for the post-sales support team to fix problems that were not addressed during development
- Progress is hindered on the next new product development project
Sub-optimal choices are not likely to produce great products that position companies for maximum success in the future. This post reviews some common beliefs about troubled projects and then addresses one way to overcome what may be perceived to be no-win scenarios.
Note: "Sometimes, Brooks’ Law is cited inappropriately as an argument for not adding resources to an understaffed project. In addition, Brooks’ Law does not apply directly to contributors that perform tasks that can be easily partitioned and isolated—those tasks that do not have a significant learning curve and require minimal communication." [2]
How does one overcome what appears to be a no-win situation?
No-win scenarios
Question: Who is noted for saying "I don't believe in the no-win scenario."
Answer: Captain James T. Kirk in the movie "Star Trek II: The Wrath of Khan." Kirk was referencing his experiences with the Kobayashi Maru test.
In the Star Trek culture, a Kobayashi Maru reference reminds fans of an apparent no-win scenario where a solution is possible by changing the starting conditions to redefine the problem.
Kirk overcame the apparent no-win scenario of the Kobayashi Maru test by changing the starting conditions. In contrast, he escaped the Genesis Cave by out-whiting Khan.
Changing the Starting Conditions
Let's review the original riddle and re-examine the goal. The desired goal was to produce a baby within one month. There were no requirements specified regarding the woman. There were no explicit requirements regarding the number of women. There were no other project constraints.
To achieve the goal, one solution involves altering the initial conditions by selecting a woman with an offspring already developing in her body. Note that it is the same woman as shown in the first image but this image reveals a fact that was not shown earlier.
By changing the appropriate starting conditions, one can achieve the desired result within the desired time.
Changing the starting condition for new product development projects
Kobayashi Maru thinking is characterized by changing the starting conditions to solve an intractable (wicked) problem. It does not involve:
- A Compromise
- Turning a difficult situation into an opportunity (a lemons to lemonade approach)
- A Hobson's choice (a free choice where only one option is offered. A 'take it or leave it' choice)
- A Pivot (as defined by @EricRies and the #LeanStartUp advocates is changing directions (vision) but staying grounded in what you have learned )
How will you close your next innovation gap (the time between the product concept and delivering value to an abundant number of customers)? How will you get to great faster that your previous attempts or faster than competitors?
I will not provide recommendations to overcome specific problems in this post. I can summarize several factors that may inspire more creative starting conditions. These include:
- Enlist individual contributors with the an abundance of domain knowledge and a mastery of their skills.
- Facilitate interoperability within the development network (encourage cross-functional cooperation and collaboration, improve communication,...)
- Evolve combined efforts produce the appropriate experience for the users of the product
- Adapt development models better suited for development networks (environments where many individual contributors are either geographically dispersed or where individual contributors are employed by separate organizations)
Kobayashi Maru Examples in New Product Development
One example of Koybayashi Maru Thinking was documented in my first article in Visions Magazine - How to Change Direction in New Product Development in 30 Days without a Budget [3]. This case study from HP documents the transition of someone in the role of documentation specialist to designer. Instead of complaining about the product's user interface, it was changed without a project budget increase and within the previously defined time constraints.
Many Kobayashi Maru Thinking examples relate the story a person changing hats (roles) for a finite period. In the Star Trek example, Kirk role changed from test taker to strategist and programmer.
Do you have another example of Kobayashi Maru Thinking in new product development? What starting conditions can you change on your new product development project?
Additional resources
[1] The Mythical Man-Month: Essays on Software Engineering Anniversary Edition. 1995 by Frederick P. Brooks, Jr., Page 17.
[2] Insights on Brooks' Law and Launch. Article by Mark A Hart in the June 2008 issue of Visions Magazine at http://www.oplaunch.com/documents/Insights_on_Brooks_Law_and_launch.pdf
Brooks' Law Wikipedia entry. According to Brooks, his law is an "outrageous oversimplification."
For additional insights on overcoming Brooks' Law, view the comments at http://stackoverflow.com/questions/76526/i-need-this-baby-in-a-month-send-me-nine-women where the question is asked "Under what circumstances - if any - does adding programmers to a team actually speed development of an already late project?"
[3] How to change direction in new product development without a budget. Visions Magazine. October 2003
