Summary and thoughts on The New New Product Development Game as an inspiration for Scrum
The New New Product Development Game, by Hirotaka Takeuchi and Ikujiro Nonaka, was/is referenced a lot by the Scrum community as a primary inspiration.
6 characteristics from some Japanese new product development companies from the mid-1970s to early 1980s
Effective new product development from a handful of Japanese companies (Fuji-Xerox, Canon, Honda, NEC) in the mid-1970s to early 1980s seemed to share six characteristics:
- “Built-in instability”: broad, challenging goals and a wide measure of freedom to accomplish them;
- “Self-organizing project teams”: autonomous, motivated, cross-functional teams;
- “Overlapping development phases”;
- “Multilearning”: learning at multiple levels (individual, group, company) and across multiple functions;
- “Subtle control”: deliberate design of systems to encourage desired behaviour (e.g., who’s selected for teams, work environment, encouraging direct engagement with customers, team-based evaluation and reward, celebrating failures, etc.);
- “Organizational transfer of learning”: Mechanisms for learning from one group to transfer to the rest of the organisation.
[5 and 6 seems to me to overlap with 1, 2, and 4.]
Notable missing company: Toyota
I’m not sure if all the current Toyota Product Development concepts were fully developed by the early 1980s but the key missing things from the 6 characteristics I see are:
- Set-based concurrent engineering (could argue this is an implementation of characteristic 4 and 6);
- Entrepreneurial system designers (aka Chief Engineer or shusa).
“Self-organising” doesn’t mean “self-directing”
“ Top management kicks off the development process by signaling a broad goal or a general strategic direction. It rarely hands out a clear-cut new product concept or a specific work plan. But it offers a project team a wide measure of freedom and also establishes extremely challenging goals.”
Note that the top-level direction, typically a challenging one, is set from outside the team. It’s more the product concept and work plan (aka day-to-day direction) that is up to the team to determine.
“Self-organizing” means autonomy, self-transcendence, and cross-fertilization
On autonomy
“ Headquarters’ involvement is limited to providing guidance, money, and moral support at the outset. On a day-to-day basis, top management seldom intervenes; the team is free to set its own direction. In a way, top management acts as a venture capitalist.”
On self-transcendence
“ The project teams appear to be absorbed in a never-ending quest for “the limit.” Starting with the guidelines set forth by top management, they begin to establish their own goals and keep on elevating them throughout the development process.”
On cross-fertilization
“ A project team consisting of members with varying functional specializations, thought processes, and behavior patterns carries out new product development.”
Note that, this goes beyond “cross-functional” but also highlights the importance of including diverse perspectives in new product development.
Type A (sequential) vs Type B (overlapping adjacent phases) vs Type C (overlapping all phases)
Rework, acting with partial information, and changing decisions is expected
“ A group of engineers, for example, may start to design the product (phase three) before all the results of the feasibility tests (phase two) are in. Or the team may be forced to reconsider a decision as a result of later information. The team does not stop then, but engages in iterative experimentation. This goes on in even the latest phases of the development process.”
T-shaping is expected
“ Division of labor works well in a type A system, where management clearly delineates tasks, expects all project members to know their responsibilities, and evaluates each on an individual basis. Under a type B or C system, the company accomplishes the tasks through what we call “shared division of labor,” where each team member feels responsible for — and is able to work on — any aspect of the project.”
Transfer of learning is not emphasised enough in Scrum
“Multilearning” refers to learning by individuals, groups, and the overall organisation across multiple functions. Example of mechanisms include 15% time (3M), quality circles from Total Quality Control, training across functions (aka T-shaping), etc.
“We observed an equally strong drive on the part of the project members to transfer their learning to others outside the group.”
I’m not aware of much emphasis on this learning aspect in most Scrum guidance, especially not around transferring team learning outside the team.
