During my Scrum master training, I was taught that my goal was to help the team become Agile. That involved helping remove blockers and obstacles, and coaching the team to become self-managed and deliver value. I took that as my north star.

Every time I saw what I interpreted as an obstacle or blocker, I tried to intervene right away. The problem was that my interventions weren’t landing. Any proposal I made was ignored, and new experiments coming out of our retro were abandoned.

On one occasion, I just joined a new team. On our standup, I noticed they were adding a small number of vaguely titled tasks to their board. I thought this would be a good teaching moment and proceeded to give advice on how it would be helpful to add more details to their tasks for transparency and to allow other team members to help out.

The message was acknowledged. However, the next couple of days, the team continued with their regular way of tasking. I was contacted on the side by a more senior team member who mentioned they are a mature team set in their ways, so they probably won’t change their regular way of working.

It was a deflating moment.

What Was I Missing?

A couple of years later, I attended an Agile conference and was shocked to learn that other Scrum masters had gone through something which I found familiar: they attempted to engage with their teams only to be ignored and pushed to the side.

Unfortunately, in those conversations, no one mentioned a solution. I was left wondering what I was missing. What should I be doing differently to help my teams?

I left the conference without an answer to these questions, but I did talk through this problem with another Scrum master from work. We shared experiences and brainstormed. One of them made me pause and think.

What if I do the opposite? Instead of constant interventions, why not try to contribute less?

The Art of Observation

In meetings, we tend to think that a good contributor is someone who is engaged and actively participating. You are visibly doing something. However, I learned there was more to being a good participant. It all depended on your role.

Meetings have several roles, according to the PROOF model by Agile coach Frank Saucier, and one of them is the observer. You would assume this is a passive role, and in a way, that is true. They are not contributing as actively as the rest. However, the role of the observer is to learn something by watching the content of the meeting and how it’s run.

I decided to change my approach, to be less active and observe more. I’ll admit this was hard at first since I thought that by participating less, I wasn’t providing value in a meeting.

I decided to change my approach, to be less active and observe more. I’ll admit this was hard at first since I thought that by participating less, I wasn’t providing value in a meeting. However, this approach suggested prioritizing learning over acting.

Keeping a Log

I started my approach by keeping a log. Every day, I would record one interesting moment, something that caught my attention and would usually have me trying to intervene right away.

Maybe engagement in a call was low, maybe I perceived confusion when the team was talking about a new story. Anything that would usually make me react right away was instead logged.

After a couple of days of logging data, I was ready to make a hypothesis: What did I perceive was happening to the team? What was a challenge that I saw they were having that was not being addressed? How was it impacting them? These were the guiding questions I used to formulate a theory.

Waiting Before Intervening

On one occasion, one of my teams had an odd standup where the event went way too long, and I sensed we walked away with more confusion than when we started. I let it play out and logged what I was hearing as well as how the board was being updated.

With the context of what the team was working on, I made an assumption that the team needed more detail on their tasks. A difference from what we had in our working agreement, where we wanted to avoid having “Status updates.”

Instead of acting right away at the next standup, I continued to observe and log what I was seeing.

Instead of acting right away at the next standup, I continued to observe and log what I was seeing. I noticed the longer conversations were mostly about testing, and the team seemed to have different opinions about what the results meant and what should happen next.

The team explained that the real issue was a new tool they were using to test APIs. The tool was producing confusing results, so they decided to hold a working session to share what they had learned and build a common understanding.

This was an eye-opening moment. If I had intervened right away, I might have diagnosed the wrong problem (not enough details on tasks) and coached for something they didn’t need. Instead, I waited and observed to have better information to bring to the team.

The Mindset Behind Gathering Information

The mindset behind gathering information is important. The goal is to build a theory, support it with observations, and make sure the next step is based on what is actually happening.

Something to highlight is that this approach is not meant to be fully passive. If I catch visible tension or something that needs my intervention immediately, I act accordingly.

A good example is if I heard two teammates arguing in a call. That’s an obvious sign to step in right away.

Contributing Less

This experience helped me shape the way I interact with my teams. I started making a habit of gathering interesting information on how the team works together and presenting that information in either a retro or in one-on-one conversations.

This, in turn, creates good discussions with the team, discussions in which they share their experiences and surface problems that are slowing them down.

Usually, my theories are wrong or have only half of the story of what is really going on. But in return, I feel I am being a better influence, and my coaching has more impact, all of it by contributing less.