The issue of team size comes up very often in my interactions and online. People are very anxious about this detail and for good reason. The size of a team directly effects the culture and work they do, for good or bad.
The Agile and Scrum literature, including training classes, recommend a team size of “seven, plus or minus two.” This means a Scrum team should have 5-9 members as the ideal size. In Scrum this number includes the Product Owner and ScrumMaster. There are many reasons for this recommendation:
- A team smaller than five decreases diversity of skills, opinion and background too much, which hurts creative capacity.
- Imagine a retrospective on a team of three people. There is a strong tendency toward either a regular complaint session or mutual admiration society. Neither of these would lead to productive improvements very often.
- A large team requires too many relationships at once. For example, every member of a 10-person team has nine relationships to maintain, with a total of 90 relationships in the team. Add an 11th member and the number of relationships goes up to 110!
- The overhead of coordination grows with team size along with the difficulty in maintaining relevance between the members.
I was once the ScrumMaster of a seven person team. We were starting the creation of the base technology for a the company’s next generation of products. Exciting stuff! We hired or pulled people from other projects to grow the team as the work progressed. At around twelve members I began asking about splitting the team, to keep the size reasonable. We decided against it, that we wanted everyone to be aware of what was happening in this complex work.
And the team continued to grow. Software engineers, hardware engineers, VHDL (embedded stuff) designers and so on were added. Soon we had 26 on the team. Yes, it was big, way too big. We still held our daily stand-up meetings and kept them to 15 minutes or less most of the time. We worked hard to keep meetings tight and relevant. And we failed at keeping the energy up.
Splitting Is Good To Do
After several sprints we finally had consensus to split the team into three. Let me paraphrase some things people said about their new team size after the first sprint:
- Retrospectives are better because it is easier to write items for “well” and “improve” because didn’t have to worry about boring other members with things they don’t care about.
- Daily meetings were not an interruption of hearing about things I wasn’t working on. I could work, go to the meeting and go back to work with the same thread of thought.
- My team members are helping me more often now. I guess they didn’t really see when help was needed when we had such a large team.
Large or Small, Watch
Whether your team or teams are large or small, watch what is happening. Pay attention to the information flowing in meetings and during the work. Especially give a strong look at what is happening in the retrospectives. Are things discussed shallow or repetitive? Is there confusion when clarity was expected? So some members feel alone in the team? The size of the team may be something you can change to remove such doldrums and re-energize the communication!