Scrum Process | Scrum Problems | Scrum Detail | Scrum Challenges


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.

Getting evaluation from new team about usefulness of Scrum

When a team, that has been working using the traditional Waterfall software development model switches over to the Scrum development methodology, it is a big change. It needs training, some hand holding and some initial periods when the team may not be so effective till it starts getting into its stride and shows an increase in productivity. The changes, especially with relation to the responsibilities of individual team members and also with regard to the role of managers can take learning and getting used to.
We have seen many Scrum teams after transitioning, and one key recommendation made on that basis is about a team taking the time to evaluate where they are after a couple of Sprint cycles. This is separate from the Sprint end review meetings; the objective of this evaluation is to understand how the team is working as a Scrum team. Ideally, this should be done along with a Scrum coach in the form of an open discussion with the team members and the managers can talk about their roles, their thoughts about how the process is working and recommendations that they have about the process based on their current experience. At the end of all, the Scrum coach could take them through their various thoughts, their perceptions, try and see whether other members of the team could either agree or provide differing points (and it is important that this be done by the team members rather than by the Scrum coach, since the team member can be more persuasive if they are correct; the Scrum coach would step in if the entire discussion is going in a wrong discussion or the team members are confused).
How often do you need to do something like this ? We would recommend that this kind of discussion be done once only, since it is essentially for the team to figure out how they are working, to evaluate the problems in understanding of any team member and figure out whether they are working fine or not. If the team comes to an agreement that there are issues that need the help of an expert to understand / resolve, then the Scrum coach can be brought in to provide expertise, but with the team running the discussion (if there is a need for a Scrum coach at multiple points, then the team has not really got into the mode of understanding how Scrum works).
What happens when a team does not try to do an evaluation for their understanding about Scrum once the team has started working on Scrum ? Well, nothing earth-shaking, no falling down of the roof. However, if some team member has a flawed understanding of how Scrum works even after working on Scrum and this understanding has not been corrected, there can be some problems later (this all sounds a bit vague, but when team members have different understandings about responsibilities and process and these are not corrected, the result typically is not good). At the same time however, the Sprint end review might help in clearing perceptions and understanding about issues and processes.
Given that the time involved and the effort involved about having such a mid-term meeting to evaluate understanding of Scrum is not all that difficult, teams would find it leading to an enhanced productivity if they actually had this kind of meeting and people were able to ensure they had all their doubts or wrong understanding cleared.

Some advantages from Swarming (scrum) …

The previous post in this topic was about Swarming in the Scrum team and what it is about. This post looks at some of the advantages that Swarming brings to a Scrum team (alert: Unfortunately, the very nature of trying to describe advantages makes the use of some jargon type phrases as required, so please grin and bear them). What are some of the advantages of doing Swarming in a Scrum team ?
For a number of teams which do Swarming, the basic aim is to ensure that the most important and required tasks in terms of customer need and usefulness get completed during the Sprint cycle rather than getting partially done by the team member or team members who were working on it. This happens even during the Sprint cycle when it becomes clear that there are some issues in getting the task (planned for the Sprint cycle) completed during the complete cycle; that is when most of the team or the entire team gets together to work on this specific task / User Story in order to get it complete. If one were to summarize, the idea is to ensure that the more critical tasks are completed on schedule even if people are pulled from other tasks.
It gives people in the team some initiative. For example, there could be the case where team members wanted to work on a particular task or feature, but were not able to do so. During the cycle, there would be cases where it would be required to pull in more team members and people could be invited to volunteer (and obviously, this entire strategy is with the concurrence of team managers); if they were to do so and were not working on some mission critical tasks themselves, they would be allowed to drop their current work and move for some time on the task which is sought to be completed through Swarming. You might find that people who come in through this process might be more passionate, and might even turn out to be more innovative.
In many cases, it has been found that when the same (critical) task is provided to a couple or more team members working together rather than a single person working by themselves, the progress on this task actually increases more than expected. The concept of getting people to work together along with the exchange of views and ideas can have a tremendous positive impact on the schedule and progress (but this needs to be limited to the critical tasks). They learn teamwork, which is one problem when you have each team member going off and working on their own individual tasks (unless you have got a very mature team, in which case you are plain lucky).
Similar to the above point, there is another advantage of having multiple team members working on the same task rather than it being assigned to only one team members. Moving the task to multiple team members does ensure that team members get exposure of a particular function that they may not have been exposed to so much in the past, which is beneficial for the understanding of the function it imparts and this actually helps the team in the future.

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