The Value of Pairing, Swarming, and Mobbing

A colleague asked about mobbing a few months ago on Twitter. Here’s the short answer, including pairing so you can see everything in one place:

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

A WIP limit of one means the team or pair works on just one story or 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 One swarms. They get together as a team and discuss the item (WIP limit of one) 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 or 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 One 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 One’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 Two 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 Two 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 done.

Pairing is one keyboard, one machine, two pairs of eyes. The keyboarder is the driver, the watcher is the navigator. You get a 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.

If you want to read more, I wrote a post about pairing and swarming and how they will help your projects a couple of years ago.