The Daily Scrum That Reports to the Scrum Master
A Scrum Master supports two teams. On Team A (seven developers, one PO, one SM), the Daily Scrum runs 25 minutes. Each developer gives a status report to the Scrum Master, who takes notes and then assigns follow-ups: 'Priya, help Tom after this.' The developers have stopped talking to each other outside the event and route coordination through the SM. Two developers have privately said the meeting is 'for management.' The team's Sprint Goal is at risk because an integration dependency was discovered on day 6 of a 10-day Sprint and nobody raised it until the Daily Scrum. The SM is also the de facto coordinator for a cross-team API dependency with Team B.
1. Diagnose what has gone wrong with the Daily Scrum and what the Scrum Master must stop doing.
Read the worked answer
The Daily Scrum has become a status meeting owned by the Scrum Master, which inverts its purpose. It exists for the Developers to inspect progress toward the Sprint Goal and adapt their plan for the next 24 hours. When the SM takes notes and assigns work, the Developers learn that coordination is the SM's job, so they stop self-organizing - exactly the symptom described (dependency surfaced on day 6, not day 1).
The SM must stop: running the meeting, taking minutes as a record, and assigning follow-ups. Those behaviors are the mechanism producing the dependency. The SM's job is to teach the team to own the event and to make the impediment visible, not to become the impediment's router.
2. How should the Scrum Master re-establish the Developers' ownership of the event without abandoning them?
Read the worked answer
Use a coaching approach rather than a rules announcement. Options:
- Ask the team what the Daily Scrum is for and what they'd change; let them redesign the format (e.g., walking the board by Sprint Goal, or a 'what's blocking the Goal' round).
- Agree explicitly that the SM will attend as an observer and speak only if asked, for a trial period of two Sprints.
- Have the Developers identify the integration dependency themselves and decide who owns the conversation with Team B.
The SM should expect a dip: the first few Daily Scrums may run long or drift. That is normal learning, not evidence the old format was better. The SM's measure of success is whether dependencies surface earlier, not whether the meeting is tidy.
3. The cross-team API dependency with Team B is real and urgent. How does the Scrum Master handle it without re-centralizing coordination?
Read the worked answer
Separate the impediment from the event. The dependency is legitimate; the SM can help remove it without owning all coordination. The SM might:
- Make the dependency visible (e.g., on a shared board or in the teams' backlogs) so it is inspected, not remembered.
- Facilitate a one-time conversation between the two Developers who actually do the work, then step out.
- Coach the teams to build a lightweight agreement about how cross-team dependencies are raised - ideally before they become urgent.
If the SM keeps being the sole channel, the dependency will keep being invisible until it's late. The goal is a system where Developers coordinate directly and the SM removes what blocks them.