Scrum History — The evolution of the Development Team

Scrum then and now, part 7

Willem-Jan Ageling
Serious Scrum
7 min readJul 24, 2019

--

Scrum has been around for years. Jeff Sutherland and Ken Schwaber presented it to the world at OOPSLA in 1995. They based it on “The New New Product Development Game“ (1986) by Hirotaka Takeuchi and Ikujiro Nonaka.

Since 1995, many elements of Scrum have not changed at all. By contrast, some other parts of Scrum have continued evolving. With this series I aim to show you how radically Scrum has changed over the years. Through this I wish to achieve transparency on why certain ideas about Scrum materialised and help raise understanding on the current definition of Scrum.

With this article I aim to give you an overview of the evolution of the Development Team through the years. The Development Team produces a working Increment every Sprint. The proposed composition and size — and even the naming — of the Development Team show beautifully how Scrum evolved over the years.

The New New Product Development Game

Characteristics

The paper that started the ball rolling — ‘The New New Product Development Game’ — is very clear how the teams should be composed.

It discusses cross-functional teams:

“Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish” — Hirotaka Takeuchi and Ikujiro Nonaka

It is repeated here and also discusses self-organisation:

“A group processes a self-organizing capability when it exhibits three conditions: autonomy, self-transcendence and cross-fertilization.” — Hirotaka Takeuchi and Ikujiro Nonaka.

and:

“Autonomy — the team is free to set its own direction” — Hirotaka Takeuchi and Ikujiro Nonaka.

Size

There is no mention of the team size, except for it being “small”:

  • A small group of engineers at IBM working on the first PC
  • A small group of sales engineers at NEC working on NEC’s PC 8000

Naming

The team is named “Project Team”.

The first Scrum paper — 1995

Characteristics and size

With the OOPSLA paper in 1995, Sutherland and Schwaber introduced their own adaptation of Scrum.

“Development teams are small, with each containing developers, documenters and quality control staff. One or more teams of between three and six people each are used.” — OOPSLA paper 1995

This addresses that teams are cross-functional and determines the size of a team.

And:

The team defines changes required to implement the backlog item in the packets, and manages all problems regarding the changes.” — OOPSLA paper 1995

This snippet touches upon self-organisation of the teams.

The quotes bring forward that the OOPSLA paper is very prescriptive. This is logical as it is focusing on using Scrum within an software development environment using Object Oriented techniques and tools.

Naming

The team is called a Development Team.

SCRUM: An extension pattern language for hyperproductive software development — 1998

Characteristics

Mike Beedle, Martine Devos, Yonat Sharon, Jeff Sutherland and Ken Schwaber 1998 bring the concept of self-organisation across as follows:

“Scrum Meetings allow the development team to “socialize the team members knowledge”, and have a deep cultural transcendence. In turn, this “knowledge socialization” leads to a self-organized team structure, where the process is invented in an adaptable way on a daily basis.” — Mike Beedle, Martine Devos, Yonat Sharon, Jeff Sutherland and Ken Schwaber 1998

It brings forward how important the Scrum Meetings (later called Daily Scrums) are to allow self-organisation.

Cross-functionality is not discussed. In fact, teams don’t necessarily deliver a “Done” increment at the end of the Sprint. The concept of delivering a “Done” increment of the end of the Sprint is not discussed in this paper.

Size

There are mentions of the teams being small like this one:

“We want every person on the team to understand the problem fully and to be aware of all the steps in development. This limits the size of the team and of the system developed.” — Mike Beedle, Martine Devos, Yonat Sharon, Jeff Sutherland and Ken Schwaber 1998

There’s no clear guidance how small “small” actually is though.

Naming

The team is called a Development Team.

First Scrum Book 2001

Characteristics

The book “Agile Software Development with Scrum” spends a couple of pages to discuss what a Scrum Team is. Here is an important quote discussing self-organisation:

“A team commits to achieving a Sprint goal. The team is accorded full authority to do whatever it decides is necessary to achieve the goal.” — Beedle and Schwaber

Cross-functionality is discussed here:

“Teams are cross-functional. A Scrum Team should include people with all of the skills necessary to meet the Sprint Goal.” — Beedle and Schwaber

Here’s how the individuals contribute to the team:

“Each team member applies his or her expertise to all of the problems. The resultant synergy from a tester helping a designer construct code improve code quality and raise productivity.” — Beedle and Schwaber

Individuals can apply their own expertise, but each individual helps with all the problems. In the years to come Scrum will be more prescriptive before the way the team self-organises isn’t discussed anymore.

Size

Team size is determined here:

“The size of the team should be seven people, plus or minus two [Miller]. Teams as small as three can benefit, but the small size limits the amount of interaction that can occur and reduce productivity gains. Teams larger than eight don’t work out well.” — Beedle and Schwaber

It clarifies the size of a team, but it also deviates from what is brought forward in the OOPSLA paper.

Naming

The team is called a Scrum Team. The Scrum Master and Product Owner are not part of this team. So in essence the Scrum Team 2001 is today’s Development Team.

First edition of Scrum Guide — 2010

Characteristics

There’s the quote you’d expect from a Scrum Guide:

Teams are responsible for organizing themselves to do the work. Teams are cross-functional, having all the skills needed to create an increment. — Sutherland and Schwaber 2010

But there’s more:

“There are no titles for team members. Teams selforganize to turn the requirements and technology into product functionality. Everyone chips in and does his or her best, doing or learning how to do what is needed. No job descriptions. No titles, no exceptions. For example, people who refuse to code because they are systems architects or designers could not be part of a Scrum Team.” — Sutherland and Schwaber 2010

Here Sutherland and Schwaber stress what they believe it means to be part of a Scrum Team. The team as a whole owns the Sprint Backlog and should feel responsible for creating “Done” increments. They state it very clearly.

Size

“The size of the Team optimizes at seven people, plus or minus two.” — Sutherland and Schwaber 2010

This is again a different sizing than in the previous publications. And this will not be the last time this changes.

Naming

The team is called “Team”. The Scrum Team now has three roles: Scrum Master, Product Owner and Team.

Second edition of Scrum Guide — 2011

Characteristics

The second edition of the Scrum Guide is quite a departure from the first version on the topic of the Development Team:

“Development Teams have the following characteristics:

* They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

* Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;” — Sutherland and Schwaber 2011

The term multi-disciplinary is dropped. Is is replaced by cross-functional.

On the topic of how the team works together the Scrum Guide became less prescriptive:

“* Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

* Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,

* Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.” — Sutherland and Schwaber 2011

Where the first Scrum Guide said that everyone should chip in and people should not refuse to do certain portions of the works the 2nd Scrum Guide moves away from it. People can have different skill-sets and focus-areas, but we still talk about one team and accountability as a team.

There is no clear definition that a single team member should be multi-disciplinary anymore. So somewhere along the line this watered down.

Size

Here’s what the 2nd Scrum Guide says about the size:

“Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. […] Having more than nine members requires too much coordination.”

The Development Team should be between 3 and 9 members.

Naming

We are finally talking about Development Teams (again). The Scrum Team now has three roles: Scrum Master, Product Owner and Development Team.

Everything that was established in the 2nd version of the Scrum Guide is still true today, 2019.

Conclusion

Ever since 1986 self-organisation and cross-functionality have been the pillars of a Development Team. How cross-functionality should be considered changed over the years, quite drastically sometimes.

The fact that the team should be small was always acknowledged. What small exactly meant differed over the years. Just like the name changed constantly.

For 24 years things evolved constantly. Ever since the 2nd Scrum Guide the characteristics, size and naming of the Development Team stayed the same. I am curious to see how long this remains the case.

The evolution of the Development Team is another example of the need to keep up-to-date with the evolution of Scrum. Before you know it your knowledge is outdated.

--

--

Willem-Jan Ageling
Serious Scrum

https://ageling.substack.com Writer, editor, founder of Serious Scrum. I love writing about maximizing value.