The term is derived from the behavior of insects in nature. The classic example of this behavior is a beehive when it reaches a critical mass. The workers will grow a new queen, and then the hive will split and a swarm will form that will leave the hive and seek out a location for a new hive. Perhaps the most astonishing thing is the fact that there is no one individual controlling the actions of the hive. There is no controller, no authority, no coordinating influence. Sounds kind of Agile.
These characteristics of “swarming” in the insect world are very similar to the kind of behavior that we are trying to foster within Agile teams. We want the entire team to focus on one and only one story at a time.
We want to use simple rules. We want to allow the team to self organize.
However, swarming is a relatively new pattern to emerge in the software world, and there has been a lot of misunderstanding and resistance to the notion of swarming. The idea of having the entire team focused exclusively on the same story is very hard for some people to swallow. The key is to create the right environment to support swarming activity.
If you are going to practice the swarming you need to make sure the following conditions hold true for your team:
There is a definition of done that enables the involvement of the entire team
The scope of the story is non-trivial
A set based decision making model is used
Often the argument that I hear is that a given story simply doesn’t require the involvement of everyone on the team. However, the more I thought about it, the more I realized that this probably isn’t really true very often. If we look at the definition of done for a team, we fine that there are activities from virtually every team specialization that are required to get a story into “potentially shippable” form. There needs to be a definition of done that enables the involvement of the entire team. Think about it – what activities need to be done for each story? Can we leave out QA? Documentation? Analysis? Design?
Someone once argued that it doesn’t make any sense to build a car 1 tire at a time. I have to agree, but I must also maintain that the challenge must be equal to the resources of the team. We should scale the stories to the appropriate size. The scope of the story must be non-trivial. Instead of building one wheel at at time, perhaps we should change the story to implementing the braking system? Perhaps the team should be implementing the suspension? The drive train? The story has to be scoped large enough that it allows the participation of more than one team member.
We also have to realize that swarming opens up some opportunities that we might not have using more conventional team organizational patterns. A Set based decision making model can be used. If the entire team is focused on the same problem, then we can also have them explore multiple solutions to the problem. This can lead to enhanced learning by the team, and allows them to explore alternatives more fully before making a commitment to an implementation or technology.
So, if you want to explore your busy inner bee, you need to create the right environmental conditions to support the swarming behavior:
There is a definition of done that enables the involvement of the entire team
The scope of the story is non-trivial
A set based decision making model is used
Given these conditions, the swarming pattern represents an exciting opportunity for us to explore a new way of understanding how we collaborate within our teams.