You’re the scrum master on a team that is doing well. Recently you’ve noticed that some team members put in more effort and hours each sprint, than others. You want to bring this up during the next retrospective, but are unsure what is the best way to do it. Is presenting a report showing the average hours worked by each person the right way to go?
[featured-image single_newwindow=”false” alt=”What Does a Scrum Master Do When a Team Member is Not Performing” title=”What Does a Scrum Master Do When a Team Member is Not Performing”]Tim Patterson | Slacking at Work | www.flickr.com[/featured-image]
This question is unfortunately becoming more and more common. Newly minted scrum masters often struggle giving up the control that traditional project management positions gave them. The right question to ask in this situation is: Why is a scrum master watching the clock?
Scrum Masters are in a position of servant leadership. We are tasked with managing the scrum process, not the team members. We are coaches, not task masters. Presenting a report of hours worked is against the agile values and could cause deeper issues for the team.
Defining “effort” as the average number of hours worked is a terrible metric to use. The time it takes to complete a task could be based on many factors. The experience levels of the developers, the difficulty of the task, and dependencies on other activities can all lead to team members needing varying hours to complete their work.
Using an average hours worked report during the sprint retrospective meeting could also work against the team maintaining a sustainable pace. The scrum team members working fewer hours could suddenly feel pressured to work longer hours. People need down time to do high-quality work. Longer hours puts the team at risk by burning out the developers and potentially decreasing the velocity of future sprints.
In this case, the scrum master should first dig in to whether or not the variable hours is actually an issue. Is the team’s velocity trending down? Are more defect being reported by the end users? Is the customer still satisfied with the value being delivered each sprint? These are the types of questions that a scrum master can use to verify that a problem exists.
Another option is to ask the team during next retrospective if they have taken on too much work. It is possible that the root cause of more hours being worked is simply not limiting the amount of work in progress. If that is not the case, perhaps the stories and tasks are not being broken down in to small enough deliverables. These are all great areas for a scrum master to help the team investigate.
Scrum calls for teams to be self-organizing and self-managing. This is a real responsibility that scrum team member take on when deciding to do scrum. In the event that a team mate is not keeping up their end of the deal, the team must be willing to address the issue.
As scrum masters we can help guide the team through these difficult conversations and lead them to positive ways to correcting the problems.
[reminder]Have you seen instances of a scrum master reverting to their old project manager tendencies? What kind of impact did it have on the team?[/reminder]