Statement: Scrum Master: “Team, I’m canceling tomorrow’s Daily Scrum because I have a doctor’s appointment and I can’t be here to run the meeting.”
Anti-pattern: The Meeting King.
Problem: The Daily Scrum is not about or for the Scrum Master. It is a daily planning meeting for the Developers by the Developers.
Recommendation: Ensure that the Developers understand the purpose of the Daily Scrum and keep it focused on the plan for the day based on the progress made so far towards the Sprint Goal. As a Scrum Master, slowly take yourself out of the focus of the discussion and empower the team to self-organize.
Explanation:
A statement like this indicates a misunderstanding of the Daily Scrum’s purpose, the ScrumMaster’s accountability, and the importance of adhering to a cadence.
A common misconception is that the Daily Scrum is a status meeting with the Developers reporting status to the ScrumMaster, Product Owner, managers, or stakeholders. The Daily Scrum is a daily planning meeting for the team by the team. It is an important step in Scrum’s inspect and adapt cycles. This time it is about inspecting and adapting the Sprint Backlog and planning out the day. The Developers created the initial Sprint Backlog at the beginning of the Sprint in the Sprint Planning. Every day, the team gets together to coordinate and plan their activities for that day, ensure they are making progress toward the Sprint Goal, and adjust the Sprint Backlog accordingly.
Whether the ScrumMaster is there or not is immaterial. The key players in this event are the Developers. They are there to come up with the plan for the day and see if adjustments need to be made to meet the Sprint Goal, ask for help, volunteer to help, etc.
If the ScrumMaster is there, then they are there to increase the team’s effectiveness, facilitate the discussion by keeping it focused on the Sprint Goal, stay within the timebox, make sure impediments are visible and actively being worked on, and ensure progress is being made toward the Spring Goal. As the team grows and matures and becomes more self-organizing, any team member can help with that.
Finally, sticking to a cadence simplifies scheduling. Having to keep shifting, canceling, and rescheduling events based on people’s availability adds an unnecessary extra layer of complexity. It is ok if someone cannot make it to an event every once in a while, especially with an event that occurs daily. They can always get caught up afterward if needed.
- Tales of the Bizarro Scrum
- Tales of the Bizarro Scrum – Developers and Deliverables
- Tales of the Bizarro Scrum – Are You Sure It’s Going to Take this Long?
- Tales of the Bizarro Scrum – The BAs are Holding Us Back!
- Tales of the Bizarro Scrum – Yes, We Are a Self-organizing Team
- Tales of the Bizarro Scrum – Assigning Points to Everything
- Tales of the Bizarro Scrum – Isn’t Scrum Just a Team Level Thing?
- Tales of the Bizarro Scrum – The Code Freeze
- Tales of the Bizarro Scrum – Refining the upcoming 8 Sprints?
- Tales of the Bizarro Scrum – Of Course We Are Agile!
- Tales of the Bizarro Scrum – I’m Responsible for Writing User Stories
- Tales of the Bizarro Scrum – Meeting King
- Tales of the Bizarro Scrum – The Sprint was a Colossal Failure
- Tales of the Bizarro Scrum – When is Sprint Planning?
- Tales of the Bizarro Scrum – Canceling the Sprint Retrospective
- Tales of the Bizarro Scrum – Product Owner Missing Sprint Planning?
- Tales of the Bizarro Scrum – Extending the Sprint
- Tales of the Bizarro Scrum – I’m the Product Owner and Scrum Master
- Tales of the Bizarro Scrum – The Variable Sprint Duration