Scrum is about Teams producing results, not people doing work. The best way that Teams can produce quality results is by working together, helping each other out, having conversations, and just plain ‘getting it done.’ This pattern of work is called the Team Swarm.
With that in mind, here are 6 ways to successfully Swarm.
1. Developer Pairing
Pairing is a practice often associated with eXtreme Programming (XP), in which each Story is worked on by two Developers, working side-by-side at one computer, collaborating on the same design, algorithm, code or test. This practice has been utilized in the industry with great success for years. Many Teams have found it useful to rotate Pairs every 1-2 hours, which is referred to as Polygamous Pairing. Both Pairing and Polygamous Pairing are stylized forms of Swarming; however, only in the Polygamous case are there actual Swarmers.
In basic Pairing, where the Pair is fixed for the duration of a Story, the TeamLet (or collection of people working on a Story) is the Pair, one of the Pair is the Coordinator, and there are no Swarmers. In the Polygamous case, the Coordinator is the developer that stays with the Story (if there is one – sometimes nobody stays put for the duration of the Story’s development), the Swarmers are the developers who come by and Pair on the Story, and the TeamLet consists of everybody who worked on that Story (basically, the whole Team).
2. Stay-at-Home Coder
It is generally accepted that coders have a tough time context switching; that is, when they are buried deep in a piece of code and they have to come out to do something else, it then takes them awhile to get back ‘into the code.’ Therefore, one of the patterns of Swarming is the Stay-at-Home Coder pattern.
In this pattern, each coding Story gets a coder as its Coordinator (remember that not all Stories are coding Stories). The non-coders on the Team (analysts, testers and so on) then become Swarmers who share their expertise across all the coding Stories as well as work on the non-coding Stories. In other words, these non-coders will be Coordinators for non-coding Stories and Swarm on the coding Stories, while the coders will ‘stay-at-home’ with their individual coding Story – they will only Swarm after their story is Done.
The Team will probably need a coder to be a Swarmer in order to give technical support to the other coders and help others with the non-coding Stories. Since this coder should not be Coordinating a coding Story at the same time, we say that the Team has kept one coder in reserve to act purely as a Swarmer.
This pattern is very similar to the Polygamous Pairing pattern, except that the Swarming is not limited to a Pair of Developers at a time. Sometimes the Coder works by him or herself, and at other times it is useful for a coder, an analyst, and a tester (or some other combination) to all be working together at the same time – and that’s what this pattern allows.
3. Single Item Flow
Single Item Flow (also called ‘single piece flow’ or ‘one piece flow’) is a lean manufacturing concept that says each individual Item will move through the manufacturing process all at once with no waiting between steps. On software teams, this means Stories don’t wait for people who have skills they need – the people are available when they’re needed.
So, on software teams, Single Item Flow has usually been taken to mean that the whole Team has all the skills it needs (no need for SMEs), and works on a Story until it’s Done, and then the Team moves on to another Story. In our Swarming terms, this means there is a Coordinator for each Story, and everybody else on the Team is dedicated to that Story as well. This seems wasteful to most people, so most Teams don’t want to do it.
But that’s ok, since Single Item Flow doesn’t necessarily require the whole Team. To be more specific, I think Single Item Flow really means a TeamLet Swarms on a Story until it’s Done, and the TeamLet must have all the skills necessary to get that Story Done. In other words, there can be no Swarmers that have skills which are required by more than one TeamLet at a time. This takes some careful coordination between the TeamLets in order to use these specialists without interrupting the flow of any of them, but this is why the Team self-organizes all the time, isn’t it?
When looked at this way, strict Pairing of Developers is a form of Single Item Flow, since nobody but the Pair works on the Story, and that’s all the Pair works on until it is Done; there are no required Swarmers. This can also be true of Polygamous Pairing, as long as none of the Developers are Specialists required by more than one Story at the same time.
Having multiple TeamLets each doing Single Item Flow is a fine idea and is basically what the Team Swarm concept is trying to achieve. It will work reasonably well as long as the Team is not overly constrained by the availability of required Swarmers, including the SMEs.
4. Professional Swarmers
Some people that do the Team’s work shouldn’t be Coordinators of Stories; they should only Swarm (technically, many of them should Mostly Swarm, but let’s look at it simply first, then see the follow-up section). We refer to these people as Professional Swarmers and their primary production responsibility is to augment, support and provide expertise, brainpower and additional muscle to existing TeamLets. Some of these people are:
- Product Owner: The Product Owner has significant responsibilities that are conducted external to the Team, and we are usually safe in assuming that the Product Owner could be pulled away at any time to work with Stakeholders or the Business Owner. Therefore, it is unwise to have the Product Owner be a Coordinator because the Product Owner may be unable to stay dedicated to a Story. However, the Product Owner is a person with skills who acts as a Team Member, so the Product Owner is often used as a Professional Swarmer.
- ScrumMaster: The ScrumMaster’s basic responsibilities are to be a trainer, coach, mentor, impediment remover, facilitator and so on. Therefore, at any moment, the ScrumMaster may be called upon to do something other than work on a Story as part of a TeamLet. Therefore, the ScrumMaster should not be used on a Story in a Coordinator role, but should only be used as a Swarmer. Like the Product Owner, the ScrumMaster is a person with skills and is used as a Team Member, so the ScrumMaster should be a Professional Swarmer.
- External SMEs: SMEs are people from outside the Team who have skills which the Team needs. Because they’re not Team Members, they can only be Swarmers; but there’s more to it than that. Because they’re not dedicated to the Team, we can’t really trust the SMEs to stay focused on the same priorities which the Team has, so we Buddy them up with a Team Member while doing work for the Team. In a Swarming situation, a SME could Buddy up with a Team Member permanently, and the Pair of them works as a unit Swarming from Story to Story, or the SME could Buddy up with somebody on each of the TeamLets. Either way, what the Team gets is the SME’s expertise and Buddies that are smarter. What the Team doesn’t get is the actual extra manpower.
- Tech Leads: Technical Leads, Development Leads and so on, are an interesting issue. These Team Members should be used more as mentors, trainers or coaches than they are used as actual developers – that is their job now. For example, Tech Leads don’t usually write code anymore, they work with others to help them get better at writing code. Therefore, folks like these should work as Professional Swarmers and move from Story to Story doing the mentoring, coaching and training they’re supposed to do.
- Internal SMEs: Even though we officially use the term ‘SME’ to refer to external Subject matter Experts, we probably have experts on our Team (Technical Writers, Database Gurus and so on). These people will be in demand by many different Stories and TeamLets, so they should be used as Professional Swarmers. Unlike external SMEs, however, they do have the Team’s priorities in mind and therefore don’t have to be Buddied up. The Team might decide to Buddy them up anyway so the Team can spread the expertise around, but this knowledge sharing usually happens naturally because of discussions that happens inside the TeamLet.
5. Mostly Swarmers
Many of the Professional Swarmers I mentioned in the last section are actually Mostly Swarmers. Let’s look at the Technical Writer. It is likely that most Stories have a requirement such as ‘Tony the Tech Writer reviews the online documentation’ as part of its Definition of Done, so we could reasonably assume that Tony would be a Swarmer on each of these Stories. In fact, he probably helps write the online documentation for each Story and also gathers whatever else he needs for the other documentation he is responsible for (User Manuals, Marketing Materials and so on).
Tony may also have his own ongoing Stories like ‘Produce the User’s Manual’ and ‘Help Marketing with Advertisements’ which he does more-or-less by himself (from the Team’s perspective), so he’s the Coordinator for them. He probably spends some time in every Sprint on these Stories (so they are officially Epics), but only when he’s not Swarming. In other words, his first responsibility in most Sprints is to Swarm, but he may have ongoing background Stories he’s the Coordinator for. These Stories may move to the foreground once in a while (like during a Release Sprint), when they may actually be Swarmed on by other Team Members.
I call people like Tony ‘Mostly Swarmers’ even though they are also Coordinators. This is because their primary responsibility is to Swarm, and their own Stories are of secondary concern in most Sprints.
6. The Kanban(ish) Variant
Kanban results in Team behavior which is very similar to the Swarming behavior discussed here. The only significant difference is that the Stories that are eligible to be Swarmed on next are not already agreed to. That is, when a Story is Done and the Team is deciding what to do next, the Stories that are eligible to Swarm on next can come from anywhere in the Backlog, not just from the Sprint Backlog. Typically, though, they come from the Back Burner, as the Back Burner is full of Stories that are ready to be agreed to.
The Team Swarm is a pattern that well-formed Teams use, as it focuses on the needs of the Stories, adapting the Team’s organization and behavior based on those needs.
Interested in more successful Swarming for your Team?