A new game

Ken Schwaber and Jeff Sutherland refer to the article The New New Product Development Game as their main source of inspiration for the creation of Scrum. The authors of the article, Hirotaka Takeuchi and Ikujiro Nonaka, published it in the renowned Harvard Business Review in the mid-1980s (TAKEUCHI; NONAKA, 1986).

Takeuchi and Nonaka are known for their important contributions in the field of knowledge management and organizational learning. In the article, they studied companies in Japan and the United States, such as 3M, Xerox, Honda, Epson, NEC, and Hewlett-Packard. These companies were taking a different approach to new product development teams, and with it, achieving excellent results for products such as cars, copiers, personal computers, and cameras.

Their teams had six fundamental characteristics: built-in instability, self-organizing project teams, overlapping development phases, “multilearning”, subtle control and transfer of learning.

Built-in instability

Top management initiates the development, indicating broad and challenging goals or strategies to create an element of tension, while giving the team a great deal of freedom to achieve those goals.

Self-organizing project teams

Self-organizing project teams exhibit the following conditions:

Autonomy – They are more autonomous in their day-to-day work, with very little interference from top management.
Self-transcendence – They are absorbed in a never-ending quest for an unreachable limit, in which the team sets higher and higher goals during the development process.
Cross-fertilization – They have a variety of specializations, behaviors and personalities, and the interaction between their members promotes the creation of new ideas and concepts, the distribution of knowledge and consideration about what is best for the group

Overlapping development phases

Even though its members may start a project with different time horizons, since the work of each person can begin in different phases of the project, the team ends up creating a common rhythm of work, since they must synchronize their paces to reach a common deadline. As a result, they begin to work as one, and with this the individuals and the whole become inseparable, creating a common pulse. This pulse acts as a force that moves the team forward.

The overlapping of development phases allows for better handling of any bottlenecks that may arise in the workflow, offering greater velocity and flexibility, reinforcing shared accountability and cooperation, stimulating involvement and commitment, sharpening the focus on problem-solving, encouraging initiative-taking, enabling the development of diversified skills and intensifying sensitivity to market conditions.

Multilearning

By being exposed to different sources of information, team members acquire extensive knowledge and diverse skills, creating a versatile team capable of solving a myriad of problems quickly.

This learning takes place in two dimensions: at multiple levels – that is, individual learning, group learning and organizational learning – and in diverse roles, in which specialists are encouraged to accumulate experience in areas outside their expertise. “Multilearning” allows the team to respond quickly to market changes.

Subtle control

Although project teams have a high degree of freedom, they do not work without any control. Top management should establish checkpoints to prevent instability, ambiguity, and tension from leading to chaos. Nevertheless, the kind of rigid control that undermines creativity and spontaneity should be avoided.

This subtle control is exercised in the following ways:

Selecting the right people for the project, while monitoring the group’s dynamics and adding or removing members as needed.
Creating an open work environment.
Encouraging engineers to interact with customers and suppliers.
Establishing an evaluation and reward system based on the performance of the group, not individuals.
Managing the differences in rhythm throughout the development process.
Tolerating mistakes, finding and correcting them early and always learning from them.
Encouraging suppliers to also self-organize and involving them early in the project.

Transfer of learning

In addition to the accumulation of knowledge between different levels and functions, we often observe the transfer of this knowledge to other divisions of the organization and other new product development projects. This transfer occurs when we assign key individuals to subsequent projects, or when we create standards from project activities.

Knowledge transfer works well when the external environment is stable. In this sense, changes to the environment can make such lessons learned impracticable. In these scenarios, unlearning can actually help the team stay aligned with the reality outside its environment and make incremental improvements.

Definition: the name “Scrum”

Scrum is not an abbreviation or an acronym. As such, we should not write SCRUM, with capital letters, or S.C.R.U.M., with a period after each letter. Scrum is actually a term from the game of rugby. How, then, did this name end up in an agile framework? In their article The New New Product Development Game, Takeuchi and Nonaka discuss high-performance new product development teams in American and Japanese companies during the 1980s. The authors compared their way of working to rugby teams, which pass the ball back and forth between their members, but always moving towards a common goal as a unit.

This team view contrasts with the traditional practice of product development, where the work progresses in sequential phases. Under this scenario, where the functions are highly specialized and segmented, each person does their part and then passes the work to the next phase.

Scrum, short for scrummage, is a formation in which teams position themselves to receive the ball in a rugby game. Players on the opposing teams group together against each other in an attempt to gain possession of the ball. From this rugby analogy, the name was adopted for the Scrum framework.