Milestone Swarming
In my last article, I discussed the power of milestones and I promised I’d talk about one of my favorite techniques for rapidly delivering on milestones. First, as a reminder, by milestone I mean delivering on some significant achievement for your business. This might mean achieving a meaningful improvement to a key KPI, or meeting the needs of a new type of customer, or getting the results of an important A/B test. Remember that the point of a milestone is the business result, and not the date.
Another dimension to milestones is that sometimes they are specific to a team, and sometimes, especially with many of the most meaningful milestones, they involve the coordinated work of multiple product teams (this is often referred to as an “initiative”).
In general, for modern Agile dedicated product teams, the developers and test automation engineers determine themselves the best way to deliver the items on the product backlog. In some teams, each developer takes on one or more backlog items and works largely independently. In some teams, the developers utilize a technique called “pair programming” where two developers work on a single item at a time collaboratively. Sometimes a developer will pair with a test automation engineer and they’ll work in parallel to achieve “done done.” And of course there are any number of variations.
What I wanted to highlight today was a technique that, while not new, has been surging in recent months and I think there are some good reasons for this rise in popularity, and I want to do my part to encourage teams to give this a try. The technique goes by different names. Some call it “swarming” and others call it “mob programming” or “mobbing” or “team programming.” I personally like the term “milestone swarming” so I’ll use that here.
The idea is fairly straightforward and based on the theory that if pair programming is good, maybe swarming is even better. When swarming, you use most or even all of your dedicated product team to attack a task or backlog item. The team focuses on accomplishing this milestone and keeps going until they succeed. It may be that the team is all literally together as one person types and everyone reviews, or they may have a few coordinated threads proceeding in parallel.
In a Dual-Track Agile environment, swarming can be done on either the discovery track or the delivery track. Mostly it is a delivery track activity, and as such, the participants are typically developers and test automation engineers. The product manager and designers do need to be accessible for questions that arise during the swarm, but the bulk of their work should have been done during the discovery work in advance of putting the items on the product backlog.
The benefits to this are many. One is simply the speed that comes from the single-minded focus on the success of the milestone. Another is the quality that results from so many pairs of eyes reviewing the work as it progresses. Another is the cross-training that occurs as people learn from each other’s engineering skills, domain and code base knowledge. And my favorite benefit is the morale that results from a team rapidly accomplishing something meaningful.
It may seem excessive to throw an entire team at a task, and I’m not suggesting you do this with every little task, but I am suggesting that if something is a true, meaningful to the business milestone, then it’s probably a strong candidate for swarming.
So far I’ve talked about a dedicated product team using swarming to accomplish one of their key milestones. However, even more powerful is when we apply the concept of swarming to an initiative. In this case, we’re actually assembling a temporary, virtual team comprised of members from multiple product teams to attack a milestone that spans several teams (and usually different skill sets and areas of expertise).
One of the reasons that this concept is so powerful for initiatives gets to the nature of initiatives. Most product teams have very mixed feelings on initiatives. This is because initiatives are often some of the very best things we can do to improve our products, yet they are often a royal pain to deliver on because there are so many dependencies and such a high degree of coordination and communication necessary.
When you decide to swarm on an initiative milestone, you’re saying as an organization “this milestone is truly important, and we are going to assemble a virtual team from the relevant product teams and have them synchronize and focus on this milestone until success.” That’s a pretty significant investment. In cases where the teams are geographically distributed, they may swarm from different locations, or sometimes it’s worth literally shipping the people involved to get them in the same location for the duration of the swarm.
Since communication and coordination are some of the biggest challenges of succeeding with Agile at scale (more than 5-10 dedicated product teams), the use of swarming for initiatives serves several goals over and above the benefits of swarming for a given team. One is the relationships that are built across teams. Another is the cross-training especially in terms of domain and code base. But the biggest benefit to the company is that rather than avoiding those efforts that cross team boundaries because they are such a pain, an initiative swarm makes these hugely valuable milestones much more viable.
Finally, some teams use swarming on occasion and say how much they love it, and then promptly go back to business as usual. While swarming is not suitable for everything, I’m encouraging more teams to make swarming a part of business as usual, especially for initiative milestones.
If you haven’t yet given swarming a try, I’m hoping you consider it for your next key milestone and see if you can’t deliver on that milestone faster.
