Agile Swarming: Evolving beyond Scrum

This blog is about our journey and evolution as an ‘agile’ team. In the initial days, we were not even close to being a good team, but today, I can proudly say that we have progressed and evolved as a truly agile team. Like many, we follow Scrum methodology, and hence will be using mainly scrum terminology in this article.

I would like to share some highlights in our agile journey from level 0, where we thought that we were agile but not by any means, to level X, where we proved that “Yes, we are agile “.

Phase 1: Starting from definitions…

When we started the journey, we followed the scrum ceremonies as a defined way of doing rather than taking its intent and value to the core.

In the daily standups everyone used to answer the 3 questions with ease like a student who is in an exam hall and knows the answers to every question. In case of retrospective another set of 3 questions. It was like focus on self, in a way.

Phase 2: Understanding the essence…

We realized that merely following different scrum ceremonies as per their textbook definition doesn’t help us. We started identifying the real essence of each ceremony and instead of doing started enjoying the process.

In daily standups, everyone started describing what they have done w.r.t. sprint goals rather than talk about a specific topic. We started treating sprint retrospectives as a platform to improve the process and followed different ways (fun but most effective) to achieve the team goals for that sprint. There were a lot of discussions where we were thinking how to get the most important statements to come out in retrospectives and also a strong no if someone was unable to pick a thing in a sprint.

Phase 3: From following agile in a team to becoming an agile team

As a scrum team, the primary goal of a sprint is to deliver a potentially shippable increment at the end. Though the team planned to deliver a certain set of stories as part of the sprint, sometimes stories can’t be completed within the timeline.

Here is a sprint where we haven’t completed all the stories. We just wanted to do a retro on why we have missed some stories.

The retro went like …

Product Owner: Well, I’m not happy, not because we haven’t completed everything, but because we missed implementing the top priority item in the sprint. Want to know the reason why we missed out and what can we do to prevent such incidents in future sprints?

Immediately the whole team was looking at a specific developer (X) who worked on it throughout the sprint.

X started giving an explanation on what went wrong and the entire team was sharing its inputs.

Subsequently, we also discussed the status of the remaining spillover stories as well and realized that all these stories were about 70 – 90 % done and a little more time could have moved them to ‘done’ but the sprint duration is fixed and can’t be changed!!

By looking at these two incidents we reached the following conclusions:

Are we committing a specific story as an individual or as a Team? If we are committing as a Team, then who is responsible for completing it? Of course, it is the responsibility of the Team and not individual team members.
It’s always better to have 70% of user stories 100% done than having 100% of user stories 70% done.

As we were on the lookout for ways to improve our team performance, we heard about Mob Programming and Agile Swarming. Here is a brief gist about these agile techniques:

What is Mob Programming?

According to Woody Zuill, the technique’s creator, mob programming is defined as:

‘All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer.’

As per the above definition, using this technique, a group of people sit together with a big monitor or projector connected to a computer. At any point of time, one person takes the lead in carrying out the mob’s instructions.

How does mob work in a sprint?

There is only one item in WIP (Work In Progress). The mob moves to another item only, if there is an impediment and they can’t proceed further, or if the picked up item is moved to done. With this technique, you can be assured that even if it is not a perfect sprint, you will not be left with a bunch of stories that are partially-done.

Advantages of Mob programming

Mob creates a situation with one pair of hands and multiple brains. With the whole team focusing on a single task, this accelerates the speed at which a story progresses to done. This technique allows more paths to identify the solution for a complex problem, and the team starts to understand each other’s strength and weakness.

You become a better team than before. There are many other benefits of mob programming:

No dependency on a single team member as the whole context lies with the whole team
“Learning by doing” and real-time Knowledge Transfer
No extra time required for code review, as the entire team knows what every code change is there for…
You learn and improve as a team than an individual.

Realizing the potential benefits, we wanted to start implementing mob programming. But we ran into an implementation challenge, as our scrum team has members from multiple geographic locations with a substantial time zone difference.

Then we looked at Swarming.

What is Swarming in Agile?

Using swarming technique, the entire team (or a significant portion of the resources) is allocated to a single task (also called a story), so that the work at hand is completed more effectively.

What are the different roles?

Swarmer: A swarmer is a person who moves from one story to another offering his/her skills or technical expertise where they are needed.

Coordinator: A coordinator is a person in charge of the story. A person can be the coordinator for only one story at a time but can be a swarmer for other stories.

TeamLet: A TeamLet is a group of people working on a given story, and each TeamLet has one coordinator with one or more swarmers.

(Source: https://www.educba.com/swarming-technology/)

Well, we decided to try out Swarming by forming two TeamLets with two items in WIP as described below:

We started with two TeamLets, some permanent swarmers (QA, Functional Consultant) and one swarmer who can join with any team as needed.
Once a story is picked up by a TeamLet, there would be a discussion on all steps needed to move the story to done as per Definition of Done (DoD).
At the end of the discussion, the coordinator for that story was identified, review their progress and share any learnings with each other.

What were the results?

Initially, there were some apprehensions about underutilization of team members. When you look at the pace at which a story is moved to done and how well the communication happened in a TeamLet, the team didn’t notice any underutilization. Nobody felt over-stressed or stuck looking for someone’s help.
There is a significant drop in the number of bugs reported while testing the stories, as it became a routine to execute the regression tests in the development phase itself.
We noticed a significant change in Product backlog refinement sessions. With more team bonding, no hesitation of sharing their views and explanation has become easy by referring to recently completed stories.
We have seen good progress in the burndown chart and consistency in sprint velocity.

Conclusion: In our experience, we realized significant productivity gains by adopting agile swarming. Finally, after a long journey we are enjoying the benefits of becoming a real Team, and understood that It’s all about thinking and executing collectively as a TEAM. Proud to say that we are now truly "AGILE”.