As many studies show, “Size does matter”. For different reasons, see below, it is important to keep team size limited. Hereafter follow some rules of fist. “Two-pizza team rule” from Jeff Bezos (Amazon), team should be small enough to be fed by 2 pizza’s, which roughly means less than 8. The Scrum guide puts the number between three to nine: large enough to have sufficient interaction and productivity gains, small enough to be able to coordinate. “No double digits” Harvard Psychology professor J. Richard Hackman.
Benefits of small teams compared to big teams
More effective and efficient communication
- Communication (relational) connections grow rapidly with team size: #=n(n-1)/2. A team of 9 has 36 connections, a team of 18 has 153 connections/relations to maintain.
- Meetings take less time due to reduced chance of lengthy and complex discussions, and lower chance of topics where only part of the team is involved and the rest is wasting time or interfering/disturbing
- Easier to keep all up to date and understand what others are working on and if there are any issues. Partly due to improved osmotic communication (“background hearing”).
- Fewer backlog items to simultaneously manage which also improve focus
Higher engagement
- More influence, and room to voice opinion
- More acknowledgement for individual contributions as they are relatively bigger, more unique and visible, and therefore perceived as being more valuable (in contrary to the opposite called “social loafing)
Improved management
- Smaller teams are more able to self-organize
- Fewer people and backlog to manage, means more time and energy available to support/coach team members, pro-actively prepare work, implement improvements and remove impediments
Better outcome
- People care more and social control is higher, leading to improved customer satisfaction, profitability, productivity, and quality (fewer safety and other incidents).
- More innovation and thought-through decisions as people in small groups find it easier to build trust and less fear of failure, allowing them to voice their own opinions, challenge those of others, and ultimately make better, more thought-out decisions
- Faster to respond to changing circumstances as less people are needed to get aligned and make a decision
- More reliable in estimations and more predictable
Challenges when splitting up teams
When a team grows, at some point it may become so large it would benefit from splitting it up. This, however, also comes at a cost for which you find some examples described below. In fact we require basic scaled agile techniques of frameworks like SAFe, Scrum@Scale, etc.
- More teams need to be managed which requires additional management (more PO’s and SM’s), and events for alignment/syncing
- Work of teams needs to be aligned and integrated which adds risk and possible delays
- During execution, dependencies (e.g. non-functional requirements, shared resources, technical dependencies) may exist between the teams which require management and inter-team communication and collaboration.
- Less people in team that share a competence, make it more difficult to have back-up and swarm which reduces team planning reliability and flexibility
- Teams often have a tendency to specialize, for instance around a domain or part of product, which reduces overall planning reliability and flexibility.
- Some competences are not available for each team and have to be managed for instance by sharing a person over teams, train people (T/π-shape), split work and manage over the teams, etc.
- Sharing knowledge and learnings require additional time, effort, tooling and agreements
- Risk of in-group/out-group thinking (my team first, we didn’t cause that, etc.) and local efficiency / reinventing the wheel / deviating
- Ownership of shared code, models, parts, libraries, etc. requires additional management
- People may feel locked in a small team and a balance has to be found between keeping individuals happy (e.g. by moving to a different team after a while) and teams performing.
Practices for dealing with challenges
Some known good practices for dealing with the challenges that come with splitting teams are as follows.
- Each team needs one and only one Scrum master and one Product Owner. Depending on the work at hand and maturity of SM/PO, teams, and organization, a SM or PO may serve multiple teams. PO’s should form a virtual team to align on backlog related topics, SM’s should form a virtual team aligning on improvements and impediments.
- Developers need to take responsibility for cross-team collaboration an solving dependencies (this is not a SM job). This means, go over and talk to people in other teams (preferably face-to-face or perhaps phone and not via email).
Other things that help are: organize cross-team design workshops and other sessions; keep design/code well structured, clean and commented; automate builds and testing and regularly check design/code back in; design peer reviews; pair designing/coding; etc. - To foster high quality components, particular components could benefit from having a mentor/moderator. These can teach others, monitor technical health (involved in refinement, review design options and changes), facilitate workshops, organize component communities, etc.
- Have a combined Sprint planning. Start with all PO’s and teams (or team representatives) in a single room where draft sprint goal and top priority stories are shared. The second part where all teams each plan their own sprint, preferably simultaneously in the same room or close by (break out rooms). Same can be used for refinement sessions.
- Teams can send scouts (not SM) to visit other teams Daily Scrums and report back. In case needed, Scrum-of-Scrum events can be organized for urgent impediments the team can not solve.
- The sprint review can have a shared part where all teams demonstrate and observe/discuss.
- After the sprint retrospective, Scrum masters may share general impediments/challenges and ideas/actions for improvement.
- Highly specialized people (not enough to have one in each team can be regarded as “freelancers” (a.k.a. travelers or shared resources). Preferably, they make teams less dependent on them by coaching/teaching (e.g. via pairing, organizing workshops / training sessions). Next, they can join a specific team for one or more sprints, guarantee some (time or MoSCoW based) capacity, reserve time slots, co-locate with teams, under-plan to allow for unplanned requests, etc.
- For features that need to be picked up by multiple teams (large features, specialisms, short time frame, etc.) it helps to have one team taking the lead (coordination, integration, test system availability, etc.).
- For cross-feature topics (e.g. non-functional requirements, technical developments, infrastructure, etc.) enabler features / stories can be defined and put on the backlog to be picked up by a team (or multiple teams if needed).
- Communities of practice are formed for knowledge sharing, working on competences, and collaborate on tough challenges. It helps a lot if someone takes a lead to coordinate and facilitate (can even be a full-time job).
- It may help to take the actual teams situation (e.g. domain knowledge, competences, etc.) into account when defining and splitting features / stories.
- People in teams may have specializations but are willing to put the team first, the same can be applied to whole teams. Some teams can specialize (e.g. on a domain, large component, competence, etc.) as long as they do not overspecialize and are willing to put the team-of-teams first for planning flexibility, systems thinking, overall effectiveness and efficiency.
- Provide opportunities for people to change team when needed for learning, refreshing, personal circumstances, etc. There should be a balance between the need for stability and other factors. The Scrum master can play a role in this, as well as providing room for self-organization.
