A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Problems with Swarming (in Scrum)

In previous posts, I have talked about the advantages of Swarming during Scrum (link), but this post talks a bit about the contra side. As always, when it comes to Scrum, there are always viewpoints that may be contrary to each other. During discussions, I have heard people who are very happy with the results of Swarming, while there are others who are cynical and skeptical of the touted benefits of Swarming and when people refer to it so much. Even if they have used it once in a while, they are more comfortable for it to be used only in rare cases and certainly not to be discussed on a more regular or often used practice.
So what are some of the problems that people quote if teams are indeed using the process of Swarming. Well, swarming is all about focusing the effort of the entire team on a specific task. Normally the team (comprised of between 5-9 members) would be working on a set of different tasks, not one task. However, when there is a specific important task that is critical, all the members of the team can temporarily delay what they are doing and focus on this one critical task. This helps the team members also learn more about working with other team members, which is good for team organization and team dynamics; at the same time, with fresh blood and new ideas, a critical task which was getting delayed moves much quicker and the team can resolve it and move onto the other remaining tasks.
Sounds good right, so where is the problem ? Well, the problem comes into existence when you consider that many people are so enthusiastic about using Swarming that they almost want this to permanent, that is, once every Sprint cycle, identify some critical task that needs to happen as per schedule, see whether it looks about to happen or not, and if not, get everybody involved on it. Other people don’t look at this so enthusiastically. Their view point is, swarming is an emergency measure, only to be used when some real super critical task is getting delayed, and only useful in such occasions. If you try to do it every cycle, you are ending up trivializing it, and also ensuring that when there is another emergency that comes along, there is no other emergency measure to use. After all, you should plan tasks and estimation in such a way that if such emergencies have happened in the past, learning and review should try and minimize the future appearance of such emergence. Planning for emergencies is no doubt critical, but not to plan for handling emergencies as a part of the schedule. Swarming can be a part of the training process, and used once in a while, but not in a non-emergency situation.
The other problem with Swarming is that places all your people on the same task. This can be a problem when you have a multi-functional team; even though you might hope that there is enough work for everyone, rare is the chance that everybody will have fulltime work available with them. There could be a person having a different skill test who is not needed immediately, or in the push to get everybody focused on the critical task, the work allocation really does not happen to a level where there are specific tasks available for everybody on the team. This is essentially wastage of time available on the Sprint cycle, and even though there can be attempts to optimize, such kind of time gaps can happen.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>