Agile Swarming, Mobbing and Brainstorming — Refining Requirements and Getting Things Done

How these practices helped us when we didn’t have the perfect agile setup

Setting the Scene

In 2016 I led a development team on an agile software project that didn’t have a Product Owner. What I did have was a client that had a good idea of what they needed, some idea of what they wanted, no experience with agile processes or values, but a champion attitude towards being available and involved.

What I also had was a very experienced senior software developer (Mark Whitfeld) who we had contracted from an external development house in the region and his extensive agile development background allowed him to take the lead on tasks normally executed by a Product Owner (obviously sacrificing development responsibilities in the process).

The Smart Part

With no Product Owner, the creation and elicitation of user stories as well as backlog and requirements refinement became a whole team effort with Mark at the helm of these tasks.

It was at this point that Mark suggested that we apply swarming* to user stories from a requirements/refinement perspective where, whenever someone started on a story with unclear requirements OR found themselves in a position where the story they were working on became a bit murky, the whole team got together for a quick (timeboxed 10/15 min) pow-wow to figure out what was going on there.

The whole team engagement not only helped with the intended refinement, but it also did an amazing job of ensuring that all members knew the exact definition of the product at any point along the way and assisted greatly in strengthening team dynamic and communication (I will write about this at another time).

This approach contributed greatly to the team’s performance and significantly added to their output, especially when further combined with pairing, mobbing and “traditional” swarming (see below).

I suggest you give it a try.

*A note on definitions — If you’re involved in agile software development, you’re most likely familiar with the concepts of pairing, swarming and mobbing (this and this article are both good reads), but here’s a quick synopsis for reference:

Pairing — one task, two developers, one keyboard (shared PC)

Mobbing — one task, entire team, one keyboard

Swarming — one task, many developers, many keyboards (own PC’s)

Furthermore, in this context, the difference between swarming and brainstorming (the mulling over of ideas by one or more individuals in an attempt to devise or find a solution to a problem - Merriam-Webster) requirements is that, when you brainstorm, you have no solution yet, i.e. the “what” is unclear and you attempt to figure out what the destination should be. When you swarm, you know what you should be building, but you don’t know how you are going to get there, i.e. swarming is about the route you need to take between all the different side tracks to get to your destination.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.