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.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
2 comments… add one
Pawel, I think swarming both on critical issues and average issues can be helpful. Critical issues benefit from swarming in as you say “you get more people to move things further”. Average issues benefit when you have junior resources that feel uncomfortable asking for help. Instead of burning time, heads down, trying to figure it out all on their own and putting the release at risk, the goal is to have a culture that has team members “swarming” to help. But, at the same time, having every reported bug/defect kick off a swarming effort can cause significant distractions/inefficiencies.
In truth, my experience as it relates to swarming, is in trying to create a culture that allows developers to leverage swarming assistance when they are at risk for not having a quick fix to a reported defect as time is expiring. Yet, not forcing a specific discipline that requires swarming based on some arbitrary criteria.
Actually swarming as needed is pretty healthy approach and it is often used in different teams, not only ones which work with Kanban. The problem I have with everyday swarming is some teams enforce it setting very low limits on the board.
This way you basically have to swarm over feature because there are fewer slots for tasks than there are people in the team. It happens even if everyone feels comfortable with their tasks. But if it works for them, fine, I’m not going to tell them that’s wrong.
And when someone don’t like or don’t want to ask for help when in need, I’d look for a solution not in swarming but in changing their attitude.