From the trenches: Swarming
What starts with S and ends with WARM
We formed as a Scrum team in September 2020. This team was to focus on a feature set of a new product for my organisation.
The Scrum team has five developers, a Scrum Master and a Product Owner. The team is cross-functional, anyone in the team can take an item from the Sprint Backlog to DONE.
Yet, the average time it took from start to DONE was six days.
Reactive Swarming
During the Daily Scrum, the discussion would be around Pull Requests (PR) that are waiting. The team would agree to review these as a team after the Daily Scrum. The discussion was always great.
There was always great collaboration to understand the way forward. Then — they would go back to working on an item each.
Several days later, something similar would happen. Eventually, the team would decide to swarm it and move past the issue.
Reflection
As a Scrum Master, I would struggle with what seemed obvious to me. If we took a more proactive or Swarm first approach, we could overcome these obstacles faster. Speed, quality, knowledge sharing, and collaboration may also improve.
Do I TELL them? That felt wrong. It felt like I would undermine self-organisation. Yet, as part of the Scrum Team, shouldn’t I share my thoughts on this? I am not from a developer background. Could this be imposter syndrome creeping in?
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. — 2020 Scrum guide.
Scrum Masters have many stances. Coach, Mentor, Teacher. Sometimes it is to do nothing deliberately. To give teams the space to reach their conclusions, and encourage them that this is OK.
Did the Sprint hit the bullseye?
The team reflected on the Sprint.
The team liked how swarming worked to progress an issue two of the team we’re facing. They had been pairing on an item, but progress was grinding to a halt with problem after problem.
The whole team got involved, discussed, debated, and challenged each other. It was a great collaboration, and something marvellous came out of it.
They were looking at items from the Sprint Backlog that were part of the same feature. Rather than doing the things, they thought about the Sprint Goal and how they could reach it.
They found a better path to the Sprint Goal. Less Sprint Backlog items, a clearer path to achieving the goal.
We looked back on this. “We should do that more” one of the team said. I probed — what might more stuff like this look like?
No one could think of a specific example, only generally having more collaboration.
I made it clear to the team that they were Swarming. Most had heard this term before. We talked about how this was awesome teamwork, and together — 2 brains are better than 1, 3 better than two and so on.
Seed planted.
I asked: “What if we did every Sprint Backlog item like this? Swarm first, maybe not everyone, but the majority?”. Some of the team loved this idea, but I could sense some unease from others.
I explained how the all too common three questions of; What did you do yesterday in a teaching stance? What will you do today? Are there any impediments in your way? Is now removed from the Scrum Guide. This omittance was to encourage a swarming culture over a status report.
Then in a mentoring stance — I talked about Empiricism, and not only in our product but in ourselves as a team. We have evidence that more swarming might work, and we need to explore if there is much more unrealised value in it. Or in other words
“Let’s try it, and see if it works. If it doesn’t, we will drop it”.
As a Developer, it is all too common that it is one person to one item. It can be quite hard to get used to swarming for some engineers after many years of cubicle style siloed work. People can be reticent, to the point of making up excuses why it won’t work.
It might feel embarrassing? Too far out of comfort zones or psychological safety is a little low? I won’t explore that today.
The next Sprint, the team immediately Swarmed the first item. At the start, items didn’t feel like they progressed as we had imagined. The team enjoyed the collaboration, so stuck with it.
By the end of the two-week Sprint; items were flying to done as we had envisioned. The team explored different ways to work in the same code branch. Knowledge sharing increased. Enthusiasm seemed to increase.
Over the next few Sprints, the Developers embraced this habit. At times, there was only a single item on the board as WIP (Work In Progress).
Time seemed to free up, and slack appeared in the system. We used this time to improve as a Scrum Team.
We did a little more refinement.
We spent a bit more time researching things of value.
Got a little closer to other parts of the Product that another team worked on.
Met our Sprint Goal early.
Worked on some bonus ‘nice to have’ items.
Cycle time dropped from, on average, six days, to 3 days.
All tickets in the Sprint Backlog became ‘doable’ because of everyone’s involvement.
There was much less scope creep, and developers stopped going down as many ‘rabbit holes’.
Product knowledge increased.
The team got to know each other better.
Human interaction increased. It didn’t feel like endless meetings. In a 100% remote environment, the value of this was immeasurable.
This was awesome.
Why does it matter?
On the surface level, doing things faster always sounds great. We can have a lovely burn down, and everyone is happy that all the work is complete.
That’s all that matters, right? Not if you want to get the value out of Scrum.
As we dive deeper, it’s actually about the feedback loop. Getting done sooner means we are shortening the feedback loop. This team understood this well, to quote one of the developers “Value is binary; it is 0 until it is delivered.” I loved this.
Some of the more powerful swarms we did not close items. Rather, we discovered a better way. Often, this included the customer in the conversation. This gave both sides context, and we worked together to solve the problem.
This was awesome to be a part of.
Bits n bobs:
We picked up a nice habit in remote swarming to swarm within a Microsoft Teams Channel itself, rather than a chat or meeting invite. This felt more ‘out in the open’ and seemed easier for anyone to jump in and out.
As we Swarmed each Sprint, the Sprint Goal became more and more critical. This team was never bad at using Sprint Goals, but its use as a compass to guide the Sprint became more powerful. Remember, we are backpacking.
As part of our Swarming, we were at times Mob Programming. I love this from Comic Agile.
To enable pairing and mob programming, this team used VS Code and the Live share extension. This allowed them to remote pair to the levels of one keyboard would be in the office. They also loved how it was a huge help to avoid merge conflict pains. They love this and recommend it to anyone working remotely.
Sometimes Microsoft Teams didn’t work that great quality-wise. We worked around it, sometimes a Google Video, sometimes a Zoom. There is always a way.
Thanks to Jon, Matt DiBerardino and Fredrik Carleson for their help in pulling this post together.
