Pairing, Swarming, and Mobbing

A colleague asked mobbing last week on Twitter. Here's the short answer, including pairing so you can see everything in one place:

  • Swarming has a WIP (work in progress) limit of 1, where the team collaborates to get the one item to done.
  • Mobbing has a WIP limit of 1 for an entire team with one keyboard.
  • Pairing is two people and one keyboard, often with a WIP limit of 1.

A WIP limit of one means the team or pair works on just one story/feature at a time. Sometimes, that feature is large as in the team who worked as a swarm on very large stories. (See the post Product Owners and Learning, Part 2 for how one team finishes very large features over a couple of days.)

Here are some examples of what I've seen on projects.

Team 1 swarms. They get together as a team and discuss the item (WIP limit of 1) with the product owner. They talk among themselves for a couple of minutes to decide on their “plan of attack” (their words) and then scatter. The testers develop the automated and take notes on the exploratory tests. The developers work on the code. 

Aside: On another team I know, the UI, platform, and middleware devs get together to discuss for a couple of minutes and then write code together, each on their own computer. (They collaborate but do not pair/mob together.) On another team, those people work together, on one keyboard for the platform/middleware work. The UI person works alone, checking in when she is done. Everyone checks their work into the code base, as they complete the work. Teams develop their own “mobbing” as sub-teams, which works, too.

Team 1 has an agreement to return every 25 minutes to check in with each other. They do this with this kind of a report: “I'm done with this piece. I need help for this next piece. Who's available?” Or “I'm done as much as I can be for now. Anyone need another pair of eyes?” (Note: you might want more or less than 25 minutes. They chose that time because they have smallish stories and want to make sure they maintain a reasonable pace/momentum.

As people finish their work, they help other people in whatever way they can. Early in Team 1's agile days, they had a ton of automated test “technical debt.” (I would call it insufficient test automation, but whatever term you like is fine.) The developers finished their stories and helped the testers bootstrap their test automation.

Team 2 mobs. The entire team sits around a table with one keyboard. The monitor output goes to a projector so everyone can see what the person typing is doing. This team has a guideline that they trade off keyboarding every 15 minutes. (You might like a slightly longer or slightly shorter time. In my experience, shorter times are better, but maybe that's just me.) Sometimes, the tester leads, developing automated tests. Sometimes, the developer leads. This team often uses TDD, so the tests guide their development. 

Team 2 checks in at least as often as they change keyboarders. Sometimes, more often.

Notice that the work in progress (WIP) is small, one story. In both swarming and mobbing, the teams work on one story. That's it. Their focus is doing the work that gets that story to done. that story getting to done.

Pairing is one keyboard, one machine, two pairs of eyes.The keyboarder is the driver, the watcher is the navigator. You get continuous review on the work product as you proceed. I often ask what I consider “stupid” questions when I am the navigator. Sometimes, the questions aren't stupid—they prompt us as a pair to understand the item better. Sometimes, they are. I'm okay with that. I find that when I pair, I learn a ton about the domain.

Here's the value of swarming or mobbing:

  • The team limits their WIP, which helps them focus on getting work to done.
  • The team can learn together in swarming and does learn together in mobbing.
  • The team collaborates, so they reinforce their teamwork. They learn who can do what, and who learns what.
  • The team has multiple eyes on small chunks of work, so they get the benefit of review.

If you work feature-by-feature, I urge you to consider swarming or mobbing. (Yes, you can swarm or mob in any life cycle, as long as you work feature-by-feature.) Either will help you move stories to done faster because of the team focus on that one story.

I wrote a post about pairing and swarming and how they will help your projects a couple of years ago.

6 thoughts on “Pairing, Swarming, and Mobbing”

  1. Hmmm, I’m a business analyst not a developer but reckon that mobbing and swarming could work very well on some of the deliverables that I have to produce. Typically I get caught up in seemingly endless review cycles which could perhaps be dramatically reducing by a bit more co-working at the right time …

    1. Tom, if you do find that you revisit work (review cycles), it’s time for any of these possibilities:
      – workshop the requirements with the necessary people. I like the team who will implement the feature, maybe plus the PO/PM.
      – make sure you’re working feature-by-feature so everyone can focus on that one feature
      – I do like the swarming or mobbing when people start to get scattered.
      Good luck!

  2. Pingback: Your Agile Assembly Line Workers – CoinAffairs

  3. Pingback: Test pagebuilder – Agile Meridian

  4. Pingback: WIP It! – Agile Meridian

  5. Pingback: Managers: Are you responsible "to" or "for" people? | Java code geeks - ondequando

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: