Part 13: Unleash Your Scrum with Multi-Skilled Professionals — The Power of Swarming and Combining Collaborative Work Modes

In the previous article of our “Unleash Your Scrum with Multi-Skilled Professionals” series, we delved into mob programming, a collaborative coding practice that amplifies teamwork and accelerates problem-solving. Like pair programming before it, mob programming can break down silos, promote knowledge sharing, and ultimately lead to higher-quality products.

But the Agile toolbox doesn’t end there. To truly unleash your Scrum team’s potential, we must equip them with diverse collaborative techniques, each tailored to different challenges and situations.

In this article, we’ll introduce swarming, a dynamic and adaptable approach that complements pair and mob programming. Swarming empowers teams to tackle complex challenges head-on by harnessing collective intelligence. Imagine a team spontaneously coming together to troubleshoot a critical bug or proactively focusing their combined skills on a high-priority feature. This is the essence of swarming.

We’ll explore the origins of swarming, its various forms, and the benefits it brings to Agile teams. But most importantly, we’ll uncover how swarming, combined with pair and mob programming, can create a powerful and adaptive framework for continuous improvement and multi-skilled team development.

If you’re joining me for the first time, I recommend reading the previous parts for context:

Unleash Your Scrum with Multi-Skilled Professionals — Series Outline

Chapter 10

10.6. Creating Social Ability

Try … Swarming

Created with Dall-e

A Short History

Picture a flock of birds gliding through the air, synchronized and purposeful. This mesmerizing sight isn’t just visually stunning; it’s a powerful example of how coordinated effort can achieve remarkable results. Swarming, a strategy inspired by nature, has been embraced by diverse fields for its ability to optimize complex processes.

The term “Swarm Intelligence” was introduced by Gerardo Beni and Jing Wang back in 1989, aimed at designing intelligent multi-robotic systems. They were inspired by the mesmerizing coordinated behaviors of birds, fish, and insects, emphasizing the system’s behavior as a whole rather than the capabilities of individual units.

The idea of swarming isn’t new to humans; it has historical roots in military and aviation contexts, among others. For instance, swarming has long been a military strategy in which decentralized forces surround and overcome adversaries, showcasing a fluid and coordinated approach to tackling challenges.

In Lean manufacturing, the Toyota Production System (TPS) embraced a form of swarming through a system called “Andon.” When a defect was spotted on the production line, an alert would trigger, halting the process. The entire team would then swarm around the issue, pooling their collective intelligence to resolve it swiftly and ensure top-quality production.

How Does It Work?

Unlike Pair or Mob Programming, swarming doesn’t follow a strict structure. It’s more free-form. It’s about taking those frustrating moments when the code just won’t cooperate and turning them into collective problem-solving and learning opportunities. Every developer has faced it — that point where a fresh perspective could be the key to untangling a complex issue. Swarming leverages this by bringing together different viewpoints to tackle the task at hand.

In swarming, when a task is deemed critical, it becomes a collective endeavor. Whether it’s an issue that’s arisen, a user story, or an impediment, the idea is to call on the team and tackle it together. The beauty of swarming lies in its flexibility — it could be a pair or a trio of developers or, at times, the whole team diving in to get the job done.

The trigger for a swarm could be a sudden, unexpected problem like a system crash or a critical customer issue. But it’s not always about firefighting. Teams can also choose to swarm as a proactive strategy, especially when they anticipate challenging issues during development. It’s about staying a step ahead, recognizing that when tough problems arise, a united effort from the get-go can be a game-changer in swiftly navigating through them.

Swarming also brings a rich mix of expertise and experience to the table. This approach’s fluid nature allows members to join and leave the swarm as needed, contributing their unique insights while learning from others.

Swarming Variations

Branching Out

The essence of swarming or mobbing centers around uniting the team to focus on a singular work item. However, there are instances when some tasks may not warrant the collective attention of the entire team. During such times, activating a “parallel” mode becomes beneficial, allowing a member, a pair, or a subgroup to branch out and address an impediment. Once resolved, they rejoin the primary swarm, enriching the group with their newfound solutions.

The “parallel” mode encapsulates the notion that while the team is collectively driving a single work item towards completion, individual or smaller grouped efforts can be made to overcome various hurdles hindering the progress of the current work item.

Branching out is particularly useful when routine or low-complexity work is on the docket. Similarly, when an urgent issue arises, a member or a pair can branch out to investigate and, if feasible, resolve it. At the same time, the rest of the swarm continues with the original task at hand.

However, it’s crucial to resist the temptation to branch out when there’s an opportunity for automation. Maintaining the swarm and channeling collective efforts toward automating the current problem is the more prudent approach in such scenarios. This resolves the issue at hand and sets a precedent for tackling similar problems in the future.

Spreading Out

Harnessing the team’s collective knowledge is instrumental in designing and implementing a fix for an issue or defect effectively and efficiently. However, once a solution is crystallized, its application across the codebase may demand considerable effort, possibly engaging many team members for an extended duration. This phase might entail some repetitive actions to amend or adjust certain aspects.

Upon addressing the initial occurrence as a group, the team can transition into a “spread out” mode, distributing the task of applying the solution throughout the system. This could be executed individually or by forming pairs, depending on the nature and complexity of the task. Once the solution is comprehensively applied, the team reconvenes to discuss various aspects of the defect and the applied solutions, document the experience, and ensure the correctness of the changes made. The essence of spreading out mirrors that of branching out, but with a heightened emphasis on parallelism to expedite the process.

Again, it’s imperative to restrain from spreading out if an automated solution is plausible. In such instances, keeping the swarm intact to work on automation would be a sagacious approach, ensuring a resolution for the present issue and a streamlined process for similar challenges in the future.

Keeping One in the Dark

Engaging as a swarm for extended durations has merits, but it can sometimes give way to groupthink. In this scenario, the quest for unanimity might overshadow innovative thinking, resulting in biased decisions rooted in conformity.

To circumvent this, a strategy could be to have one team member step aside from the swarm until a particular task is completed. This interval could also be an opportunity to introduce a new individual from outside the team into the swarm, infusing fresh perspectives and novel ideas into the collective effort.

Once the task is accomplished, a thorough code review is conducted. Here, the solution is presented to the temporarily detached team member, offering them the platform to scrutinize and question the decisions made. Their fresh outlook might unveil new dimensions, and if their suggestions hold merit, they can be seamlessly integrated into the overall solution, enriching the final output.

How Does It Help Multi-Skilling?

The cross-skilling benefits observed in Pair Work and Mob Programming also extend to Swarming. Multi-skilling blossoms through the communal sharing of knowledge, coupled with the ongoing creative dialogue and exchange of ideas that transpire when tackling a task as a team.

Venturing into Swarming

The “Andon” technique from the Toyota Production System can be seamlessly integrated into the Team Agreements. This way, whenever a team member hits a snag or a problem arises, a virtual “Andon” is triggered, rallying the whole or part of the team to swarm around the issue.

Strategically, the team can earmark such activities during the Sprint planning or while orchestrating the day’s tasks during the Daily Scrum. The aim is to cherry-pick tasks that stand to gain from the collective intellect of a swarm, with cross-learning and cross-pollination emerging as a rewarding byproduct.

When stumbling upon a particularly knotty problem that calls for more profound expertise, pairs may rope additional team members in, morphing into a swarm. In a co-location setting, swarms have the potential to materialize spontaneously. A simple spark could be one team member catching wind of a colleague or colleagues wrestling with a problem through osmotic communication, setting the stage for getting together to untangle the issue.

Try … Combining All Three Modes of Working

The trio of working modes — pairing, mobbing, and swarming — offers unique on-the-job learning and cross-skilling avenues. They empower teams to choose the most appropriate approach to tackle the task at hand in a rich learning environment.

Practicing these modes equips the team to seamlessly blend the solo, pair, mob, and swarming rhythms in their work based on the demands of the moment.

Consider a scenario where a pivotal task lands on the team’s lap, say, integrating a new API. The team huddles, deciding, “This is hefty and crucial; let’s mob it up!” This phase is akin to a brainstorming session where every team member contributes their insights, collectively sculpting a plan for the API integration.

Now, with a solid plan in hand, it’s time to break into duets. One pair leads on the frontend while the other dives into the backend. With the team working in pairs, the process is still choreographed — the pairs code each in their realm yet in sync with the broader plan established during the mob session.

As the team gains experience in these practices, they become adept at discerning the most suitable mode for each task. It’s about recognizing when the collective brainstorming of a mob or a swarming session is the need of the hour or when the focused attention of pairing will drive the task home. Sometimes, the quiet focus of solo work is needed to fuel creativity, which will later be shared with the team.

A Day in the Life

In “Creating Agile Organizations,” Cesário Ramos and Ilia Pavlichenko share how a day might unfold for a team adept at interweaving the different work modes.

At the Daily Scrum, the team focuses on the next crucial feature needed to meet the Sprint Goal. They outline their daily plan and begin with parallel work and pair programming. Several pairs of developers start building a test suite by writing acceptance tests, each pair tackling a small piece of functionality. At the same time, another pair concentrates on the user interface, while a third pair improves the requirements with more acceptance tests.

After several hours of pair programming, the team meets again to plan their next steps and share what they’ve learned. They decide to switch to mob programming because working in parallel seems less effective now. Together, they begin combining the parts they’ve built.

Later in the day, with the feature tested, attention moves to documentation. Transitioning into swarming mode, the developers split into two subgroups, tackling the documentation in tandem, ensuring the feature’s readiness by day’s end.

Navigating these three development modes requires a shift from traditional practices and involves patience and training. It’s a journey supported by kindness, consideration, and respect. As we discussed earlier, introducing these modes as an “experiment” can be a gentle way to guide the team toward a new way of working. This creates an atmosphere of psychological safety, assuring the team that this journey is about learning and adapting together, not a forced change.

Kick-off with Modesty

Begin with modest sessions lasting no longer than two hours, conducted several times a week. Limit the initial sessions to a small group of three to five individuals to minimize anxiety and expedite the transition through the storming phase. Kick-start with simple code kata — coding challenges aimed at honing skills and techniques before progressing to more complex tasks in subsequent sessions.

Creating a Conducive Environment

Select a convenient setting, such as a meeting room, for the initial sessions, where the team can sustain a sense of safety, focus, and communal creativity. Enhance the collaborative atmosphere by providing a large whiteboard or flipchart sheets for visualizing ideas. Pre-install a familiar coding environment and editor on the designated machine to ensure a smooth start.

Maintaining a Healthy Rhythm

To safeguard against fatigue, adopt the Pomodoro Technique, taking short, regular breaks every 20–30 minutes. Conclude each session with a retrospective to reflect, learn, and adapt.

Fostering a Sense of Freedom

Make it clear through the “two legs” rule that anyone feeling uncomfortable or fatigued can exit the session and engage in other productive activities.

Persistence is Key

Help teams to engage with the three modes over a month. When challenges arise, re-emphasize the overarching benefits pursued, ensuring they are visible and well-understood. Celebrate the positives emanating from these sessions. Post the one-month mark, empower the team to either revert to their previous working style or continue with the new modes. Cesário Ramos and Ilia Pavlichenko observe that a month’s practice typically unveils the primary benefits to the team, with most teams choosing to continue with the new working modes.

As we’ve seen, swarming is a dynamic technique in the Agile arsenal. It offers a flexible and responsive way to tackle complex problems, encourage collaboration, and accelerate knowledge sharing. However, when integrated with pair and mob programming, it truly shines, creating a synergistic trio of collaborative practices.

Each mode — pair programming, mob programming, and swarming — has unique strengths. By learning to transition between them seamlessly, teams can adapt to the varying demands of Agile development, harnessing collective intelligence to its fullest potential.

With this exploration of swarming, we conclude our deep dive into the fourth source of influence in the Influencer change model: Social Ability. Over the last four articles, we’ve explored a spectrum of socially driven practices designed to boost teamwork, knowledge sharing, and collective problem-solving.

This extensive focus on Social Ability reflects its immense impact on team dynamics and performance. But while Social Ability unlocks immense potential, it’s not the sole answer to building high-performing teams. We must also consider the environment in which these teams operate, including the structures, systems, and incentives that shape their behavior.

In the next article, we’ll turn our attention to the fifth element of the Influencer Change Model: Structural Motivation. We’ll explore how aligning incentives and creating a supportive environment can further multi-skilled teams, driving them toward greater success and fulfillment.

References

1. Cesário Oliveira Ramos, Ilia Pavlichenko. Creating Agile Organizations. A Systemic Approach (Addison-Wesley, 2023)
2. Joseph W. Yoder, Danijel Arsenovski, Ademar Aguiar, Hironori Washizaki. Delivering Value with Confidence “Swarming Patterns” (12th Latin American Conference on Pattern Languages of Programs, 2018)