A common problem in Scrum implementations occur when the former project manager becomes the ScrumMaster in your Scrum project. I call this the phenomenon „The managing ScrumMaster“. But why is it such a problem?
From push to pull
One of the biggest changes when introducing agile methods like Scrum is the procedure of how the different tasks are assigned. In most non agile projects it is the project manager or even worse other stakeholders who assigns the tasks to the team members. This is the so called „push“ principle. In agile projects this is completely different. Here the team members decide on which task of the sprint backlog to work next. This is called the „pull“ principle. And that’s were the problem with former project managers start. The team is used to ask his project manager what to do next so they will ask their new ScrumMaster and he will eagerly answer and assign a new task to them. This makes it extremely difficult to switch from push to pull. But if the team is not able to switch to pull they won’t benefit from the main advantage of agile methods: the self organization of the team itself.
One possibility to solve this problem is silence. Yes, silence! If a team member asks the ScrumMaster what to do next just hush or tell them to have a look at the sprint backlog by themselves.
Reports instead of planning in the daily scrum
Similar problems also occur in the daily scrum. If the ScrumMaster is the former project manager the team tends to report what they’ve done. In worst case the ScrumMaster has a clip board in his hands and is asking each team member the three questions while noting everything. Of course this is not the way a daily scrum should be. Instead of reporting to the ScrumMaster the team has the mission to clarify what to do today to accomplish the sprint goal at the end of the current sprint.
A possible solution for this dilemma could be that the ScrumMaster doesn’t attend the daily scrum in the beginning. Of course he has to make sure it happens. Another possibility would be to use tokens during the daily scrum. This token works a circuit (or randomly) and the team member who has the token speaks next.
ScrumMaster „only“ accountable for the Scrum process
A former project manager is used to lead his team, define project plans, milestones and the content of each release. But as ScrumMaster the „only“ thing he is accountable for is the Scrum process. Sure, this is a complex challenge but something completely different. It is clear that it is hard for a former project manager to keep his hands off such things. Problems are preprogrammed.
From my point of view a role that betters fits to a former project manager is the role of a Project Owner. Most duties and responsibilities are the same. It is clear that if you want to be the Product Owner you need to know the domain of your product and you’re able to define valuable features. But that’s the content of a different blog post.
Former project managers may be a problem in the role of a ScrumMaster but if you know them you can prepare yourself.
Anybody faced similar problems with former project managers? Just add a comment.
Good blog, and a fairly common scenario I suspect. I for one was part of a team with that exact scenario. In my case, our ScrumMaster did a really good job of putting aside his Project Manager duties for the sake of making our Team work. He had a good feel for the team, so when his PM hat needed to go on, he didn’t hesitate.
I’ve talked to enough people, however to realize that my situation was in the minority, so I will consider myself lucky.