I've heard swarming mentioned in the context of Agile or Extreme Programming. It seems to be a complement to pairing.
What exactly is it? When should it be applied? How do you do it well?
-
@CodeWorks: My searches on Google produced few relevant results, and none with a clear answer to my question. If there's a canonical answer out there, then by all means, post it here.– Jay BazuziCommented May 9, 2012 at 5:24
-
infoq.com/news/2013/02/swarming-agile-teams-deliver– BlundellCommented Jul 29, 2016 at 8:55
-
There's a voiceover line in the strategy video game "Sword of the Stars" where the ant/mantis/hivemind people say upon you issuing a research command "We are swarming the lab your majesty." I always assumed that was intended to land with a sense of dramatic irony.– Erik ReppenCommented Oct 11, 2017 at 0:20
Add a comment
|
5 Answers
The idea is that everyone on your team works on the same story at the same time. Instead of everyone focusing on different tasks, everyone focuses on one task at a time until it's completed. Then they move on to the next thing, where they all work together on it.
This helps teams that struggle completing stories before the end of sprint. Often teams finish 80% of all the stories, but none are complete. This is less useful than completely finishing 80% of the stories, since unfinished stories have (effectively) no value to an end user. It's easier to get stories completed when everyone on the team is focusing on one story at a time. This is the motivation behind swarming.
There are some difficulties here. For instance, QA can't always test things before they are built (or even designed). In this case, you should establish a design together early on, and then QA can write (initially failing) tests against the design and not the actual implementation.
-
-
2Another way of saying it is "have as few works-in-progress as possible", right? Commented May 7, 2012 at 20:31
-
1@CodeWorks Yes. We have used it where I currently work to some success. It's a pretty fun way to develop, because it's feature oriented. Everyone is working towards the same goal at the same time, so I found that it fosters teamwork really well.– OleksiCommented May 7, 2012 at 20:32
-
1@JayBazuzi Yeah, pretty much. Having full-team support is also important though.– OleksiCommented May 7, 2012 at 20:33
-
9@CodeWorks, Not at all. In fact, it probably increased it. Because everyone was working so closely together, there were less blockers that surfaced. When something came up, at least someone on the team knew how to solve it, and were able to do so right away since it had their full attention. Also, context-switching is generally bad for your productivity. Just ask you CPU. :P– OleksiCommented May 7, 2012 at 20:36
Swarming just refers to the fact that multiple people work together to complete a task or story. In my experience this isn't something you do often.
Typically, each member of my team works on a different task and/or different story. If someone is falling behind, or if there's a desire to finish a task or story early, other people will stop working on other tasks and "swarm" to complete the task, which means they all work together on a single task or story until it is completed.
We recently had a small number of stories that was some fairly boring, uninteresting work. I gave the team a small incentive (pizza) and deadline (end of the day) to finish the work, so they swarmed on the story and knocked out at least a couple days of work in one afternoon. They got the work done and out of the way early, then each team member went back to whatever they were working on. They got a free lunch, I got work done early that could have dragged on due to it's dull nature, and the team got ahead of their sprint. Win-win-win.
"Swarming" is nothing more than a fancy term for "hey, let us help you with that".
answered May 8, 2012 at 1:59
-
This seems quite different from the other answer. You're saying "when there's an unusual, urgent need, get everyone on it". @Oleksi said "when planning a development cycle, better to put everyone on one task at a time than to have each person working on a separate task in parallel." Either definition is plausible, and both are useful practices, but his has 4x the votes, so I'm assuming his answer reflects the most widely-accepted definition. Commented May 9, 2012 at 16:37
-
@Jay Bazuzu: Whether everybody is put on a single task as part of sprint planning, or whether it happens organically as needs arise, the definition is still pretty much the same -- everyone works together on a single task. Commented May 9, 2012 at 21:19
-
I think your answer is very key here. The other answer that is 'accepted' is the "what". But yours seems to address the how. Commented Feb 7, 2014 at 20:52
Swarming is actually a central concept to agility. It is not something that is done "when there are problems". Swarming, in its simplest form, means that teams work collaboratively on items (stories) and work them to completion. The core concept is to "quit starting, and start finishing". In other words, instead of every developer working independently on a story, the team focuses on a more limited set of stories/tasks together and get each item done sooner. Think of it as the difference between a single-threaded system, and multi-threaded. If a User Story has 10 tasks that must be done, and each one is 8 hours, assuming that there were no complications, one developer could work each task sequentially and complete the story in 80 hours, or about two weeks (given 10 day sprint of 8 dev hours per day). What if two developers split the tasks and worked them concurrently? The same 80 hours of work can be completed this way in one week. Add a third, and you can see now it might be done in 3 to 4 days.
Swarming can be done in several ways:
- Pair Programming (two developers sitting side by side to work on the
code, one is the "driver" writing the code, the other is the
navigator, keeping the longer term direction in mind and helping to
code review simultaneously.
- Pair work: A developer and a tester work simultaneously on the same work, one coding and the other testing, writing automation, etc
- Swarming like I mentioned above, which is very common. Usually, team members swarm a Story, but each owns individual tasks in this method.
- Mob programming: the entire team is focused on one story (or even task) at a time.
Teams that give a story to every developer tend to have too much "work in progress" or WIP, and often many stories get started but not done. This is an ANTI-PATTERN, and is NOT best practices.
Teams that swarm tend to have less WIP and complete more stories--and by done, I mean Developed, Tested, Approved, ready to deploy. Thus, this is a practice is that core to agility.
The following article on InfoQ describes one approach to swarming:
- Team uses mob programming for most of it's coding tasks
- A parts of the team or individual team members often split and join the team in short intervals
- Everybody does everything (no roles)
- Team is not using estimates, WIP is always one, no need for standups or similar ceremonies
Read the article for the detailed explanation.
These are pretty good answers, but I would suggest that there is pair programming (2 people) and there is mob programming (whole teams) and there is swarming (some group of people on each of several tasks).
I've seen "teams" which were basically talent pools using this multi-mob kind of swarming to complete tasks. The team member all worked with each other eventually, all 40 of them in a very large team, but they didn't all work with everyone else at once.
It worked pretty good. It's different from pairing and mob programming, but it works quite well in context.
I described it with more details in this article.
