ScrumMaster Incognito*

Find the ScrumMaster in this picture.

... 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 repeatedly awaits direction or approval before acting. This means 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 re-plan 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 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 for planning their own work requires that the team be confident and that they 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 and builds a sense of 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 so that they themselves take ownership of its result.


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