Categories

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.

Scrum – What is Swarming and is it useful ?

How many of you have heard of the concept of Swarming ? Even if you have not heard of this concept, it is possible that you would have done something similar to this as part of the Scrum team. In a typical day of Scrum teams, various teams work on their own tasks, which may or may not be directly linked to the tasks done by each other. It is also seen by many teams that no matter the estimates, what typically happens is that by the end of the Sprint cycle, most of the Scrum team members have completed a percentage of their tasks rather than 100% of their tasks (not good, but it is the reality and the teams can sometimes be happy that the most important part of their tasks still have been completed and some part of the tasks could even be dropped).
However, there is something called Swarming. What this comprises of becomes clear when you think about what a ‘Swarm’ means. A Swarm could be seen as a swarm of bees or other insects operating as a group; and so swarming as part of Scrum lingo means the concept of all the Scrum team members working on a single task. When is this likely to be done ? Well, this is not something that is done on a regular basis. Suppose you have different team members working on their individual tasks, and one of the Scrum teams is delayed in their task. Now, this can happen on a regular basis – technical complications, estimation problems, team problems, and so on. While trying to resolve these issues, if the task is not of a high priority, the Product Owner can take decisions about reducing or removing the task from the Backlog. However, if the task is a critical task, something that is critical to the building of the overall product (for example, it could be the architecture framework of the product, or a piece that forms the backbone to which other pieces connect, or something that needs to be shown to the client), then it is critical that the task be done quickly and the delay in schedule be reduced.
So, the entire team is galvanized into working for this task for a few hours, or one day, or for a bit more than one day. A number of teams also seek to make this kind of task be accompanied by some kind of gesture, say for a pizza working meal for everybody involved in this task. In the best case scenario, such an effort ensures that a great amount of work gets done, either so that the task gets completed or the amount of work that gets done ensures that the task comes back to schedule.
However, there are some problems / concerns with this approach.
– The number one is about the time involved in ensuring that all the other team members are fully upto to speed with the current status of the task, and their involvement will not lead to extra work because their understanding is imperfect
– There may be morale and other team personnel issues involved if the original Scrum team members in charge of this effort are not really comfortable with more people being added to this effort
– When so many people are involved with a single task done over a short period of time, the defects that may be generated may not be so easy to handle, and even the testing team may not be able to spend the increased amount of time required to test this extra output because of more people involved in doing the work

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>