Why your eyes and ears are the most important tools you have as a Scrum Master

What are your most important tool as a Scrum Master? Here are some ideas:

A task board. Helps the team coordinate their work and keep track of the progress.

Some sticky notes and sharpies. Quick and easy tools to make everything visible!

A burn-up or burn-down chart. Is the team and project on track?

A team barometer. Is the team happy?

A Scrum checklist. Are we following the rules of Scrum or are we taking shortcuts?

All of these can certainly be useful to help us do a good job, when we use them appropriately. However, there are two tools that trump them all:

Your eyes and ears.

A Scrum Master’s most important job

As a Scrum Master, the most important responsibility is to help the team and the product owner get the maximum value out of working in an agile way, so that they can create awesome products. This means that we always need to observe what is going on. It just isn’t enough to wait for the sprint retrospective to see what issues might come up. The issues don’t just appear during the retrospective, they happen during the sprint. That’s where we need to look out for them!

In this article, I’ll list just a few of those things to look out for. However, while checklists can be useful, they can easily make us focus on ticking boxes for the sake of ticking boxes. Therefore, don’t use the below as a guide what to look out for. Rather, consider it a bit of inspiration!

Listening to what is being said

Simply listening to what people say is an incredibly powerful tool.

Is the team aware of whether they are on track to meet the sprint goal? If not, do they care and what, if anything, are they doing about it?

Do people seem to understand the true purpose of the various Scrum events? Or do they treat them as process for process sake, with no real value?

Does the team self-organise around the work or are they being micro-managed by the product owner or a team member? Or, indeed, by their Scrum Master?

Is the product owner on the team’s side or do they hang them out to dry in front of the stakeholders in the sprint review?

Is the team working to find the best solutions to the users’ needs? Or is there a lot of up-front planning with the team just working from a fixed set of requirements and solutions, with no innovation?

Just listening in, without interfering, is a great way for getting a feeling for what is going on. I also find another bonus with this method. My brain needs time to process things. Listening without having to come up with answers right there and then saves me from occupying my mind with what I am going to respond, which would cause me to miss important details!

Not just passively observing

However, this passive listening, no matter how focused, won’t give us the whole picture. That’s why it is also important to talk to people. Not primarily to let them know what we think but to learn more about what they think. Talking to someone one-to-one is great for getting below what happens on the very surface of things. And don’t limit yourself to the team members – the product owner deserves to be heard too.

I know I’m not doing this quite as much as I should, so as my New Year’s resolution this year, I’m scheduling a catch up with a different person each week, making sure I get through everyone on the team, so that I don’t just talk to the people I always talk to.

Looking out for what isn’t said

Just listening to what people say isn’t enough, though. Some information isn’t spoken out loud but is still there for you to see if you keep a close eye to things.

Is the team working together as a team to meet the sprint goal or are they working as individuals, each focused on their own stories?

Does the team keep having to tackle urgent issues, preventing them from focusing on deliveriong product value?

Are people energetic and is the work engaging them or are they bored or frustrated?

Is the product owner involved with the team or are they frequently missing from daily stand ups or even sprint planning meetings or reviews?

Is the backlog made up features and solutions rather than user-focused needs?

Are the backlog items in the sprint planning sufficiently prepared and the most valuable things we could be doing right now?

Is the team delivering high-quality software, using suitable technical practices on top of Scrum, or do they take shortcuts, resulting in lots of bugs getting raised?

Turning observations into actions

So, what do we do with all this information we’ve gathered while observing everything that’s going on?

The first thing is to verify whether what we’ve observed is an actual thing or if it is just something we’ve made up. Yes, my mind does make things up sometimes!

There are two ways to do this. Ideally, use them both!

Firstly, we need to find out whether there is any evidence to support what we think we’ve observed. For example, if it seems lots of stories carry over from sprint to sprint, look at the numbers. How many stories did the team bring in and how many did they finish? Is there data from previous sprints to see if this has been going on for a while or whether it is a new issue?

Secondly, as a Scrum Master you needs to talk to people (yes, more talking!). Mind you, not to tell them “You have got this problem!” but to find out if they are making the same observation. Tell them what you’ve seen and ask what they make of it. For example, you might say “I saw in the sprint planning today that people were on their laptops and it felt to me as if there was very little energy in the room. Did you see that too or was it just me?”. And if they agree, dig deeper: “Why do you think that might have been?”.

Deal with it straight away or later

Some issues make the most sense to deal with straight away, for example if they put the sprint goal at risk. Others can wait until the retrospective. Whichever way makes sense in the particular case, remember that the Scrum Master isn’t necessarily the best person to solve the problem (the team may have better skills and knowledge). And before coming up with solutions, make sure we’re looking at the actual problem and not the symptoms of it.

For example, the problem is unlikely to be that the team is doing the work too slowly. Rather, something is preventing them from going as fast as they could. That is the thing that needs to be fixed.

A bonus tool

Oh, all of this leads to another set of tools I value in my Scrum Master toolbox: a good old notebook and a pen! When keeping my eyes and ears open, there is always a lot going on. I spot things all the time but am not always sure what they mean. I need to remind myself to look out for them in the future.

In other cases, the observations are on a more personal level. I did something and it worked well or it didn’t. Those things, I want to make sure I remember. I simply can’t trust my brain to keep track of all of them, so I need to write them down.