The Scrum Master Dilemma: To Mandate or Not?

​During the Q&A portion of an Agile panel discussion, a Scrum Master asked the following question:
“My team prefers to have their daily scrum just twice per week. I know I can’t mandate that they have it daily, so what should I do?”
 
My initial reaction was to unmute zoom and shout “Of course you can mandate this! It’s called the DAILY Scrum for a reason!”, citing the official event title from the Scrum Guide. However, instead of prescriptively waving the Scrum gospel around, I paused to contemplate the word she used: “mandate”.
 
According to dictionary.com, mandate (when used as a verb) is to order or require; make mandatory. When you mandate something, you are coming from a place of authority, of leadership. You are now dictating the process; you are setting the rules.
 
Do Scrum Masters have the right to mandate rules to a team?
 
Yes.
And…
Sometimes no.
 
I know, I know, everyone hates a wishy-washy answer but hear me out.
 
Have you heard the phrase “Shu-Ha-Ri”? This term is derived from martial arts and is used to describe the progression of training or learning. Essentially, there are three stages of acquiring knowledge. I like to think of it as:

• Shu Stage: Learn the Rules
• Ha Stage: Bend the Rules
• Ri Stage: Break the Rules

If the team is at the Shu stage, they need to master the basic rules before attempting to customize them. Using the Daily Scrum example above, a Shu level team needs to first understand and abide by the underlying guidelines.
 
For example, this means meeting on a consistent basis (daily), keeping the Daily Scrum focused, raising impediments, strategizing towards completing the sprint goal, and containing it within a 15-minute time frame. Until these elements of the Daily Scrum are truly ingrained in the team’s DNA, I would expect the Scrum Master to continually reinforce (mandate) these rules.
 
When the team has moved past “Shu”, the Scrum Master can take a more flexible or pragmatic approach.
 
What indicates that the team has advanced from “Shu” to “Ha”? Or from “Ha to Ri”? Unfortunately, there is no magical “Ha-Ri Finish Line”, but you can hunt for clues such as:

• The Daily Scrum is held at the same time and place, regardless of who is in attendance.
• The Dev team facilitates the event themselves, without relying on the Scrum Master or Product Owner as a crutch.
• There’s vibrating, ambitious energy surrounding the completion of upcoming work against the Sprint timebox.
• The conversation is natural and organic. Questions such as “When can we start testing?“  are raised and answered.
• Team members freely request help and/or hold one another accountable.
• The team’s Story Point burn down chart is clearly displayed and analyzed. The team focuses on the sprint trends and strategizes how they will meet their Sprint goals. 
• The Dev team elects to meet twice a day, once during the morning Scrum and once in the late afternoon, as an extra touchpoint.
• The Dev team prefers to work as a cohesive unit, situated in the same room, pair programming, or mobbing together.

The above examples are indicative that the team has fully embraced the agile mindset (being agile, not just doing it).
 
As a Scrum Master observing these behaviors, I would feel confident stepping back and allowing the Dev team to bend some rules (ie: scheduling their daily scrum twice per week). However, I would monitor them to make sure they continue to stay within the guardrails of the framework, values, and principles, since it’s easy to get complacent.
 
In summary, there is a certain rhythm and rigor to Scrum. The Scrum Master’s job is to promote/support Scrum by helping everyone understand Scrum theory, practices, rules, and values. How this looks depends on the maturity of the team.
 
The one question I will always go back to is: Is this a true Shu, Ha, or Ri level team? The answer to this question almost always determines the best approach or course of action.