Using a "Swarm" on that gnarly defect

It always seems to happen. Your nearing the completion of the final sprint. The company is excited for the new product, features, and or services to be made available to the customers. And it happens. The dreaded email arrives. Their is a defect that we absolutely can't ship with. And worse - its "architectural". I'm a bit embarrassed to admit that nearly every significant release I've been involved with has had this scenario. The email goes out, the team panics, management panics, the company panics. It's the end of the world!

This just happened for us on the Serena Agile On Demand project. Well, we did some of the compulsory panicking, but got our wits about us and got back to work. A few of our developers when dark for a few weeks to better understand the root causes. Testers rallied around them and provided them data and performance metrics. But after a couple weeks, we hadn't made progress and the release was at risk. Well, what we were doing clearly wasn't working. We needed to change things up a bit. So we swarmed.

A swarm is a technique teams use to collaborate around solving a specific issue.

In this case it was performance related. A few very talented developers had been focused on it for a few weeks. But they were burning out and carrying far to heavy a load for the team. We needed a break through and had the team to swarm around the issue. A swarm helps in a variety of ways. Firstly, it gets more eyes on the problem and allows for concurrent analysis. The collaborative aspects of the swarm are obvious. Now its just not one or two team members on their own. The team is collaborating, brainstorming a variety of approaches and solutions. And finally, it doesn't leave one or two resources isolated on the problem. For this most recent swarm, we collocated the swarm into one of our conference rooms (pictured).

There are planning impacts to swarming that need to be closely considered. What happens to team velocity when swarming? Clearly, there is an impact and this needs to be closely managed. So the decision to swarm needs to be explicit and it needs to factored into the sprint and release burn-downs. So use the Swarm wisely!