2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- February 1, 2017
- Collaborate
Swarming is a practice where the entire team works together temporarily to solve a problem.
Swarming is most useful for certain kinds of problems, problems that impact the entire team. If no one can do anything until the problem is resolved then it may make sense, and improve morale, if everyone on the team has an opportunity to work on resolving it.
I remember I was sailing to Bimini from Miami with some friends and later the following day, we had run aground on a sandbar. The captain had the crew and the rest of us swarm on finding a solution. Some of us jumped into the water to help push the boat free. Others stayed on the boat and used their weight to shift the position of the hull. A few minutes later, we had broken free and we did it because we all worked together.
Swarming works best if everyone has a vested interest in the outcome. Of course, there are some problems that just require one person. For example, if the build breaks it’s typically the last person who ran the build that caused it to break so that person should be responsible for fixing or backing out any problematic changes so the build can run again. The entire team is dependent upon a good continuous integration server and when it goes down it can be of paramount importance to get it back up as quickly as possible. But this is usually a “one person job” since the person who broke the build is best suited to fix it.
Some teams find that they can become hyper productive when working in a swarm and for these teams, I recommend mobbing as a technique that they use on an ongoing basis. Mobbing is a technique first described by Woody Zuill. Woody describes mob programming as “All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer.”
Mobbing is like keeping a full time swarm where everyone on the team works together all the time. It may sound inefficient for the whole team to work in a mob but it turns out that for certain kinds of tasks and on some teams it can be highly efficient. Mobbing and swarming can be a good way to start out a new team working together and then after a few days or weeks of working in the group, individual members can break out and work on their own. This can be a great way to get everyone on the same page with common practices and coding conventions.
Swarming can be a great opportunity for building and solidifying a team. The next time you’re faced with a showstopper problem, consider calling, “All hands on deck!”
Previous Post: « Podcast on The Agile Uprising
Next Post: Developer on Fire Podcast »