Small Teams and Process

David and Goliath — Guillaime Courtouis [Public domain, via Wikimedia Commons]

Isn’t it amazing what small teams can achieve?

I recently read that the team developing the popular Discord iOS app has just two developers. It reminded me of the jolt upon learning Facebook had acquired WhatsApp and a team of just 32 employees for $16B. How do they produce software to serve millions and maintain high quality with these tiny teams?

From experience, a smaller team has its advantages. I’ll focus on reduced process overheads in this post. Process tends to accumulate as a team grows, to enforce standards and regulate development direction, but also incurs a cost in resources and flexibility.

In the early days of Adapptor we were a single small team, with a mix of seasoned developers of varied backgrounds. When defining the workflows we use to build our apps, we could draw from a depth of past experience working with Agile methods.

When we were that small team, completely adopting a formal software methodology like Scrum felt like overkill. These frameworks are prescriptive, distilling much learned wisdom into procedures for producing software. A methodology guides software development in great detail for reproducible results, like a recipe in a cookbook. But it isn’t tailored to the composition or mission of your team, nor the problems you are facing in your projects right at this moment.

We picked the things we felt worked in Agile — standups, sprints and a living backlog — and adopted them, but avoided implementing too much process around it. We favoured transparency over process, making every decision in the development of our products visible through face-to-face interactions, across chat channels and over email.

Our veteran developers had a model for shipping software, and working in a small team with tight collaboration imprinted these principles on their colleagues. And as our project requirements changed, we could pull in more processes and ideas from Agile methods — code reviews, milestone planning — to support the needs of our projects.

I think of it as comparable to a typical startup, where the overarching mission is to ship software, and the process behind delivery evolves to support it. Processes are repeatable and can compensate for communication and consensus overheads of larger teams. It’s easier for a small team to reach a consensus decision by virtue of having less stakeholders. But smaller teams can make the opposite tradeoff, streamlining processes because overheads are low.

As a team grows, expectations of productivity gains increase along with it. And the challenges that frameworks like Scrum set out to solve become more relevant. Scaling a software team is a strong driver behind the adoption of these frameworks, because the processes provide a shared rulebook that can be applied to the problem of delivery. When everyone is following the same rules it improves team alignment, countering the difficulty of coordinating a large group of individuals.

But process can be stifling. It can be disheartening for a developer to spend more time in regularly scheduled meetings and retrospectives than actually building a product. There needs to be some flexibility to tweak and adapt to the project’s requirements and available resources. The blocker is firstly getting consensus for the changes in a large team and then implementing them. Everything is made more difficult because the scale is larger and change is slower to make.

In this context, it was fascinating to watch the video describing Spotify’s Squad structure. As a company, Spotify found that some Scrum practices had become obstacles to their development efforts, and came up with their own organisational model and processes. In their community-based structure, small teams (Squads) are given more autonomy, and self-organise in loose overlapping groups with names such as Tribes and Guilds. Spotify’s engineering culture pulls ideas from Agile and Open Source development thinking but in concept is unique to the company and its people.

This approach has inspired many companies to emulate it, applying the same ideas and names as outlined in the videos. I feel like this could only really work for companies with the same size and makeup as Spotify. The key factor for change was giving the team the autonomy to change the rules that weren’t working, and then evolving an organisation that could support this. The resulting Squad structure was an effect of this decision, not the cause, and I suspect reflects on the many positive attributes of small teams.

Software products are many and varied, just as the teams that create them are diverse in backgrounds and capabilities. There is much knowledge in Agile methods won through hard earned experience that is worth learning and applying. But sometimes the overheads from the practice of Agile play against the advantages of small teams. Empowering your team with the freedom to adapt Agile principles seems like a natural way to benefit from both.