Experiment: Observe What is Happening

Inexperienced Scrum Masters often rush to solve problems, offer suggestions, and show the path forward. While this can be helpful, it can also impede a team’s ability to learn and grow and undermine their ability to self-organize. This experiment is designed for Scrum Masters to find a better balance between solving problems and enabling growth and autonomy.

Required skill

The difficulty depends on your ability to sit on your hands. Most Scrum Masters are eager to help, and that makes this difficult.

Impact on survival

Being able to observe the system of the Scrum team is a great way to start seeing bigger impediments.

Steps

To try this experiment, do the following:

1. At the start of a Sprint, ask for permission from the team to step back this Sprint. This is a good moment to talk about self-organization and how you can get in the way of that. As a Scrum Master, you still participate in various events, but not actively. So no facilitation, no suggestions, or taking the lead. You remain available to answer questions or help when the team is stuck.
2. During the Sprint, observe what is happening as the team does its work. Use the list as described in the next section as inspiration. Whenever you observe something, don’t jump to conclusions or interpretations. Instead, ask yourself what you are specifically seeing or hearing.
3. In the Sprint Retrospective, explore what it was like for your team to have you in a passive role. What became possible because of it? Where did they notice self-organization?
4. If the team is up for this, you can share your factual observations during the Sprint Retrospective. For example, say “I see that 7 out of 10 items are ‘In Progress’ on the first day of the Sprint” or “I noticed that the Daily Scrum usually starts 5 to 8 minutes later as people have to wait for others to join”. Give your team the first opportunity to recognize and make sense of the observations, then share your own in a constructive way. What has the team learned about their work together? Which impediments have you noticed?
5. Use your observations to drive the open questions you ask during the Sprint. A well-timed powerful question, built on observations, can create huge insights that would otherwise take months to discover. For example: “This Sprint, we never interacted with our stakeholders. How does this align with our goal to build a valuable product for them?”

A well-timed powerful question, built on observations, can create huge insights that would otherwise take months to discover.

Here are some things you can pay attention to in your observations:

• What do interactions in the team look like? Who is often talking? Who is not?
• What usually happens when someone in the team suggests something? Is it considered? Ignored? Criticized? Expanded on with additional ideas?
• What does the flow of work look like during a Sprint? How much work is in progress on a given day of the Sprint? What kind of items tend to remain in their column for a long time? Who notices this?
• What impact do dependencies have on the team? When do they happen? What do they look like? How long do they have to wait in order to continue?
• What is the atmosphere like during a Sprint? Are people laughing or smiling? Are there strong emotional responses? Do people work with others or mostly alone?
• What happens when the team runs into problems? Who takes the initiative to resolve them? Who is involved and who isn’t? Is it always the same person taking the lead? Do they explore different options and then pick one, or do they go straight to a solution?

What happens when the team runs into problems? Who takes the initiative to resolve them?

• How do the Developers interact with the Product Owner? How often is the Product Owner present? What kind of questions does the Product Owner get? And what kind of answers are given? What considerations does a Product Owner use in deciding how to order the Product Backlog? Are all the Developers involved in this?
• How does the team organize and coordinate its work? What kind of decisions are made during the Daily Scrum?
• How does the team interact with its environment? How often do they interact with other Scrum teams? How often are they interrupted by people walking in with requests?

Our findings

• The skill to observe what is happening is also one for the Scrum team to learn. You can experiment with rotating the role. The “observer” still does his or her work but takes a passive role during gatherings.
• It can be hard to sit on your hands when you’re used to taking the lead. Especially when you notice that the team is struggling. Trust in their ability to figure it out. The flip side is also true; don’t sit on your hands all the time. Scrum Masters have a lot of work to do when they want to help entire organizations work empirically. Consider this experiment as taking a breather and using that time to inform your next steps.
• This experiment requires that the team trusts you as a Scrum Master. Otherwise, observation will feel like spying. Be very clear about the purpose of your observations and that you only share them with the team. If trust is low, start with other experiments to build that trust. Or practice the role of observer for a single Scrum event first.

Looking for more experiments?

Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum team. Each of them is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.