Swarming is a technique used by ant colonies for finding the shortest path to food using pheromone trails. However, in software development, swarming is used for problem-solving and bug fixing. It gives an engineer a chance to look at the code from another perspective and fix bugs he would otherwise overlook.
Swarming is not a new concept and has been used by most software development companies in one form or another. If your organization is a startup with only a few engineers working on the same code base, then swarming may give you an edge over your competitors.
Swarming Can Be Done Using Two Approaches:
One developer works on a bug fix while others add features to the code base, or all developers are focused on a problem fix for some time so that everyone understands it better before they go back to their regular tasks.
When doing it this way, each engineer contributes something towards fixing the bug and understanding all the code-related pieces. So, later if someone else encounters the same bug, he would have prior knowledge about it.
You may even uncover hidden defects in your codebase using this method of swarming, which otherwise could be very expensive to detect when they manifest as failures in customer environments or production systems. Some examples where developers might swarm around are
- Fixing an elusive bug (e.g., debug logging, checking for race conditions)
- Understanding the architecture or design for a particular component
- At the end of a sprint, the team may swarm around the user stories that were not completed.
The Best Way to Make the Most of Your Swarming Sessions
1. Identify a bug or an issue that can be resolved fairly quickly so that everyone on your team has enough time to focus on it. It is also important that your organization’s priorities are well defined before you start swarming so that no one leaves mid-way through a session due to incoming critical work.
2. The first step in swarm programming is getting the entire team together as early as possible and having them help each other understand the problem being addressed with this session(e.g., get more context about how/where the code works). If there is an existing JIRA ticket for this bug, ensure it contains enough information (especially about what isn’t working or what is not working as expected). This will help all the participants understand the intent and background of this swarming session.
3. Next, have your team members review each other’s code and dependencies so that they can be prepared before taking ownership of a bug (e.g., if a developer has to fix an issue about another module/library in your codebase, then he should become familiar with it beforehand so that he doesn’t waste time on looking up API docs while trying to fix it). Some developers need to follow along with others’ swarms to understand the codebase doesn’t regress over time.
4. After everyone has had enough time reviewing each other’s work and understanding the problem, it’s time to have each person work on the bug. Once everyone is working, a common approach is for the designer or architect of the particular component (or design) to walk around and help developers where needed.
5. Make sure that all members of your organization understand what swarming and swarm programming are before trying this out. You may also want to give some examples of how successful companies are using it so that everyone can visualize its effectiveness during meetings/sessions like stand-ups.
Wrap-up: How Can You Get Started with Swarming?
Swarming is really about maximizing the utilization of each member on your team through learning and using context switching to your advantage. Your software delivery rate can be increased while your team’s productivity doesn’t suffer because a cross-functional combination of thinkers and doers is working on resolving issues together.
With this technique, you can ensure that each team member will only be working on one problem at any point in time, thus increasing their productivity by creating a self-organized team.
By focusing your entire team on the task of fixing bugs together, you’ll also find that they’ll start to share an intrinsic motivation (as opposed to extrinsic motivation) in collectively resolving a problem together. This will lead to better quality and a happier team that supports the agile values and has an increased likelihood of tackling more problems than they could on their own.