5

While the term "swarming" is used quite commonly, I found it hard to find a definition for it.

Different swarming approaches seem to range from "do pair programming, if otherwise the WIP limits would be broken" to "all people work on a single problem, all the time". Similarly, the opinions seem to diverge on whether swarming should be avoided or be the way of working.

My goal when asking this question is not to have the range of opinions represented in different answers. My goal is to understand different forms of swarming and which form to use in which situation and project management style. My impression is that swarming is an umbrella term for different ways of working involving more than one person to work on a single problem. Are there more precise terms that could be used for the different forms of swarming, in order to avoid misunderstandings?

I added the 'kanban' tag because I had to add at least one tag and swarming is often used in a Kanban context. However, I’m also interested in a general, method-agnostic definition.

Manuel Jacob
  • 151
  • 3

1 Answers1

7

You are correct that it is often used as an umbrella term. However, when you apply some math and theory, we can get a bit more specific.

Much of the WIP conversation in Kanban centers around Little's Law from queuing theory. You can look up the math around it if you'd like but it basically shows that in a graph of throughput (y-axis) over WIP (x-axis) throughput peaks at some WIP value and then drops. The take home message is that a group of people doing only 1 thing at a time often leaves people idle but taking on too many things creates overburden and also reduces productivity. Therefore, to gain the highest level of productivity, the group needs to find the balance where they are not too idle and not too overloaded. Henrik Kneiberg has a great demonstration of this on YouTube called The Utilization Trap.

So, for the purposes you describe, the most useful definition of swarming is probably adding people to a single problem until a point is reached that another person helping does not meaningfully increase the speed at which the task is done.

A common way to achieve this is that the board is worked right to left with each person first checking if they can help a task forward before moving left on the board. In this manner, no new task is started if someone could be helping on an in-progress task instead.

Daniel
  • 16,867
  • 2
  • 21
  • 49
  • Thank you for your answer. Can you clarify what you mean by "no new task is started"? Does it only mean that no task should be pulled from "backlog" into an in-progress step, or also that noone should pull any unassigned task on the board (e.g. from "implementation accomplished" to "review in progress)? I hope the question makes sense without knowing our exact workflow. – Manuel Jacob Aug 16 '19 at 16:02
  • 1
    @Manuel, if the person looking for work can assist someone else in moving a ticket that last step to 'done', then that should be preferred over picking up an unassigned ticket. – Bart van Ingen Schenau Aug 17 '19 at 16:10
  • Bart is right in line with my experience. If you have columns 1 through 6 where 6 is done, items in column 5 are worked on first, then column 4 and so on. This optimizes your system for turn-around time and throughput. This is a good video on the topic (though it doesn't specifically talk about the kanban board): https://youtu.be/CostXs2p6r0 – Daniel Aug 19 '19 at 13:10
  • Always also be on the lookout for the "lone-wolf problem." You want to make sure that many people on the team understand the various elements of the system well enough to be able to meaningfully work together on them. This also means that the developers do develop a description of the work (which other people can understand and use), instead of simply jumping in because they [alone ...] know what to do. Encourage people to broaden the scope of what they can work on, given that the natural tendency is to narrow it. – Mike Robinson Feb 15 '21 at 17:04