If you’ve been trying to focus your team on one thing, you may have noticed that your agile team size feels wrong. Perhaps a number of developers are working on things that felt sub-optimal. Perhaps your business analysts suddenly had too much or too little or do. Especially in large teams, more than a handful of developers can feel like a waste.
If you’re feeling that way, you’re not alone. My experience suggests that teams often do better with a smaller number of developers on them. Certainly less than 5 and perhaps as few as 3 or 4.
However, it’s not quite as simple as “fewer developers is better”. Agile team size is a tricky thing to get right. Let’s look at the some of the dynamics so we can make good decisions about their makeup.
Dynamic #1: Communication pathways
First, let’s think about the number of ways that communication can happen within a team. Within two people, there is only one flow of information between them. However, these numbers grow quickly. With three people there are three pathways of information, and with four there are six pathways. With only six people, we reach 15 separate communication avenues.
The more developers, the more discussion. There’s more syncing up to understand what’s going on, and the more misunderstandings. The more communication pathways there are, the more relationships that have to be built across the team. People are complicated, and react differently to different people. There’s more chance of misunderstanding, and things going wrong.
Dynamic #2: Process constraints
Some organisations require a lot of ceremony from their teams, like constant reporting of progress. Therefore their teams naturally grow to include roles that exist purely to fulfil reporting obligations. When presenting these organisations with the idea of smaller teams, they assume the number of Scrum Masters, or Project Managers would need to increase. The logical conclusion is that the idea makes no sense. If they reduce the number of developers and increase the number of teams, the oversight would become a nightmare.
If that’s sounds like your organisation, take a good long look at your process. Ask yourself whether your level of oversight is helping or hurting your business. How much is truly being achieved in your teams? How much of your process is received wisdom?
Perhaps you need to rely on senior capable team members to take on more product responsibility. Perhaps you are able to retrain your project managers to product visionaries. Consider helping your scrum masters learn good Quality Assurance or Business Analysis techniques. Trust your teams to execute a vision, rather than checking their every move.
Dynamic #3: Code-less systems
It might be possible, especially these days, to build a new business or system with no developers at all. Before putting together a new team, check whether the problem really must be solved with code.
Your team might be able to stick together systems like Zapier, Airtable or Google Sheets to do what you need, without a single developer. These days, an approach like this can get you surprisingly far with many business types, especially for prototyping new ideas. It is clearly not going to work for every problem, but it’s worth considering.
Dynamic #4: Failover
If you are writing code, one developer is not a good number for a team to have. If you’re rapidly iterating in the early stages of a product to try and hit product market fit then you might risk it. But I suggest planning to change this approach as soon as you can afford to, as otherwise your crucial systems might go down at a moment’s notice.
Be careful not to fall foul of the other dynamics in the name of failover, especially if you have loosely coupled subsystems that can easily be rewritten. More than one developer is a good idea, but two may be enough, especially if you get good at writing (see below).
Dynamic #5: Synchronous vs asynchronous work
It’s a good idea to decide whether you want your team to be working synchronously or asynchronously. A bigger agile team size gives more opportunity to work synchronously, as there are more developers to work with.
With bigger synchronous teams with lots of developers, there’s plenty of opportunity for pairing. Pairs or mobs work synchronously by definition, and this practice is extremely helpful for knowledge transfer, mentoring, and building and debugging complex things.
However, let’s consider the open-source approach to development. There’s little to no pairing in much open source work. Development and communication happens in the open via issue tracking. Developers working in this way write a lot on issue tracking systems or mailing lists to transfer information between people. Because developers write everything down, it’s easier for someone else to pick up and improve code, and we have more flexibility on agile team size.
We can adopt this practice in our companies, whether or not the code is open source. This can work much better than following an “oral tradition” of ad-hoc information transfer through pairing and meetings. Mark Seemann recently wrote about how our oral traditions will seep into our code. Ad-hoc conversation breeds ad-hoc architecture.
Dynamic #6: Remote vs colocation
If a team works remotely for a long period, video communication can grate after a while. Spending a lot of time on Zoom calls is draining. Gianpiero Petriglieri, as associate professor at Instead, said in a recent interview that we need much more focus to be on a video chat. “Our minds are together when our bodies feel we’re not. That dissonance, which causes people to have conflicting feelings, is exhausting. You cannot relax into the conversation naturally,” he says.
This dynamic is closely related to our choices around asynchronous work. It is possibly to run an oral tradition remotely, and the technology now makes remote pairing easy. However, if we choose asynchronous work, we may find it easier to run a remote, more resilient team.
Dynamic #7: Role mix
Are all the right people in the team? If our teams are stuffed with developers, but are free of designers, product people or domain experts, we might want to think again. Our developers will always have questions and require interaction with stakeholders and customers. Perhaps your team needs fewer developers but a more eclectic mix of other disciplines so that they can collectively deliver what’s most valuable.
This doesn’t mean everyone has to report into one person. In my current role overseeing the Labs division of Gower Street, our normal practice is to have functional reporting lines, and then group people in to cross-functional product teams. This is a little different at the moment due to the pandemic, but we hope to get back to this soon, as we’ve seen the benefits first-hand.
Dynamic #8: Team utilisation
It’s not good for team members to be constantly busy shipping features and never taking a step back to consider how the whole system fits together.
With a smaller number of developers per team, it takes quite a senior developer to step back and refuse to deliver the next feature until the code is cleaner, or the build is smoother. With a couple more people, but still only working on one thing, you get a natural chance built into the system for people to step back and survey the quality of the whole system, and make some tweaks here and there.
Without at least a little slack, one or two developers can feel like they’re trapped in a never ending loop of work where people are constantly demand the next thing to be completed immediately after the first. They’re being fully utilised, and this is a problem. More junior developers require more explicitly given autonomy in order to do the right thing.
As we look to double our delivery, let’s not simply settle for doubling our code production, or sticking with the status quo. Let’s focus our teams on just a few things each, and listen to what that tells us about our team sizes. Understanding these team dynamics can go a long way to helping us increase delivery of value.