Sizing an Agile team is not an easy task. In this article, Mark Haynes discusses some of the factors (control, the nature of the work, optimal communications) that will influence the decision for the size of a Scrum team.
Author: Mark Haynes, https://www.linkedin.com/in/donald-mark-haynes-csm-745a609/
We live in a world of knowledge workers, so why do we persist in building organizational pyramids? We know that development team members aren’t a fungible resource, yet we persist in traditional organizational structures.
Are you motivated towards larger teams, due to one of these axioms:
- Many hands make light work, or
- More people provide more diversified skills, or
- More eyes create a better solution.
The Many Hands Fallacy
The Pareto Principle states that 80% of the output is produced by 20% of the workers. Why would adding additional people significantly increase the output? Those two or three people who do most of the productive work are now carrying a much larger load. Ask yourself, have additional people proportionally increased productivity, or has it increased frustration and staff turnover?
All The Necessary Skills Fallacy
Agile prioritizes flexibility over economies of scale. One constant in a continually changing technical environment is that our work is unpredictable. So, how can you predict the required future skill sets? Trying to staff all possible contingencies will quickly create large, unmanageable teams. What do you do if a skill set becomes unnecessary? Do you eliminate that person or hang on to them just in case? Maybe they will grow into their job, but how do they differentiate themselves in a team of twenty? Or should we let those few productive individuals grow into their jobs?
The Many Eyes Fallacy
It doesn’t necessarily increase team size, but it does manifest itself in endless review sessions, multiple approvers, and lengthy inspections. Formal document sign-off slows down product delivery. How much value does this have? Shouldn’t the Sprint Review be sufficient? How effective are all those code reviews anyway? Does one person read the code, reducing their productivity, and the rest tag along for sign off? The Agile Manifesto states, “Working software over comprehensive documentation.”
Team Sizing
Optimizing teams typically considers:
- Span of control,
- Task completion,
- Efficient communications, and
- Efficient use of resources.
Optimizing the team for the span of control
The span of control is the number of direct reports a manager oversees. Depending on role complexity, it may be 3 to 6 or 10 to 15 for standardized positions. For a Scrum team, it’s usually 5 to 7.
Traditional IT teams usually had one project leader for every 6 to 12 programmers and two to four project teams per manager. My test teams generally ranged from 3 to 6, with up to 4 teams per manager. Even highly skilled, independent, siloed work is limited by the management’s ability to coordinate its resources.
Optimizing team size for task completion
At what point does adding additional hands get in the way of providing effective solutions? Size matters, especially at the task level. Appropriately sizing teams allows maximum flexibility, but more importantly, it permits people to focus on their tasks.
Ivan Steiner (Group Process and Productivity, 1972) indicates the optimal team size is 5 to 6 people, depending on the task. Patrick Laughlin demonstrated that the ideal team size was three in a controlled laboratory experiment at the University of Illinois Urbana-Champaign in 2002.
The standard size of the US Army light Infantry Fire Team is 4: One Team leader, one Rifleman, one Automatic Rifleman, and one Grenadier. Each has a unique specialty.
My own experience is that three is an ideal number for a development team. One to define the business problem; one to implement the solution; and one to validate the solution. Each brings a unique perspective and skills to providing the solution.
Optimizing team size for communication effectiveness
Small teams communicate more efficiently than large ones. Each additional team member geometrically increases the burden for effective communication. Large teams potentially incur more conflicts. Keeping teams small increases individual performance and the team’s overall effectiveness.
Metcalfe’s Law states that a network’s impact is proportional to the square of the number of nodes in the network. Each person becomes a communications node.
Increasing team size drastically increases the number of communication paths.
- Two nodes make only one connection
- Five nodes can make 10 connections
- Twelve can make 66 connections.
If you have an issue requiring team buy-in, a twelve-person team has a possible 66 conversations. Small increments in team size quickly become unmanageable. This doesn’t take into account back-channel communications or the internal arguments. Of course, more meetings are required to negotiate a solution. The result is a decrease in team productivity. Why are all those meetings necessary? Maybe it has something to do with your team size.
Optimizing for effective use of resources
Large teams inherently deploy resources inefficiently. User Story size and complexity are significant factors, but every handoff is a potential dependency, with a corresponding lag time.
Compare the workflow of a 12-person team to a 6-person team. The 12-person team has serious workflow issues. The Product Owner (PO) is in serious overload. They hardly have time to interact with their Stakeholders and assess needs vs. wants. Let alone customer feedback. The Quality Assurance Analysts are similarly overwhelmed and under pressure to expedite software. How could this impact their quality?
Now consider a 6-person team. Their backlog is much less, and the PO isn’t as stressed. In my experience, Business Analysts can relieve the burden of the PO. Creating a Kanban board with a Pull vs. Push configuration helps regulate the flow of work through the queue.
Self-organizing teams
It’s natural for teams to self-organize to provide effective solutions. The tendency for large teams is to break into smaller factions. Does one group attempt to force decisions on the rest of your team? Do your team sessions quickly break out into arguments? Do the vocal or ambitious programmers get more interesting assignments, and by default, the quiet ones get the less challenging work?
Conflict is not necessarily bad, but for the Scrum Master, this means unproductive time and more time to unruffle feathers. This can lead to disharmony and reduce team effectiveness. Fewer people means fewer conflicts, but more importantly, easily negotiated ones.
Closing Thoughts
There is a natural size limit to efficient and productive teams. What factors have influenced your team size: span of control, the nature of the work (highly siloed vs collaborative), task-focused, or optimal communications within the team? A rule of thumb for sizing a Scrum team seems to be five to seven people. With smaller teams, throughput is smoother. With larger teams, reconciliation becomes a major issue.
References
Chaudhary, Sujan. (2023, December 31). What is a Team? Definition, Features, Types, Strategies, and Examples. https://thembains.com/what-is-team/
Staff Writer. Agile Glossary – Team. https://www.agilealliance.org/glossary/team/
Staff Writer. (2024, August 26). Agile Team Characteristics, Roles & Responsibilities. https://www.geeksforgeeks.org/agile-team-characteristics-roles-responsibilities/
Staff Writer. Scrum.org. What is a Scrum Team? https://www.scrum.org/resources/what-scrum-team
Potter, Jaime. (2020, April 27). Forbs. The Ideal Team Size At Work May Be Smaller Than You Think. https://www.forbes.com/sites/jaimepotter/2020/04/27/the-ideal-team-size-at-work-may-be-smaller-than-you-think/
Bhangoo, Tenvi. (2020, July 13), How To Structure Your Tech Team – And Continually Reevaluate That. Forbes Technology Council https://www.forbes.com/councils/forbestechcouncil/2020/07/13/how-to-structure-your-tech-team—and-continually-reevaluate-that-structure/
Kaila, Sunny. (November 5th, 2024). DevPro Journal. 8 Effective Management Styles for Technical Teams. 8 Effective Management Styles for Technical Teams
About the Author
I am a renaissance man trapped in a specialist’s body. I started as a biologist and that’s why I became an IT guy. I love science, but it doesn’t pay the bills. I have been an IT professional for many years. I used to be a software developer with an elegant language for a more civilized age. I became a Quality Assurance guy because it’s better to give than receive. I have been a process improvement specialist because it’s easier to negotiate with a terrorist than a Methodologist. But lately, I’ve been working as a Scrum Master and Agile Coach. I have drunk the Kool-Aid and it tastes good. Agile is a philosophy, not a methodology. In interviews, people often ask how long you’ve been Agile. My answer is always. I just didn’t know what it was called before.
Interesting article about the size of Scrum teams. I remember reading something in one the LESS books about the idea that you should always start small and only grow your Agile team when it starts to hurt.
Agnieszka,
Thanks for your comments. This is the second of three on Agile teams. The third is under construction. The first one was published. https://agilealliance.org/team-size-and-the-scrum-masters-breaking-point/
Mark