Structuring Scrum Teams – I
Atoms do not have so much going on in their lives on their own. The real chaos begins when they are integrated…
“The system being produced will tend to have a structure that mirrors the structure of the group (team) that is producing it, whether or not this was intended. One should take advantage of this fact and then deliberately design the group (team) structure so as to achieve the desired system structure.” (Conway 1968; Conway Law)
If it is true that a product mirrors the structure of the team that built it, then it is important for any Scrum team to decide how they will organize the people that will be involved in teams. Factoring into this decision are considerations of team size, familiarity with the domain, the channels of communication, the technical design of the system, individual experience levels, the technologies involved, the newness of those technologies, where team members are located, competitive and market pressures, expectations about project schedule, and much more.
We need to consider two critical factors when deciding how to structure Scrum teams: keeping teams small and orienting each team around the delivery of end-to-end user-visible functionality. We also look at the importance of having the right people on each team and not overloading those individuals by forcing them to split time among too many teams.
Amazon’s Pizzas
There is a saying used for Agile teams in Amazon, one of the leading companies of Agile world: “Two pizzas must be enough!” (Deutschman 2007). This nice analogy summarizes the fact that the teams must be between 3 and 9 people, as strongly recommended in the Scrum guide. If we need to order food for a team, we should be able to feed the team with 2 large pizzas. In such a case, it is useful to think how hard it is to try to order food for a team of 15 people. Let’s explain the situation called “Communication Complexity”:
The number of communication channels in a team is formulated as [n * (n – 1) / 2] depending on the number of people. Therefore, a team of 5 people needs 10 communication channels, a team of 6 people needs 15 communication channels so that people can communicate with each other properly.
When the number of members in the team is 10, the number of communication channels increases to 45, and when it is 15, 105 communication channels must be opened and used. We can call it the “communication cost or burden”.
As the figures show, it is ideal for Scrum teams to have between 3 and 9 members.
If the teams need to have more than 9 members, 2 teams can be created. Contrary to popular belief, with two teams, things run much faster than a single team of 15 people. Self-organizing ability of the teams will solve the “management problem” very easily.
Why Are Two Pizzas Enough?
To be fair, there are some advantages of large teams. Large teams may include members with more diverse skills, experiences, and approaches. Large teams are not as much at risk to the loss of a key person. They may also provide more opportunities for individuals to specialize in a technology or a subset of the application.
We will look at the advantages of small teams and productivity/efficiency comparisons in the second part of the article…
(End of Section I)
