...you have a ScrumMaster who is serving a Development Team. The Development Team is supposed to use the Daily Scrum to share information on progress and to adjust the direction of the Sprint Backlog, to coordinate remaining work in the Sprint.

✥       ✥       ✥ 

At the Daily Scrum, the Development Team members address the ScrumMaster instead of discussing issues with each other. The Development Team members repeatedly await direction or approval before acting. This implies that they are neither taking ownership of the event nor acting as a team.

Scrum Development Team members are in the best position to know the details of implementation planning. Far too often, developers play it safe by just using the meeting to report current status to the ScrumMaster instead of taking decisions to replan the Sprint. This may be a habit from a former Project Manager relationship, or it may reflect the team’s misunderstanding of the ScrumMaster role. If I am a developer at the Daily Scrum and I say something, I probably will focus my words on the one person who I am pretty sure is listening (because they insisted on having the meeting), so the tendency in a weak team might be to address the ScrumMaster. The dysfunction may go so far that the team expects explicit direction from the ScrumMaster.

Therefore:

As the owner of the Scrum process, it is the ScrumMaster’s job to ensure the team takes ownership of the Daily Scrum.

✥       ✥       ✥ 

One way to remove this problem is for the ScrumMaster to become invisible. For example the ScrumMaster can move to stand behind a person who persists in reporting status, or can just quietly leave the room. Another way is to educate the Development Team members on why it is important that they take responsibility.

The Daily Scrum is about inspecting the progress in the current Sprint and adapting the work plan to reach the Sprint Goal. The Development Team therefore owns the Daily Scrum. The ScrumMaster may still attend, but will not intervene in the Development Team’s planning unless asked—and then never by directing them or prejudicing their judgment on organizing the work. (The ScrumMaster may intervene on issues of process, such as time-boxing, but it is still best that the developers handle even these issues themselves.)

This relationship between the Development Team and the ScrumMaster of course extends beyond the Daily Scrum to all aspects of how the team builds the product.

Building the intrinsic motivation to take responsibility to plan their own work requires that the team is confident and that its members be invested in the results. Both of these are preconditions for cutting the apron strings to the ScrumMaster, and each of these grows as the team becomes more autonomous (see Autonomous Team) and boosts its self-esteem (see Team Pride).

The ScrumMaster need not be present at the Daily Scrum. The ScrumMaster makes the benefit of the Daily Scrum clear to the team members so that they themselves take ownership of its result.

Picture credits: The Scrum Patterns Group (Lachlan Heasman).