Let's compare Scrum with Chess for a second
Chess is a board game utilizing a chessboard and sixteen pieces of six types for each player. Each type of piece moves in a distinct way. The goal of the game is to checkmate (threaten with inescapable capture) the opponent's king.
The history of chess can be traced back nearly 1500 years.
So this comparison cross my mind in order of number of Scrum team up to 9 Dev team members + SM and PO, which is 12 members in total because "Large Development Teams generate too much complexity for an empirical process to be useful."
If people are managing 16 figures 1500 years, how is not possible to manage 16 people in Scrum team also?
Hope you get the point :)
Dejan
I'm not a chess player, but there is a small difference between managing 16 chess figures and managing a development team.
In chess you manage 16 pieces, but there are only two persons interacting. The pieces only go were you put them.
The outcome is the result of the actions and reactions of those two persons.
@Dejan Majkic, I was expecting something else when I read the title of this post but the difference lies in the fact that live human beings are complex in nature and the number of communication channels increases with the addition of 1 member to the team. Based on research the findings suggested that the optimum team size is between 3-9. Now, having said that it does not mean you cannot have a team of 16 people. You can, but bear in mind the risk due to the communication channels and the coordination issues. There are some teams out there that are still successful with more than 9 people on the team, but those could be rare cases.
Hope this helps.
A better comparison might be to have 16 real, self-organizing people standing on real squares, and then tell them that only one team member is allowed to move on their team's turn.
I can only imagine the process of them collectively arriving at the best possible move.
I worked with a 17 member scrum team at one point for about a year. The amount of effort required for effective communication plus the potential impacts of going back through Tuckerson's (forming/storming/norming/performing) when something significant changed was eye opening.
The recommendation for a team less then 9 in size is a good one based on my experience.
(I've also dealt with smaller sized teams of 3 - 5. They have some downsides too, many around having fewer options if something takes a team member out for a period of time (unexpected illness etc).
~Jamie N