Now there’s a million dollar question for agile scrum teams if ever there was one. And we need to talk about it. So let’s do just that.
The world’s richest man, aka Amazon’s Jeff Bezos, famously adheres to “the two pizza rule,” which means simply that you should be able to feed your agile scrum team with two pizzas. Most of us are probably already scratching our heads at that. Why? Well, let’s be honest, it can be pretty easy to down one whole pizza all by yourself if the mood takes you. Then there’s the different sizes, crust thickness and what not to take into account. But let’s not go there.
The agile scrum numbers game
The bottom line is that what Bezos means, is more or less in line with what messers Jeff Sutherland and Ken Schwaber say in ‘The Scrum Guide’. That the ideal number of an agile scrum team should be between three and nine.
So where do these numbers come from? Well there is actually very little reasons or context given in the guide. This definition is about as good as it gets:
“Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage.”
Many research-backed efforts have narrowed the optimum number “sweet spot”, down to 5-7 team members. But in any case, as we at Starttech know very well, every startup or business has its own set of variables and idiosyncrasies. So clearly, a one-size-fits-all generic answer cannot define the optimal agile scrum team size for everyone. What is perhaps more important though when setting up your team, is knowing what factors should be reviewed, and what the trade-offs may be.
And that is why I decided to get a straight-from-the-horses-mouth view, posing the question to several of our portfolio companies who work with agile scrum development teams on a daily basis.
The inside view
So without further ado, let’s have the views of some of those more experienced in working in agile scrum teams and find out finally if size actually matters.
Evangelos Papanikolaou – Scrum master @ Starttech Ventures
“There is no single number for the optimal size for an agile scrum team. However, there is a “red-zone” of potential issues if the team-size is at or below three members. A small-size team will mostly/inevitably comprise of “I-can-do-it-all” members, thus resulting in a reduced need for communication among team members.
“One scenario that can play out, is this: the product owner may groom the backlog list in such a way that user stories will be destined/prepared for a certain member. This way of thinking further reduces the need for information dissemination about a user story among the team (remember?: the user story was created with a certain person in mind, not with the team in mind). Furthermore, the above ”vicious” cycle continues with an unclear definition-of-done; namely, having unclear acceptance criteria for the given user story.
“Bad practice (Separate scrum roles): In the Scrum Guide it is described that there should be three distinct roles in a scrum team, a) the development team, b) the product owner, and c) the scrum master. Keeping these three roles separate (as described in the Scrum Guide) offers a higher chance that the Scrum Sprints deliver value in a more predictable and steadier method. If the P.O., or the S.M., is a member of the development team, there is a risk that wearing two different hats can cause confusion to the team.
“For me a good practice, or useful hack, is utilizing the I.N.V.E.S.T. acronym when creating user stories is an investment that produces multiple benefits. This is not directly related to an “ideal” team-size, but it is a scrum principle that the team – any team – needs to train on and improve with time”
Clearly defined roles are key
Based on Evangelos views, clearly defined roles bring the required predictability that is needed from an agile scrum team. But what else is there that’s more important then numbers? The development team’s needs, that’s what.
Some of the key ingredients needed are these:
- A sufficiently broad set of skills to build their product – aka Cross Functional
- Team members dedicated to one and only one team
- Stable membership – i.e. team membership is consistent over a long period of time
- Diversity of thought (and background) – a sufficiently broad set of ideas, ethnicity, religion, gender, and life experience all spark creativity and diversity of thought.
Emmanouil Dramitinos – CIO @ Epignosis
“IMHO the ideal size of an agile scrum team is approximately six people; for less people the value compared to admin cost is less but still positive unless team size drops below four. For more people the meeting and ceremonies tend to become longer, distractions are more and staying sharp and focused is more difficult; plus the overhead of the scrum master is higher both in terms of monitoring and in terms of interaction, impediment removal etc.”
“But also the composition of the team is crucial: it is important to combine people with different backgrounds and POVs such as junior devs, senior devs, UI/UX, QA. Clearly the optimal team size also depends on other factors as well, e.g. are the people of the team exclusively allocated to the specific team or also serve other teams or have a horizontal role in the company? Time is another critical factor, new comers and old members of the team need some time for the former to self prove themselves and make sure they are accepted and for the latter to accept them, trust them and embrace them as full team members and not as potential threat to the way things “should be done”.”
“But to challenge a bit the question raised: There are no magic numbers! Good communication, professionalism, fairness, transparency and trust are the cornerstones of an efficient agile scrum team – as long as you can enforce them on a daily basis and in a no-exceptions made fashion feel free to have a team as large or small you like (it just gets more difficult to keep track of what is actually going on and what lurks under the surface for large teams, while for smaller teams the daily Scrum meetings are often regarded as a burden and it is more tricky to see the value of the daily communication).”
“For me a best practice is to adapt agile principles and truly embrace them; avoiding pseudo-agile scrums or zombie sprints where ceremonies are a routine procedure and no actual adaptation-decision making-error correcting is done. Be fair and focus on excellent communication and info dissemination; use written rules-decisions docs for what is agreed upon on retrospectives so that the whole team can reference to what is decided and no misunderstandings occurs; then enforce these rules without exceptions made and challenge anyone deviating from them at retros. Don’t be afraid to change rules but only as a team decision; try out new things between sprints and evaluate them – use data to convince on procedures not opinions. Provide justification in case the purpose of something is unclear and prove its worth during sprints. Follow up on what the team decides is worth trying and allow room for people to grow. Fail fast and learn from it, adapt and overcome the hurdles.”
Ryan Dervakos – Software Engineer @ Epignosis
“Manos covered everything is his post above, in my opinion the ideal size of an agile team is 6 +-3. I just wanted to add and/or emphasize on the phrase “Zombie sprint”. Routine “kills” anything related to the term “agile”, if you are getting the “routine” vibe then something is going wrong. Consider, or maybe it’s better to say re-consider aspects such as “Task Planning/Delegation”, team communication etc.”
Conclusions
While it’s important to narrow down the size of your agile scrum team within the general guidelines of The Scrum Guide for better performance, there is so much more to making things work. Above all, commitment, communication, and team chemistry clearly go a long way to making sure your agile scrum team is a well-oiled, peak performing machine.
