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, and I discuss it in this post.
Ever since I started developing software I have noticed that Teams that work well together are quite noisy; there are lots of conversations going on. Team Members work together, help each other out, and have an almost continuous conversation. Some people move from Story to Story, helping out whoever needs help; some people stay put and concentrate on a single Story. Years ago, when I worked at Net Objectives, I identified this pattern of behavior and called it the Team Swarm; the name caught on and has been used by many people ever since.
In this post I’d like to talk about the Team Swarm and related topics.
Team Swarm Definition
First of all, let’s define what I mean by Team Swarm. It does not mean that the whole Team Swarms on one Story until it’s Done (even though this an option); what it means is that the Team Swarms on each Story until it is Done, but it may be Swarming on several Stories at the same time.
At any given time the Team consists of a few TeamLets, each of which is working on a single Story. The Team is constantly self-organizing these TeamLets, in order to best work on the Stories the Team has agreed to. One of the ScrumMaster’s primary responsibilities is to make sure that the Team does this (see chapter 2.3). Let me make some definitions first, and then give some examples. Then we’ll move on to other issues involving the Team Swarm. First, the basic definitions:
TeamLet: The TeamLet is the collection of people that are working on a given Story. Every Story being worked on has a TeamLet working on it, even if the TeamLet consists of only one person. The TeamLet is made up of no more than one Coordinator and (possibly many) Swarmers.
Coordinator: The Coordinator is the Team Member who is ‘in charge’ of the Story being worked on. Sometimes there is not a single person ‘in charge’ of a Story; the whole Team (as a collective) is ‘in charge.’ In this case there would be no Coordinator – only Swarmers. A person can be a Coordinator for only one Story at a time, but could be a Swarmer on other Stories. (Note: The Coordinator is also called the Story’s Point Person or StoryBoss.)
Swarmer: A Swarmer is a person who is moving from Story to Story, working with those Story’s Coordinators and other Swarmers, in order to offer his or her expertise and efforts wherever they are needed.
The Team Swarm is a pattern that most successful Teams use, even many non-agile ones. The main reason that it’s good is that it focuses on the needs of the Stories, and adapts the Team’s organization and behavior based on those needs. The Team Swarm encapsulates the Lean Concept of Single Item Flow and uses constant Team self-organization and self-management to keep the flow optimized. The Daily Scrum is largely concerned with the Team’s self-organization in order to maintain an effective Team Swarm, and it is the ScrumMaster’s responsibility to facilitate, orchestrate, and organize the Swarm.
You can read more about Team Swarm’s in chapter 2.6 of Exploring Scrum: The Fundamentals.