Q&A – Agile Swarm
What is an Agile Swarm?
An agile swarm is a team of developers that focus on a single topic at a time, try to implement a solution and then continue on with the next topic. The fundamental difference to a regular agile team are:
1️⃣ The amount of devs dedicated to a single topic: Normally, a single developer will work on a problem at a time. This is efficient and a natural way to split work within a group of people. Within a swarm we want to increase this number deliberately so that more developers will have the ability to learn on how to solve similar issues in the future.
2️⃣ Frequency of switching contexts: In a text book development setting, context switching is something to be avoided. With an agile swarm, the idea is to switch the focus to a new topic as soon as possible to be able to cover a large area
3️⃣ Utilization of experts: Every team has their go-to person for different topics. These people are typically first in line to solve all the problems themselves that fall into their area of expertise. The role of an expert within a swarm is primarily focused on managing the swarm and to provide support where it is needed, but not to solve the issues directly.
Why are we using this approach?
From our experience, agile teams tend to evolve in a way where, because of the way that work gets divided up within a team, after only a few weeks, experts emerge. These experts stay on their dedicated topics and become even better experts. However, knowledge does not get shared, every member of the team starts to get isolated. The team might be very efficient but also fragile. If there is a change in the team structure, efficiency or quality drops immediately. Due to the isolated nature of experts, communication also decreases as there is no inherit need to spread information evenly.
What are our expectations?
In order to tackle this, we will use agile swarming across a large set of different topics where we already have sophisticated experts. Now, these experts will have to sit back and take on a different role. On the one hand, similar to a product owner, they will have to define what needs to be done in detail but they will also need to present themselves as technical leads, offering continuous support to the developers. As soon as the agile swarm is able to finish a larger task the context will switch. The current expert might now be part of the developers and a different former expert might take the lead. The swarm tackles the new problem and when it is solved, it will move on.
There are some clear drawbacks from this approach. Efficiency being the most obvious one. We expect that after only a few iterations, the team should be able to compensate for the initial learning curve whenever they approach a new topic for the first time. Beyond that, the agile swarm will approach all existing problems in a strictly sequential manner, where in the past there were resources continuously assigned to a large set and everything got at least some attention.
The benefits on the other hand are also clear. Spread knowledge, break information silos and give a completely new motivation to communication in general. The swarm can only be successful when information is shared not only within daily meetings but also throughout the whole day. Experts have to face the challenges of managing teams, giving them a chance to develop their leadership skills.