Prem started off well but as soon as the project experienced trouble during the second sprint he resorted back to the traditional role of project manager as task master. Admittedly there is fine line between coaching and directing, but he needed to play a less assertive role in solving the integration problem. Here, instead of telling the team what to do, he could have poised questions that would have helped them to solve the problem themselves. This is a hard thing to do when you are under time pressure and you are confident you have the answer. He exacerbated the problem by taking control of the daily scrum away from the team. The synergy that had developed during the first sprint dissipated as team members no longer felt personally responsible for their tasks. Not only did motivation suffer, but the project likely suffered by not tapping into the collective expertise of the team.
A second major issue is Prem acquiescing to Isaac’s request to change the work on the second sprint and extending the deadline. This violates one of Scrum’s cardinal rules: no changes are introduced once the sprint backlog has been set! Prem failed in his capacity of Scrum Master to ensure that the process is adhered to. This is the primary responsibility of a Scrum Master. Still on the surface Isaac appears to have justification for making changes if his assertions that much of Sprint 2 work would otherwise be a waste of time. This reflects a dilemma when using iterative methodologies like Scrum.
On the one hand the purpose of locking in Sprint work is to provide focus and certainty so that the team can work uninterrupted on the project. On other hand, the Sprint Planning meeting is based on the best information available at that time, and what to do when contradictory information surfaces is problematic. Most Scrum advocates argue that you have to trust the process and that in the end you are better off adhering to the rules. Conversely, a case could be made that in situations such changes would be justified. Ultimately this is a judgment call, but such instances should be rare and clearly warranted.
At first glance Prem’s violation of the Scrum rule that Sprint deadlines can not be changed seems minor compared to his other transgressions. Still this can quickly become a slippery slope if it becomes the norm rather the exception. The purpose of having set Sprint times is to take time out of trade-off equation. The team focuses only what it is capable of accomplishing given its resources within the sprint time frame. This forces the team to tackle tough questions early rather than later. 3. Assume you are Kendra. What would you want to say at the retrospective? How would you say it? Kendra, as well as the other team members, is likely to want to call Prem out for violating the Scrum guidelines. She has tasted the benefits of Scrum and that taste is quickly vanishing after the second scrum. In particular, she is likely to want to talk about Prem’s transformation from Scrum Master to Task Master.
The problem is how to raise this issue in a constructive manner. Prem is likely to act defensive if his shortcomings are pointed out. This is a delicate matter with no easy solution. One strategy would be to talk to Prem about the Scrum inconsistencies before the meeting so as to avoid a public spectacle. This would give him the opportunity to save face by taking the lead in returning the project back to Scrum principles. If this doesn’t occur, Kendra needs to be careful to focus on the consequences of Prem’s behavior and not attack Prem for failing to perform his role as Scrum Master. Here, she could confess that she does not feel the same level of commitment when she is assigned a task instead of volunteering to do a task.