Scrum Process | Scrum Problems | Scrum Detail | Scrum Challenges

May 2016
« Jan    

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

One expert in the Scrum team – Part 2

This is a continuation of the Part 1 of this article (Expert in the Scrum team – Part 1); the topic of this series of articles is interesting and different from some of the other articles that have appeared here. When you have such a skilled expert within the team that he / she tends to over-awe every other member of the team, and this can lead to some problems in terms of stifling the enterprise and initiative of the rest of the team members. The previous post went through some of the problems that this can lead to, as well making such a person as the singular leader of the team to the detriment of the other team members.
In this post, one shall take the problem and try to resolve it in another way. One way is to talk to the person and explain the entire situation, and the problems that this can cause to the rest of the team. This may be surprising for the person or the rest of the team, since they would look at the positive aspects of the support provided by the expert, and trying to look at the problems in terms of reduced initiative by the rest of the team is not something that would be easily apparent to the team. These kind of problems are more easily discerned by somebody external to the team who can look at how the team operates, its dynamics, and look at some of the problems present in the team.
Speaking to the expert on this topic can be a difficult tactic. Many people cannot understand something like this so easily, since such a discussion would entail their attaching some amount of negative results to their work; and it would take a sensitive discussion with the expert to make them understand such a problem. However, using the amount of tact for this discussion depends on situation to situation, but the net result needs to be that the discussion of this problem needs to happen with the expert, and explanation given about how this kind of hand-holding for the rest of the team stifles their initiative, and they would not even make the errors that would happen naturally; this in turn reduces the amount of learning for the rest of the team. If all goes well, the expert would have understand the problems and the needs this places on his/her operations.
How this would work is something that again needs to vary from team dynamics to team dynamics; but the net operation is that the expert would push back against team members coming to verify something, and would push them more and more to explore problems by themselves and do some kind of initial design before coming to the expert for help. Such an approach would help to ensure that the team would also get the message and start to act more and more like an empowered Scrum team rather than going to the expert for guidance. They might make some errors during this course of action, but lessons are learned through errors (just as those are not massive errors).