Learn Software Development » Pitfalls

In the Daily Scrum meeting, why is it so hard to get people to discuss with each rather than the Scrum Master (project manager in disguise)

ashish — Tue, 30 Mar 2010 17:48:40 +0000

The Daily Scrum is a very simple, and yet a very integral part of the Scrum process. The idea is to get the team to work with each other, and discuss the items that they have done, are going to be doing next, and any obstacles (impediments) in their path. These are 3 questions:
1. What tasks have you done since yesterday’s meeting?
2. What tasks are you going to get done today?
3. What impediments are blocking you?
However, there are many problems in this simple concept. Ideally, what would need to happen is that the team acts like an empowered group of people in charge of executing all the tasks for the Sprint cycle. Every day, they would get together for a short meeting, and discuss these 3 questions (without getting into 2 much detail). This is supposed to be like a discussion between team members, with each team member taking their turn to explain their activities to the other team members. This makes them feel empowered, and also feel that this is different from giving the status to a project manager.
However, I have seen most cases where this is not what happens. In the project, it is typically a manager who plays the role of a Scrum Master (and to further qualify, it would be the Project Manager or Program Manager) who plays the role of the ScrumMaster. For a person in this role, it is very hard to explicitly move away from turning this into a daily status meeting (since for a Project or Program Manager, this is a very handy meeting to get detailed status on a daily basis as to what is happening in the project). This entire feeling rubs off onto the team members, and they also feel that they are in fact reporting daily status to the project manager (in the shape of a Scrum Master). So what happens ?
Information that the team members share is done while addressing the Scrum Master rather than addressing the group, and it is the Scrum Master who then asks the questions. This inhibits the other team members from asking questions (including questions that would help them), and pretty soon everybody is talking to the Scrum Master only. The next effect is that the team members stop realizing any value to them of the Daily Scrum, and look for reasons to avoid it. I have seen this happen in 2 teams where the team members finally pushed back and got the Daily Scrum changed to happen only 3 times a week. I can be pretty sure that if this would continue, the next couple of Sprints may see the team members calling for the Scrum Master to get the current status directly from the team members rather than have a Daily Scrum meeting where they are expected to sit and hear other people talk about issues that seemingly don’t affect them.
How can this be addressed ? Unfortunately, this is something that the Scrum Master has to guide, in terms of ensuring that people do not start to address their Daily Scrum information to them, and instead address the team. In addition, the Scrum Master needs to realize that the primary aim of this role is to facilitate the discussion, and to ensure that impediments faced by the team are removed quickly.

A contrarian approach, some problems with Scrum as seen by my experience

ashish — Sun, 28 Mar 2010 12:06:14 +0000

Scrum somewhat problematic for us

This post can be a bit challenging; it was most challenging to me when I started writing it, since Scrum has been sold as a solution for most software development projects. Along with this, previous software development methodologies such as Waterfall, Spiral, etc are slowly getting marked as methodologies that are out-dated, do not match well with expectations of changing requirements, and treat human beings as cold resources. Together, both of these movements start to move more and more software development projects towards Scrum and Agile concepts. I have seen many projects in my own company start to move towards using Scrum, pushed by the fact that other groups are starting to move towards Scrum, and there is a lot of pressure. Some queries that I have had about the success of Scrum have been pushed down with the push that these are imperfect implementations of Scrum, and that one should follow the tenets of Scrum more closely. However, here are some of the observations that I have made, and wanted to publish them to wonder about whether things are going fine, or are there some problems in the way Scrum is working for us ?

Specific examples of where Scrum is causing problems

- Team not comfortable: We have a concept whereby people sometimes move between teams depending on the need, and if a team is in a crunch situation. What I have typically seen is that team members who moved into a project using Scrum and then moved out where not truly comfortable with using Scrum. They felt that Scrum somewhat compromises their independence, and does not take into account their fluctuations in terms of daily delivery. When told that Scrum does not enforce a daily delivery of features or expect them to have to justify their daily work, they still seemed uncomfortable about being put in front of the entire team.
- Moving away from daily Scrum: There was strong resistance to using Daily Scrum. We put the teams through training, showed them success stories, but the comfort level with getting them to attend a Daily meeting was just not there. They would sometimes not show up citing some excuses, sometimes would be outright defiant, and would certainly mention this in the retrospectives.
- Senior team members somewhat uncomfortable with flatness: Senior team members were used to the idea that they had a certain amount of experience that caused their word to be taken easily and over their less experienced team members. Ideas such as everybody being able to estimate any features, and people asked to explain their estimates when these estimates were different from others was something that made people uncomfortable.
- Inexperience not fully exposed: When it came to tasks such as estimation, and including the Daily Scrum where people were trying to define the time remaining for their tasks, it would become clear that people who were not experienced caused tasks to be estimated inaccurately. This in turn threw off the velocity, caused more slip on burndown charts, and yet was not so easy to handle in terms of being able to mentor these people. Feedback from all other sources was geared towards disregarding their estimates, but this went against all our Scrum training.
- ScrumMaster works more like a project manager: The ScrumMaster in most projects that I have seen worked more like a project manager rather than a person who got the team to work like an empowered team. There was absolutely nothing like an empowered team discussing within each other, instead we got the SrumMaster who tried to use the Daily ScrumMaster as a way of generating the daily status (and in some cases, when senior management was present, to show that the ScrumMaster was fully aware of the current situation).

Problems that are caused during Scrum when a team member is not full time on the project

ashish — Tue, 23 Mar 2010 13:20:57 +0000

In the ideal case, a person will be working on the Scrum project full time, with that also being the assumption made when the several items of Scrum such as Daily Scrum Meeting, Velocity, Burndown Charts, etc are all calculated. However, there are cases when a team is fairly busy in multiple items and people are assigned to multiple tasks. As an example, consider the case of a development process where there is a daily build available to the team; on some days, the build fails and a person in the team is assigned the task of ensuring that the reasons behind the failure of the build are investigated, and corrective actions taken. Such types of tasks (or consider another task where a team member is responsible for the safety and security of the code repository, and that can also take some regular time) take up time for team members away from their Scrum duties, although they are not factored as part of the effort that a person can put in. Consider the case when something out of the ordinary happens, such as too many build failures, the ability of the responsible person to be able to put in 100% effort for the Scrum tasks is impaired, and there will be some shortfall. This shortfall in effort impacts the Scrum tasks progress as well, but analysis does not take the effort spent on other tasks in account.
What are some of the ways in which such other tasks can be handled ?
- If such tasks will happen on a regular interval, enough to cause some impact to the Scrum effort, then it is better to call out such tasks and dedicate one person to handle these (rather than spreading the tasks through the team). Further, since such tasks tend to be more mundane and boring, these can be switched between team members on a regular basis (say, every Sprint cycle can have a different person)
- Set aside one day in the week for these other tasks, or the maintenance efforts. This can be a bit of problem sometimes in tracking since the need for such tasks does not follow the pattern of once in a week, but it can still be useful to ensure that the effort is being tracked
- Set aside some hours every day (could be as short as 1 hour per day) for such tasks, but this gets complicated in terms of tracking and does not take care when the task suddenly develops into an emergency (as a example, when the code repository crashes or reaches an unpredictable state)
- Hire some additional people (who do not contribute to the team effort, but instead have skills more suitable for the other tasks) and use them; this entails additional costs, but prevents any impact to your team effort
- Add such effort (after calculating the effort over a period of Sprints and averaging it out) to the product backlog so that the Product Manager also realizes that such tasks are there and done by the team, and need to be accounted for in terms of effort

What are some of the impediments that can hold up a Daily Scrum ? How are impediments handled ?

ashish — Fri, 05 Mar 2010 15:11:25 +0000

Part of the routine of a Daily Scrum is where team members come up with the issues that they face which could be stopping them from doing their work. These are called impediments, and are typically problems that are preventing them from completing their work. Once the team members articulate their impediments, it is the role of the ScrumMaster to resolve these issues. But resolving of these impediments is not done during the Daily Scrum meeting, since the meeting is supposed to be a quick and short meeting and this would not be possible if people start solving these impediments right then and there. Further, it would be a big turn-off to other team members if they have to sit in a meeting where some issue is being discussed that is not relevant to them.
An impediment is just that, anything that prevents a person from getting their tasks done. It could be complicated matters such as technical dependencies, or it could be small matters such as an unpleasant odor near the office of the person, or a non-working machine. Once these are communicated during the meeting, it is then the responsibility of the ScrumMaster to resolve these issues offline, depending on the nature of the impediment. Some matters would require the ScrumMaster to call a meeting to resolve these issues, while infrastructural issues need to be handled by the ScrumMaster by contacting the required organizational persons. These can also be policies related to the organization (typically found in teams which have recently moved over to Scrum or where the organization uses other methods of development for a significant number of its projects). In such cases, the ScrumMaster will have to also raise these organizational issues. If the team members start to get a feeling that their impediments are not being handled in time or handled effectively, it can quickly have a very quick effect on the efficiency of the whole Scrum process. Part of the process of impediment handling is to ensure that people can see the status of their impediments, when they will be resolved, and that there is sustained action towards the same. If this require some sort of tool, then that should also be used.
Some of the more difficult impediments relate to personnel issues. You could have a team member who is dragging his / her feet, either because of lack of capability, or because they are not convinced about Scrum; in such cases, resolutions can be to try and figure out what is wrong, and if that does not work with the employee, then it makes sense to talk to get a different person.
Some of the impediments are related to user stories or the specifications. In such cases, the ScrumMaster has to make sure that he gets the Product Owner (and maybe the experience designer) to answer all questions and provide the required level of detail.

What are some of the problems you could face while planning using Planning Poker ?

ashish — Thu, 25 Feb 2010 18:46:39 +0000

Planning Poker is a process used for estimation during the Sprint planning meeting, many times with actual cards rather than software. The various team members do their estimation of the tasks using Fibonacci numbering sequence, and after a couple of rounds of discussion, a finalization of the estimates are done, and these are converted into Sprint Backlog. However, for teams that are not very comfortable with Planning Poker, there can be several problems as dealing with Planning Poker. Some of these are:
- For somebody who is not comfortable dealing with Planning Poker, the concept of providing estimates in this manner can be confusing to people. Guidance, simulation and some hand-holding during early stages is essential
- There can be ego clashes if the estimates provided by team members vary widely, with the senior team members not being very comfortable if the estimates provided by the more junior ones are accepted. This needs careful handling
- Once numbers are presented in the meeting, then non-team members (including the product owner and senior stakeholders) will accept these numbers, and any further refinements start getting compared against these numbers
- Once somebody sees a number by somebody else, they start getting doubts over their numbers and if given a chance, many of the team members are willing to modify their numbers (just by doing some modifications in their head over the estimation). This can sometimes lead to a quick firming of the estimates towards a more accurate number, but can also lead to a herd mentality behavior
- Planning Poker is hard to do when the team is distributed, and needs more careful planning in terms of logistical coordination
- In Planning Poker, the assumption is that the team member has the required level of knowledge, but this can be inaccurate, what can happen in many cases is that the team has as much knowledge as is available, but there are many blank areas that are not yet filled, whether these be requirements from the product owner, or dependencies that are not known
- In some cases, the Product Owner is not satisfied by the varying estimates, and may want to put pressure to select the lower estimate so as to get more features in the current Sprint. The ScrumMaster needs to be pretty vigilant to avoid these scenarios