Do you fondly remember the early days with your team when you had a pile of work to do, and everyone just dug into it with a vengeance? Is it now a struggle every week to keep everyone busy and productive? Is it hard to divide up the work for the week? Is your team constantly discovering thorny problems at integration time that could have been prevented with a short conversation between two team members weeks ago?
Your team may have become siloed; each team member works separately in their own speciality, or silo. While a silo is a place to store grain, the metaphor exists in management too because grain silos are tall, and you can only store wheat in the wheat silo, corn in the corn silo. It’s a very natural mistake to end up with a siloed team, especially in companies that have organized people by function.
There’s hope. Silos are a fixable problem and it’s worth fixing because human beings actually prefer to work together. They’re happier, more productive, and it’s easier on you, the manager, when people work together, or swarm.
It’s a mistake I’ve made myself, and then fixed. What had happened to me was perfectly natural.
Optimizing for a particular development cycle by assigning the work based on previous experience and expertise made me more efficient for that development cycle. But it made me less efficient overall, because it started a slow slide of the team into silos of expertise. It was killing the ability of the team to get things done overall.
The fix was swarming.
Swarm your team to double productivity
Swarming is the exact opposite of siloing; swarming is the process of working by feature and distributing work across your whole team. If your team isn’t operating by swarming, your team is only half as productive as it could be. It only took me two development cycles of having my team swarm before I swore I would never go back.
My total team productivity doubled, code quality went up, and everyone just had more fun. Why would I want to go back?
I have to admit, the first time someone suggested swarming to me, I thought they were nuts. But what I found was that human beings want to work together on common tasks, and people are adaptable. Sure, I couldn’t assign a designer a coding task, or an engineer a design task. But my team was smarter than I gave them credit for. Swarming is a natural human activity. They’ll do it naturally and easily, if you get out of their way.
I think we’ve all had the experience of moving furniture with a bunch of friends. What often happens is that the strongest people take the heaviest furniture, the weakest move the cushions, and the weakest of all run ahead and open the doors. You didn’t have to “manage” the moving to make this happen; instead, people knew what needed to be moved, and volunteered to do the task they were most capable of doing.
The same thing happens when swarming with a technology team. You assign the big task, you let the team break it out into smaller tasks, people volunteer as best they can, and before you know it, the couch is moved and its time for celebratory pizza. Or in this case, the development cycle is done, and it’s time for the next cycle.
How swarming works in technology
Let’s say you have two engineers, Bob and Fred. Bob might be the expert on some tasks involving technology Y. Fred is the expert on tasks involving Z. As a manager, out of a false sense of efficiency, you might be tempted to always assign Y tasks to Bob, Z tasks to Fred. That will work as long as every development cycle produces an equal amount of Y type work and Z type work.
But if a feature needs a bunch of Y-type work, Bob is the bottleneck. Everyone has to wait for Bob. Bob is feeling pressured, so he’s grumpy. When Fred and Bob’s work interrelate, Fred will just guess rather than interrupt Bob (who is busy and cranky).
Pretty soon, everyone is in their little silos of expertise. Bob does Y, Fred does Z. When Bob and Fred go to integrate their work, there are always a bunch of places where Fred guessed wrong, which leads to more work for everyone. Bob is bored from doing the same work every week, and so is Fred. Uh oh, the team is siloed.
The road is long. You’re leaving a bunch of team performance on the table in a siloed environment. So let’s start swarming with the team instead. How can we do that? How can that possibly work?
90% of engineering is understanding the problem; only about 10% is expertise. Bob isn’t on the moon, he sits right next to Fred. If you have 2 Y tasks in a development cycle, it’s a perfect opportunity to swarm.
To swarm, you assign one Y task to Bob, and one to Fred. You tell Bob “Help Fred; work together for an hour or two as needed if necessary”.
In your project planning, you will schedule for Fred to be slightly less efficient at getting the task done, because he’ll have to get help from Bob. Similarly, Bob will be slightly less efficient at getting his task done because he’ll be helping friend. So we’ve lost a little efficiency for this one development cycle.
But not as much as you might think! Because what actually happens in practice is many wonderful benefits.
- Because Bob and Fred are working together, they’re both going to enjoy their work more; even two introverts would rather work together than apart.
- You’re establishing the rule that team members should help each other. When one of them runs late on a task, it will be very natural for the other to pitch in and help.
- Bob’s quality will improve, because Fred is now looking at Bob’s code in detail.
- In the process of explaining the code to Fred, Bob will catch and fix problems in the code.
- Fred is learning something new, and engineers like to learn new things, so Fred will be in a better mood.
- Because Fred now knows a little bit about Y, Bob can now use Fred as a sounding board. So Bob’s designs will improve with input from Fred. Fred will also be able to make better assumptions about how Z should work with Y.
- Team productivity will go up. While Fred and Bob’s productivity were slightly impacted on an individual level in that it took them slightly longer to do their tasks this cycle, from the team viewpoint, you were able to get two Y tasks done in one development cycle. So the team productivity on Y tasks almost doubled; critical paths are shorter.
Those are the benefits I got after one development cycle. As I continued to go further with swarming, I reaped additional benefits:
- My life as a manager got easier because I no longer had to worry about the silos when laying out a development cycle plan, because all of the silos had been dynamited.
- Team members got into the habit of volunteering for whatever needed to be done. Attitudes between team members improved, because it established a culture of “we’re all in this together to get it done.” So engineers would test, and sometimes testers would engineer. On several occasions, a team member would volunteer for something I wouldn’t have considered, and it always worked out well. I remember a tester doing some analysis I would normally have assigned to an engineer; she did a better and more thorough job than the engineer would have done.
- Because team productivity was higher, integration happened more continuously, and so everyone immediately fixed problems while things were still fresh in their mind.
- With the destruction of the silos, my team continuously became more powerful and capable, and able to take on bigger challenges. Individuals became more promotable and more valuable to the company, which reflected well on me.
- Because team productivity was up, integration of different components was happening more often and continuously, so problems that showed up when integrating new components happened sooner and were fixed more quickly. Integration problems were fixed by any team member in the appropriate place in the code, so finger-pointing and swirl just went away; instead, engineers just discussed the best place to fix the problem.
Swarming, step by step
Blow up your silos in your next development cycle, by swarming. You have nothing to lose but inefficiency and stress. Here’s a step by step recipe for doing so:
- Talk to your team about swarming, and get buy in.
- Lay out the tasks for the development cycle.
- Make a post-it note per task, with some sense of rough t-shirt size estimate of work (S, M, L, XL).
- Make a row per team member, with their name.
- Ask the team who should do what. They’ll naturally assign tasks based on skill. Put the post its in the appropriate lane.
- Ok, now you have an uneven amount of post its across the team. This always happens, but now you can to fix it. Here are the ways to fix it:
- You can move a post-it to a volunteer
- You can break a post-it into smaller post-its, so that another team member can do part of a task. The brain surgeon may need to do the brain surgery, but the scrub nurse can sew the head closed so the surgeon can handle the next patient.
- You’ll end up with a plan for the development cycle that’s balanced. Now you can watch and enjoy as your team works better together.
Really, its that simple. You’ll be amazed, until you realize that swarming is something that people do all the time. Long before I ever heard the term swarming I used to call this barn raising because the idea of everyone in a community gathering together to build a barn is the same thing as swarming.
Pierce Wetter has kicked around software development for a couple of decades, and recently decided to start laying out all of his management techniques into recipes for other mangers to use.
His hope is to upgrade the skill set of every single software engineering manager in Silicon Valley; sink or swim is not a training strategy.
You can reach out to him for questions or help via LinkedIn; he’ll be glad to help you implement swarming at your company.