If you’re into Kanban you probably have heard the term swarming. Actually chances are good you’ve heard the term despite your lack of interest in Kanban.

What is swarming?

In short swarming is all about getting more people to do the task than you’d get otherwise, in normal situation. An example: you have a bug which normally would be fixed by a single developer, but for some reason you have the whole team working on it. And you already have another question…

Why, oh why?

Why would you want people to swarm around a small task? Typically teams do this when they face either a blocker, which hampers whole team, or a very difficult problem, which is hardly solvable by a single person. Either way you get more people to move things further, which would be impossible or at least very difficult otherwise.

Swarming in Kanban, part 1

Up to this point swarming is something teams do intuitively at times. The reason why the term is mentioned so often in the context of Kanban is one of Kanban rules: limiting work in progress. Because in Kanban we want to have as few ongoing tasks as possible, yet as much as it still does make sense, we have limits for different stages of our process. And it when we hit the limit we treat it as a problem which we want to solve and we want to solve it fast. That’s why we swarm.

Swarming in Kanban, part 2

There is another thing which you may read about, which I call everyday swarming. Everyday swarming is done by teams which swarm by default, when no emergency situation happens. The reason standing behind this behavior is trying to make cycle time and/or lead time as short as possible thus flow of tasks very rapid and smooth. Oh, and you have fewer ongoing tasks then too, which means you have less work in progress, which means you have less waste, which means you are oh so lean.

Our story

I must admit I don’t really like the idea of everyday swarming. I mean cycle time is definitely shorter but I’m so sure about throughput. Flow is smoother but you kick in a lot of micro-switches when a few people need to integrate their work into one piece of code since they all have worked on a single feature. You also may invite some issues with version control this way since you’ll be working on the same chunks of code. For me the net weight of swarming by default is negative.

Basically that’s why we avoid swarming whenever possible. When there is some serious problem to solve and standard approach is not enough we naturally help each other. One person after another joins the rescue team and this basically ends as swarming. But other than that we prefer to have only one person working on the task at the same time. Well, of course there are exceptions like discussing design or testing and bug-seeking/bug-fixing but these all are pretty natural things for any software development team. After all it would be pretty schizophrenic to discuss the design with oneself.

It looks like we swarm as David Anderson initially proposed, despite ignoring David’s teachings when it comes to lead time. I think this is the most natural way of swarming. But of course you remember the rule to experiment like crazy, so you may want to try something different in your team.

Read the rest of Kanban Story as well.