Of Birds and Bees: Are Swarm Teams the Way of the Future?
Have you ever noticed a beehive up close? What happens when a beehive reaches a critical mass? The queen bee leaves the hive and she takes half the workers with her. They swarm and build a new hive. This action is done almost automatically. There is no one controlling or instructing the bees. The queen bee is a kind of servant-leader who just assigns the role to the worker bees in the new colony. The practice of ‘Swarming technology’ in Agile Management systems is inspired by this bee- behavior. Swarming technology is also called Mobbing.
More recently, in his book The Smart Swarm, Peter Miller outlines valuable business lessons from nature:
“From honeybee swarms, we’ve learned that groups can reliably make good decisions in a timely matter as long as they seek diversity of knowledge. By studying termite mounds we’ve seen how even small contributions to a shared project can create something useful. Finally, flocks of starlings have shown us how, without direction from a single leader, members of a group can coordinate their behavior with amazing precision simply by paying attention to their nearest neighbor.”
What is Swarm/Swarming technology?
To learn about swarming technology, we need to know a bit about Agile Project Management.
Agile Management is a dynamic form of agile project management, characterized by:
- Non-sequential workflow with nearly flat hierarchy
- Parallel teams working on discrete parts of the project
- Constant interaction with the client
- Several deliverables over the course of the project
Implementing Agile Management requires teams to change the way they are used to working.
One of the behaviors of Agile teams is “swarming technology” (also called mobbing). In swarming technology, the entire team (or a significant portion of the resources) is allocated to a single task (also called a story), so that the work at hand is completed more effectively. Remember the “All for One; One for All” motto of the Three Musketeers? Well, swarmers have to adopt that motto. Each member of the team should be ready to work in areas that might not be his/her expertise.
Swarming technology is usually applied to work backlogs; or panic situations; everyone on the team “swarms” to finish the backlog so that the entire project can move smoothly. In team swarm agile, there is no project leader or manager directing the team what to do; there are only coordinators and swarmers. All the team members take collective ownership to clear the backlog. While it is possible for an entire project to be planned in swarms, in reality, the swarming team is disbanded once the story is completed, and members return to their original tasks.
In its most basic form:
Swarming technology is the concept of all members of a team focusing on a task at hand, to complete it in a collaborative way.
Let’s understand a few terms used in swarming technology:
Story: A story is a particular business need assigned to a company/organization (typically IT).
Swarmer: A swarmer is a person who moves from one story to another offering his/her skills or technical expertise where they are needed.
Coordinator: A coordinator is a person in charge of the story. A person can be the coordinator for only one story at a time but can be a swarmer for other stories.
TeamLet: A TeamLet is a group of people working on a given story. Each TeamLet has one coordinator with one or more swarmers.
A Day-to-Day Swarm Analogy
Here’s a small analogy which will help you understand the concept of swarming technology: Imagine a team participating in a cooking contest. Two items have to be made and presented before the judges in record time. The items are, let’s say, a vegetable sandwich and French Fries. There are 3 members on our team: Ms. Grace, Mr. Mac, and Mr. Zen. We assign the tasks as follows:
|Steps||Time has taken (in mins)||Person Responsible|
|Cut the veggies||12||Ms. Grace|
|Arrange the cheese and veggies||5||Ms. Grace|
|Pop in the sandwich maker||10||Mr. Mac|
|Peel and cut potatoes||10||Mr. Zen|
|Boil and fry them.||15||Mr. Mac|
|Present the menu||5||Ms. Grace|
It takes 57 minutes to finish the menu in this scenario.
Note that Ms. Grace is tied up during the first 15 minutes with the sandwich activities and Mr. Mac is idle for the first 15 minutes until Mr. Zen cuts the potatoes even though he has the skills to cut the veggies. If Mr. Mac and Mr. Zen can assist Ms. Grace for the first activity, the time is cut by a third.
Now we know that some of these people have multiple skills. Let’s list them:
|Steps||Person Responsible||Persons with skills|
|Cut the veggies||Ms. Grace||Ms. Grace, Mr. Mac, Mr. Zen|
|Arrange the cheese and veggies||Ms. Grace||Ms. Grace, Mr. Zen|
|Pop in the sandwich maker||Mr. Mac||Mr. Mac|
|Peel and cut potatoes||Mr. Zen||Mr. Zen, Ms. Grace|
|Boil and fry them||Mr. Mac||Mr. Mac, Mr. Zen|
|Present the menu||Ms. Grace||Ms. Grace|
Now, if we swarm some of these activities, let’s look at what happens:
|Steps||Time has taken||Person Responsible||Persons who perform the activity|
|Cut the veggies||4||Ms. Grace||Ms. Grace, Mr. Zen, Mr. Mac|
|Arrange the cheese and veggies||5||Ms. Grace||Ms. Grace|
|Pop in the sandwich maker||10||Mr. Mac||Mr. Mac|
|Peel and cut potatoes||10||Mr. Zen||Mr. Zen|
|Boil and fry them||7.5||Mr. Mac||Mr. Mac and Mr. Zen|
|Present the menu||5||Ms. Grace||Ms. Grace|
All of them swarmed for the first activity. The menu is ready in 41.5 minutes and this team wins! This is the basic idea behind the concept of swarming technology. Note that this is not a direct analogy, as IT project teams are more complex, but the basic premise remains.
Strategies for the effective swarming technology
- Team spirit: The concept of swarming technology is entirely dependent on teamwork. So, building team spirit is a critical strategy for effective swarming technology. All team members need to put their heads together to tackle a single problem. So it is essential that the entire team has open and free communication and is receptive to new ideas. Team-building games can be used to foster team spirit in swarm teams.
- Agile Culture: While swarming technology is not necessarily exclusive to Agile development methodology, it is useful for teams that want to adopt swarming technology to prepare teams to the idea of a non-linear, non-hierarchical system of making things happen. Otherwise, people on swarm teams will be confused about hierarchy, approvals and other considerations that are part of Waterfall Management Systems.
- Practice swarming technology as a team building exercise: Team members can frequently swarm as a team-building exercise. This fosters a sense of belonging and also awareness about the strengths and weakness of other members so that when the live situation arises, they are ready to start at a moment’s notice. This is akin to a fire drill, to enable effective functioning in an actual live project.
- Diverse teams: It helps to have members with diverse skill sets within the swarm. People with unique abilities bring a fresh perspective to the solution.
- Frequent assessment: It is important to continuously check the progress of the swarm teams and re-assess tasks in light of new information.
Styles of Swarming technology
Swarming technology is a flexible concept and you can adapt it to various forms to suit different projects. Some of the common forms are:
- Pairing: Developers sometimes work in pairs to complete a story. This is a strategy frequently used in a form of programming called Extreme Programming (XP). Two developers work on the same story (set task), often sitting side-by-side on a single computer (similar to partners in the police force) collaborating on the testing, coding or algorithm. They bounce off each other’s ideas to complete the story. There are two types of pairing:
- Basic pairing happens when the pair is set (the pair can consist of more than two members). One person from the pair is the coordinator and the duration is fixed. This does not involve swarming technology in the sense that only those two people are engaged in the task. These pairs move together from story to story.
- Polygamous pairing is swarming technology where one person stays with the story for the continuation and other swarmers come and go. There is one person who constantly stays with the story for continuation. He/she is called the coordinator. There are other members who form pairs to develop the story. They may or may not stay for the entire duration of the story.
- The Code-ordinator: In any project, one of the issues with swarming agile coders is that coders take some time to “get in the coding zone”. Projects with tight deadlines, ones that typically need to be swarmed, may not have the luxury of time. Hence, the concept of a coder who is kept on reserve. When a suitable story comes up, he becomes the coordinator. This person will stay with his story till the end; while the non-coders like analysts, testers and so on will swarm on the coding story and move on to other stories. The Code-ordinator will move to another story only when the current story is completed. This is very similar to polygamous pairing but it is rather fluid.
- Single item flow: In this form of swarming agile, a Teamlet of swarmers focus on a story until it is fully done. The Teamlet should have all the necessary skills and the workflow should be uninterrupted. There cannot be swarmers who may be required by other Teamlets. This enables the seamless flow of work without waiting in between steps.
- Always Swarmers: Let’s take the example of a team member who is a technical writer. His skills can be used across several teams and he should not be tied down as the coordinator of any team, which will require him to be with the story until it is completed.
- Part-time Swarmers: These people have a primary responsibility towards swarming agile and a secondary responsibility towards their own projects. For example, a technical writer will be documenting the stories and may also have to prepare a User Manual for the project on his own.
Does Swarming agile work Everywhere?
Swarming agile is a great strategy for specific kinds of projects. But it’s not a one-size-fits-all strategy. It’s most useful in the IT architecture phase, where collaboration and problem-solving are critical. However, the basic principles may be used in any stage of any project, cutting down idle time of resources.
Its most basic premise may be used across projects, but specific types of swarming agile may only be used in certain instances.
The Way Forward
Gartner predicts that in the future, swarming technology will be increasingly used in Agile management practices. The future of management services will see the line between the authorities/ policy makers and the implementers becoming increasingly blurred. People from diverse backgrounds will swarm, solve the problem and disband. This will result in an increased output and more temporary teams, as well as impact the way teams are hired and structured. This might, in the long run, also mean that permanent employment, as we now know it, might change forever.
The luxury of long-term work relationships is something that we might lose, but the dividends in terms of efficiency may overweigh the cons of such a working environment.
Team management is a huge task in swarming technology, and requires a diametrically opposite viewpoint from the traditional one, in terms of teamwork, hierarchy, and responsibilities.
On the upside:
- Once swarm teams are set, it opens up a whole new world of possibilities.
- Team members will learn from different viewpoints.
- Employees will do what they like doing best.
- Domain knowledge of each resource will widen.
- Developers will never get bored with the projects.
- Resources are more fluid and easily available.
- Timelines of projects will shorten.
- Employee satisfaction will increase leading to better retention
All these will combine for a better experience for the customer. This will likely make swarming technology a common feature of the projects of the future.
Here are some articles that will help you to get more detail about the swarming technology so just go through the link.