process-handbook
process-handbook copied to clipboard
A scrum master is *not a 'Project Manager'*
There is a misconception in a lot of teams, particularly teams where the scrum master is not a developer on the team (but also in general) that the scrum master is akin to a 'project manager'. Aside from the fact that after 5 years of working at a global consultancy the phrase 'project manager' makes me want to spit, I found that this creates some serious issues with team dynamics.
How does this manifest? This is easy to spot from the outside looking in: a 'scrum master' starts to dictate who will be working on what and when and stand ups become less about team collaboration and more of an update for the scrum master.
A scrum master is not a 'manager' in any sense. Their main focus is to protect the team, uphold dwyl's values and ensure the priorities are clear and sensical.
A lot of this is communication.
It's the difference between: "I don't think you should be doing X, please do Y instead, the client was very clear about their priorities".
and
"You're planning to test X today? I respect that. I remember in our sprint planning meeting our client spoke 3 times about how Y was their highest priority and we haven't tackled that yet so that one is also worth considering. Do we need a plan to make sure Y gets done this week or are there blockers for Y that I can follow up on?"
Ensure priorities are clear. Eliminate blockers. Encourage the team to be accountable to the client, not just the scrum master.
This is not an easy balance to strike when the scrum master has for example been with the organisation a long time and is well respected (there is a natural 'deference' of sorts) or when a team is particularly junior and the scrum master must play a dual role of scrum master and gently steering things based on their experience.
This is a really handy issue @iteles. Will refer back to this a lot 😊
Thanks!