Get in touch
When talking about the optimal size for a team, you will almost inevitably come across Amazon CEO Jeff Bezos’s “two-pizza rule”. This rule states that your team should never scale beyond the size of what two pizzas can feed. According to Bezos that number is six to seven people (if you don’t work with folks who are extremely hungry).
The reasoning behind this is that as team size grows the number of links between people also increases. Even worse, the number of links between people increases disproportionately to the team size, which can be illustrated with the following formula:
n(n-1)/2
In practice, this means that if your team consists of five people, there are a total of ten links between those persons (meaning that there have to be ten conversations to ensure that everyone has talked to each other). If, however, you double the team size, there are suddenly 45 links between everyone involved. So with just twice the team size, the number of links between people will more than quadruple.
This is more than just a mathematical exercise. As the number of links increases when scaling up a team, the productivity tends to start falling – something that might not make much sense at first sight. But think about how many people you now have to spread information to. How many people you need to talk to in order to get everyone’s opinion. Think about how long meetings will suddenly take.
Scrum as a framework takes this issue into consideration by stating that Scrum works best with teams of five to nine people. Unfortunately, some complex projects simply need much more expertise and manpower than nine people could possibly be able to bring to the table in sufficient depth.
The team I work in is such a team. The team currently consists of eight developers (one of them being our Scrum Master), two software testers, a UX architect, a designer and two Proxy Product Owners (PPO). Two pizzas most definitely wouldn’t feed us.
Obviously, the first thought was to split the team up into two separate teams. Almost every Scrum scaling framework (such as SAFe or LeSS) will tell you to do this. But, none of those approaches worked for us. We couldn’t split the team horizontally (meaning by architectural layer), since we are always working on a specific piece of functionality in each sprint (meaning that the two teams would need to be constantly communicating to make the application work at the end of the sprint). This added complexity in communications and coordination – we believe – would just inflate the process even further instead of simplifying it.
Another popular approach is to split teams up by feature (vertically), so that every team would work on a specific set of user stories. A lot of companies do this (and they even reflect this technologically by building all the pieces of their software as microservices). For us, however, this would not have made any sense, since the pieces of the application we are working on are highly interconnected, thus making it impossible to draw a line to separate them.
So how did we manage to build a highly motivated and productive team without splitting it up? Actually we did both – we split things up vertically AND horizontally. We just did it without splitting up the team.
Let me explain.
First of all we, as a team naturally try to be as cross-functional as possible. The complexity of the technological stack we work with does not always allow for that. That’s why we have two “imaginary” sub-teams within the developers: There are backend specialists and there are frontend specialists. This makes it easier for everyone to limit the possibilities of whom to ask if something goes wrong on a specific architectural layer – and simplifies solving the issue together.
We also introduced something we call “User Story Godparents.”
When a user story on our sprint board moves into “In Progress,” a frontend and a backend developer assign themselves to it as user story godparents. At this point they take over the responsibility regarding all technological questions concerning this user story – they’re also responsible for getting this story done.
Of course the team as a whole still is responsible for reaching the sprint goal. We nevertheless noticed that by having everyone pull small chunks of responsibility we were able to increase the overall commitment to the project. You can no longer disappear in a homogeneous mass of developers, but need to commit yourself to your stories.
As a side effect this also decreased the amount of “adjustment bugs” – meaning things that only appeared because data formats, APIs, etc. were not discussed upfront.
As the product got more complex, the team also decided to introduce the role of the “Architect.” This is a slightly different role from what you might think of when hearing the term “Software Architect.” Our Architects (there are two – one for the backend and one for the frontend) are mainly responsible for keeping an eye on inconsistencies and imminent technical debt, identifying such issues and bringing them to the attention of the Proxy Product Owners; these can then create user stories out of them.
This helped us to not lose the bird’s-eye view on the technology behind the product and also formalize a process on how to get these things into the sprint.
This still did not solve one other issue we had when scaling: never-ending discussions – especially in our refinement meetings.
We are very passionate about what we do and that sometimes leads to long, detail-obsessed discussions. Although we love those details we still needed to figure out a way to achieve results efficiently.
That’s when we abandoned planning poker (for the most part) in our refinement meetings and switched to something known as the “Team Estimation Game“. I won’t describe it in detail here (that would inflate this post out of proportion), but it comes down to making everyone take turns in asking the PPOs questions about ONE user story. Since you are only allowed to ask questions about one user story, everyone became highly focused on the important questions, leaving extraneous details out of the discussion.
Of course being agile also means that everything is in constant change, so the tweaks described above might all only be temporary and we might eventually have to split up the team or find other solutions to new problems. But for the time being, I think we were able to get the best out of the team, with Scrum as a framework, and come up with a product without having to inflate processes. For now, this works amazingly well for us. And I hope you might find some nice ideas here for your growing team, too.
The only downside is: We still have to order a lot of pizza.
