When does swarming make sense?

Most of you know the situation when we had planned some work, let’s say a few different tasks. Then we started most of them, work in parallel and when time is up only a small portion of the work is really completed. In teams working towards deadlines or iterations this usually at least feels bad or has consequences, such as more budget needs to be requested or delay of delivery.

What most of you also know is the situation that we have finished work and for some reason have to come back and re-work, maybe even re-work several times. Re-work is expensive and we should aim to avoid that. Work done doesn’t mean something like re-work it later. Just to clarify, I’m not talking about iterating or incrementing a product. I consider re-work as change needed due to miss-understanding of what should be done, lack of quality due to time pressure or similar cases.

Both above mentioned cases could probably be avoided or at least reduced. In case of too much work in progress and less work done, the focus of the group by working together on less work items will increase likelyhood of getting stuff done earlier. Regarding re-work, more brains or eyes involved would have very likely led to the desiered result without or with less re-work.

Working collectively or swarm on a work item in order to finish what has been started before pulling new work items, requires that people involved have suitable skill. There is no benefit in swarming if the group googles together how things work. As with pairing also with swarmin the involved people should have a certain understanding to actually swarm. Of course some agreements (explicit or implicit) on how this close collabration should happen are required in order to avoid heated debates, demotivation or domination.

Once a team is ready for working closely together in larger groups, or even the whole team, there are several ways to do so. You could swarm on demand. For example if a problem occurs the group gathers and works out a solution collectively. You could also decide per work item to swarm, depending on the uncertainty, complexity or time criticalness of the given work. Also a certain day per iteration, per month or per week is a way to swarm.

Benefits that come with swarming

• Swarming provides real-time review and feedback of your work, which is actually very cost efficient. 
• Swarming supports a common understanding of what should be done and also of how it can be done (knowledge building). 
• People who participate in a swarm share their knowledge and educate each other (knowledge sharing).
• Encourages trust as mistakes will occur and be admitted on the spot. Be careful when it comes to vulnerabilities, a certain culture or basis for that should be present in your team.
• Counter-intuitive, but swarming can save time (for example by avoiding re-work).

Can swarmin go wrong?

• If the team or group is not ready for swarming communication wise or trust wise, swarming could harm the team as such.
• Swarming for the sake of swarming will very likely slow you down. There is no need to swarm for each piece of work that comes in. Swarming should be used where it adds value (for example in problem solving or to build and exchange knowledge)
• People could physically be part of the swarm but get disconnected and check out.