Background

A few years ago, my team was working on launching a software product for streaming digital advertisements during the Super Bowl event in the US. The team had performed extensive testing, and all the happy and negative test cases had passed. The software was packaged and shipped to the end customer for the final acceptance testing before the launch. As the end customer started testing, it hit a snag, and tests started failing. All hell broke loose as the failure to use the product would have resulted in revenue loss to the tune of millions for the customer along with a huge penalty for us. We had 72 hours to make it work or be ready to pay the penalty.

Our usual approach for resolving any production problem was to call a team meeting, brainstorm on the issues, and discuss the steps for troubleshooting. After that, developers and testers would branch out and start working on their respective tasks. After a few hours, the key team members would regroup and provide an update. The process would continue until the team would have found the solution. However, this time, looking at the urgency, the team decided to follow a different approach. The team decided to work together so that the team’s collective experience was leveraged for solving the problem. The entire team got together in the war room, and the team worked together for 18 continuous hours – brainstorming, whiteboarding, recreating the failure scenarios, and trying quick fixes over and over. Every idea was welcomed and tried.

Finally, the team cracked the problem. The issue was fixed, and the software successfully functioned throughout the Super Bowl event and everybody was happy.

I am narrating this old story as I find it contextual. What we did for 18 hours was nothing but a technique called ‘Swarming’. The term was unknown to us back then but today, we know what we practiced was Swarming. And I think many of us would have used this technique in various situations.

The problem statement

The software engineering discipline is beleaguered by numerous wastes nicely highlighted by Mary and Tom Poppendieck in their book Lean Software Development: An Agile Toolkit. They have described that the seven wastes of software development are delays, handoffs, task switching, partially done work, extra features, relearning and defects.

Figure 1: 7 wastes of software development

For further reading on the 7 wastes of software development, please visit https://codepunk.io/the-seven-wastes-of-software-development/.

Pairing, Swarming, Mobbing and Fractals

Pairing, Swarming, Mobbing, and Fractals are a few techniques that have been practiced to reduce the wastes in software development.

Swarming/Mobbing reduces the wastes in the software development cycle by creating a collaborative, real-time validating environment that tackles issues related to the understanding of requirements and design, hand-offs, delays, task switching, defects, and relearning.

Pairing or Pair programming has been used for several years as key Extreme programming (XP) practice with good effect. In this construct, two developers work together on coding and testing using one single computer. The developer at the keyboard is usually called the “driver”,  and the other developer also actively involved in the task, but focusing more on the overall direction is the “navigator”.  The two developers switch roles frequently (in 15-30 minutes).

Swarming/Mobbing is a software development approach wherein the whole teams work on the same story or task at the same time. Swarming/Mobbing strongly advocates to adhere to a WIP (Work-in-progress) limit of one per team to bring in increased focus and reducing productivity loss due to context switching.

Swarming/Mobbing could be either done for all the tasks or could be practiced more selectively for specific tasks. Besides, a team could decide on the time they would like to spend on swarming or mobbing, the whole day every day, or one day a week, or only for a few hours in a day.

Mobbing or Mob Programming extends the concept of pair programming from two people working together to the entire team continuously collaborating at a single computer to deliver a single work item at a time. Teams practicing Mobbing work together on almost all the tasks of a typical software development cycle including working with customers, defining requirements, designing, testing, and deploying software.

Mobbing involves two key roles, the driver and the navigator. The navigator gives instructions, while the driver only focuses on carrying-out the instructions given by the navigator. When the navigator runs out of ideas, he or she seeks inputs from the mob. The team (mob) is constantly engaged in the exercise through verbal inputs from the navigator and visual inputs from the projector screen. At a fixed interval (typically 5-15 minutes), the roles change, and the team rotates clockwise.

Just like mobbing, in the Swarming approach, the whole team works on the same story or task at the same time. However, there is no restriction on working on one computer.

There are some differences between pair programming, Mobbing and Swarming constructs which are summarized below.

Pairing = 1 driver and 1 navigator working concurrently on one (1) story/task. Single input, single output.

Mobbing = 1 keyboardist (Driver) and 1 Navigator, multiple observers concurrently working on one (1) story/task. i.e. Multiple inputs but a single output channel.

Swarming = Multiple keyboardists working concurrently on one (1) story/task. i.e. multiple inputs and multiple outputs contributing to the same story.

Fractals

The term fractal comes from Geometry.  When a geometric shape is split into parts, each of which is a reduced-size copy of the whole, then the parts are called Fractals. Each fractal thus inherits the characteristics of the object that it was created from. For example, in the context of the Scrum teams, the fractals can be  T-shaped sub-teams of 3-4 members within a T-shaped self-organized Scrum team, inheriting all the characteristics of the Scrum team. 

When a team is larger than the 5-9 members team, there could be some challenges in practicing Swarming or Mobbing. The challenges could be the lack of engagement of all the members during swarming or issues related to social loafing. The fractal construct addresses these issues.

The fractal construct is illustrated in Figure-2  below.

The Fractal constructs offer several advantages including:

• Reduced communication complexity
• Increased accountability
• Decreased tendencies for social loafing
• Better enforcement of WIP limits
• Increased focus and commitment

When and how to use Swarming

Swarming technique works very well for the tasks requiring collective knowledge. Furthermore, Swarming is effective where a reduction in cycle time is a priority. Swarming has been practiced for several years in different ways. There are no set guidelines or patterns for team size, team forms, duration (full or part-time).  However, larger teams have experienced a lack of engagement and social loafing during swarming. For these reasons, the construct of smaller teams (3-4 people) or fractal is recommended. I would advocate using swarming for planning, requirement detailing, design, troubleshooting, solving production issues, working on spikes, test case preparation. In addition to tasks for swarming, the team can also decide on the duration of the swarming. For certain tasks, the team can decide to swarm for the entire day. In other cases, the team may find a two-hour swarming session per day adequate to get the job done.

Can swarming work for disperse teams?

This is a valid question and very pertinent in today’s scenario where teams have got dispersed due to world-wide locked down.

The answer is yes if the team is equipped with proper communication and teaming tools such as Microsoft team or Zoom, which supports video communication, screen sharing, whiteboarding, chat, and break-out rooms.

Currently, I am coaching a few offshore teams who are practicing remote swarming for Backlog refinement and Technical design effectively. The team has set 2 hours a day cadence for swarming. These teams work in the same time zone, so the challenge of overlap hours does not exist. Additionally, the offshore teams regularly swarm with US-based SMEs during the overlap hours. 

Using fractals for effective swarming in Scrum

• The development team could be split into T-shaped fractals of 3- 4 members.
• Fractals are fluid structures and team members are rotated periodically (maybe after 2-3 sprints) based on what the development team needs to deliver in the upcoming sprints. This is critical to remove the bias amongst the team members towards the type of work as well as towards team members.
• Each fractal picks up stories to work on for development as opposed to team members.
• The WIP Limit of one story per fractal is put as a guideline and strictly adhered to.
• Each fractal continues to split the story into tasks as required.
• Each fractal picks up tasks for swarming and swarms on a set cadence and duration as required.
• All the fractals of a scrum team would swarm discuss the interfaces between the stories and other dependencies.  
• There is no change in the construct of the team and the roles of the team members- Product Owner, Scrum Master, Development Team.
• The team continues to practice common sprint events and follow common working agreements, Definition of Ready, Definition of Done.

Summary

Swarming enables knowledge sharing and real-time collaboration. Due to this, swarming has proven to be an excellent teaming technique for resolving complex issues in fast-paced organizations where results have to be demonstrated almost immediately. Swarming helps in removing bottlenecks arising out of gaps in the technical understanding (Skill, domain knowledge) and leads to a highly amplified learning environment. It reduces queues, the wait time, and handoffs. Swarming raises the process efficiency due to WIP Limit, which leads to increased velocity. Fractals reduce the communication complexities in the larger teams, decrease the tendency of social loafing, and bring in increased focus and commitment.

However, the fractal construct and practicing swarming technique require a change in the work style for everyone involved. And change doesn’t come easy and quickly. Teams must be coached on these constructs and practices to secure their buy-in. The change will be effective when the team feels that the change is not forced upon them.

References

Zuill, Woody, Mob Programming – A Whole Team Approach

How Fractals Work – https://science.howstuffworks.com/math-concepts/fractals.htm