Back to the Roots into the Future

In their HBR article ‘The New New Product Development Game’ from 1986, Hirotaka Takeuchi and Ikujiro Nonaka wrote the for the first time about Scrum as a “rugby” approach for organizations to match increased market complexity with increased internal complexity. This was quite different from Henry Ford who neglected the variability of customer needs in his 1920 quote about the T-model when saying “Any customer can have a car painted any color that he wants so long as it is black.” This 1986 HBR paper completely reframed the new product development challenge by emphasising “new products as a source of new sales and profits”.Later in 1995 Ken Schwaber and Jeff Sutherland introduced Scrum as a framework for teams who are developing and sustaining complex (software) products and delivering projects. By transferring many of the initial ideas of this HBR paper, somehow the aspect of market complexity as a primary design challenge for Scrum got lost in the early adoption in software development. Instead Scrum is focusing on the problem of building software products and coordinating the work of a cross functional teams.

However the complexity of product development is driven by the variability of market segmentation and customer needs. That was the case in 1986 and is continuously increasing as the customer is playing a more and more crucial role in the product development cycle. Only 2007 Ken Schwaber writes in The Enterprise and Scrum: “Until recently, I viewed this relationship [between product management and development] as one of many changes in a Scrum adoption. I now view it as the most critical change, the lynchpin of the adoption. If this change is successful, the use of Scrum will persist and benefits will increase. If the change isn’t successful, the use of Scrum in your enterprise might well unravel.”

The Scrum guide puts the burden of finding what to do and “maximising the value of the product and the work of the Development Team” on the shoulders of the person who takes the role of the Product Owner. It just states that “How this is done may vary widely across organisations, Scrum Teams, and individuals.” Leaving this question open and as practiced in many organisations today, Scrum is used to solve a different and simpler problem: building software. The playground of Scrum emerged in the context of the Development Team, thus putting the focus on the How? but ignoring the Why? and What? to build and disregarding the initial thoughts on balancing external and internal complexity of the whole organisation.

Going back to the roots, in the ‘The New New Product Development Game’ Takeuchi and Nonaka describe six characteristics of managing the product development process that we still find very practical and valuable for product development:

1. Built-in instability:
   Formulate a high level, challenging goal and clear constraints but restrain from setting rules and telling people exactly what to do.

2. Self-organizing project teams:
   A team is self-organizing when it has autonomy over the work, accepts a challenge that drives self-transcendence and shows cross-fertilization.

3. Overlapping development phases:
   Work non-siloed and cross functional in a diverse group with all the skills needed to build the product.

4. “Multilearning”:
   Focus on experimentation and learning across multiple levels (team, organisational hierarchy) and functional area.

5. Subtle Control:
   Exercise subtle control in these seven ways: select the right people, create an open work environment, encourage engineers to go out into the field and talk to customers, establish a group based reward system, manage the differences in the rhythm throughout the development process, tolerate and anticipate mistakes, encourage suppliers to become self-organizing and involve them early in during the design.

6. Organizational transfer of learning:
   Foster learning in the whole organizational network and un-learning to adapt to changes in the environment

An abundance of knowledge and methods emerged beyond the scope of Scrum since Takeuchi and Nonaka wrote their famous article but companies are struggling still with the holistic approach to Product Ownership aiming at business agility. Finding the answers to the Why? and What? of product development and a holistic approach to being flexible and fast in responding to change were the original design challenges of Scrum. While current management schemes strive for best practice and reduction of variability, we see that in 1986 these grandfathers of Scrum realized that internal complexity has to be present to deliver successfully.