I remember my first job as a ScrumMaster. I took it very seriously. I saw my job as being the custodian of Scrum, and ensuring everyone was doing it correctly.
Does any of the following sound familiar to you?
- Make sure all the Scrum meetings are set up and rooms booked
- One minute before the daily standup, call people to make sure everyone attends the meeting
- Call each person’s name for them to answer the three questions in the daily meeting
- Make sure any discussion outside the three questions gets parked for after the standup meeting
- Time the daily scrum to make sure it never exceeds 15 minutes
- Insist that templates get used for stories
- Insist that story points are used
- Create a company-wide template for all Scrum artifacts
- Force everyone in the team to attend retrospectives
- Ensure the team completes everything they committed to each sprint
- Assign work to team members in the sprint
- Complete Scrum assessments online to see how your team compares to other teams
I did all of the above with the best intentions.
I really wanted Scrum to work, and I really wanted to help my team succeed. I thought this was what was necessary for them to succeed, and I thought that it was what my job entailed.
Experience has taught me that whilst the above seemed like a good idea, I was actually slowing down my team’s learning curve and its level of maturity as a team.
So what would a ScrumMaster with more experience do with the examples I mentioned above? Let’s look at that closer.
“Make sure all the Scrum meetings are set up and rooms booked.”
Anyone on the team should be able to book meetings and rooms. Perhaps ask the product owner to book the review and backlog grooming meetings, since they would know which stakeholders to invite, and ask a team member to book the daily standups.
“One minute before the daily standup, call people to make sure everyone attends the meeting.”
Don’t call people for standup, just start on time. If no one arrives, then sit down again. Ask the team during the retrospective if they missed the standup or if something might have gone better if they had the standup. If you teach them to rely on you calling them, they will not take accountability for themselves to be at the meeting on time.
“Call each person’s name for them to answer the three questions in the daily meeting.”
Let the team decide how to do this, even if the first few are a little chaotic. Consider what would happen if you weren’t there for a standup. Also, calling peoples’ names implies they are reporting to you; instead, they should be talking to each other. Ask a question at the end like, “Is there anything we would like to change for tomorrow?”
“Make sure any discussion outside the three questions gets parked for after the standup meeting.”
Although the standup is not supposed to be a problem-solving meeting, you need to use your judgment on if the conversation is adding value to the participants. Better yet, encourage the team to call each other if they go off topic in the standup, rather than you having to monitor it.
“Time the daily scrum to make sure it NEVER exceeds 15 minutes.”
Although daily scrums should be 15 minutes or less, actively timing them usually means you are focusing on the wrong thing, and will drive the behavior of having a three-minute meeting of no value, just to be able to “look good.” The duration is much less important the the content of the conversation.
“Insist that certain templates get used for stories.”
Don’t force any story templates. The point of a story is to have a conversation and shared understanding. Templates imply written documents, and changes the emphasis from the discussion to the artifact.
“Insist that story points are used.”
Let the team decide how they want to size stories. We have a workshop you can run to try out four different styles, then let the team decide what works best for them.
“Create a company-wide template for all Scrum artifacts.”
Allow teams to create their own artifacts. This gives them some freedom, creativity and allows them to express themselves. Consistency is much less important than people having the ability to change things to fit their own needs better.
“Force everyone in the team to attend retrospectives.”
Retrospectives should be valuable enough that the team wants to attend them. If people don’t want to attend, don’t force them. Rather find out why they don’t want to be there, and work on that problem.
“Ensure the team completes everything they committed to each sprint.”
As a ScrumMaster, you are not responsible for delivery. The point of commitments and actuals is not for them to always match, but rather for your team to figure out what they can deliver comfortably.
“Assign work to team members in the sprint.”
If you feel the need to assign team members work, I would dig a bit deeper and see what the underlying reason is. Asking the team an open question like, “Is there anyone on the team who can help with this?” is better than assigning something to someone on the team.
“Complete Scrum assessments online to measure how your team compares to other teams.”
While Scrum assessments might be helpful, the team should be assessing itself and deciding what the results mean for the team. Usually, if Scrum Masters are assessing their teams, it is because they are wanting to see how their team is doing as a reflection of their value as a Scrum Master. Rather, ask your team what you can do to add value to the team as a Scrum Master.
Some Final Thoughts
Consider if you are making your team dependent on you, or helping them become a self-organizing team. Try to be less of a master ordering the team around and more of a servant leader, helping the team become better than it is today. These days, we judge the effectiveness of ScrumMasters by how well the team learns, deals with conflict and collaborates, rather than which boxes they check on a Scrum checklist.