I regularly hear about the problems Scrum Masters face. After more than 200 interviews with Scrum Masters in the Scrum Master Toolbox Podcast, here are the 3 most common problems that we face in our work, in order of frequenc):
- As a Scrum Master, I lack support from management, and when they don’t actively fight Agile adoption, they are disengaged. This lack of engagement by managers undermines my work as a Scrum Master in many ways, for example: by giving permission to the team to release without testing properly, or to work in silos instead of collaborating with other teams.
- As a Scrum Master, I see Management starting Agile adoption because it is fashionable or “my friend’s company also started it”, or even worse: because the Board of the company mandated that we adopt Agile to deliver more, and faster. In other words, there’s no Vision for the Agile adoption journey.
- As a Scrum Master, I try to get team members to collaborate, but they prefer to work alone and aren’t able to see the problems they cause to other teams and other colleagues. I can see these systemic problems and their consequences, so I feel frustrated.
These are the most common “reasons” Scrum Masters see themselves failing and struggle to help the teams they work with, and ultimately the organizations they are there to help.
Can we really find simple approaches that help us tackle these problems?
I’ve come to value two very simple heuristics that have helped me either solve or cope with these problems. My goal as a Scrum Master is simple: have a positive impact on the people I work with.
Let me clarify that.
I don’t think that my job is to save the team from the “big, bad management wolves” or to help the organization I work with become “successful”. I’ve learned that those are impossible goals, and – most often – can lead us astray from our true mission: leave our environment a little better than we found it, by being the change we advocate others to take.
As a Scrum Master, I succeed when other people around me feel that my presence has contributed to their success.
Roughly quoting Einstein: “try not to become a person of success but rather try to become a person of value.”
Here are the heuristics I follow in my own work, which I believe help me tackle the 3 most common problems Scrum Masters face:
- Don’t shrink anyone, you are there to be of value, not to save people from themselves
- Don’t focus on safety, focus on impact. Help your team become a valuable team, not a safe haven for people who are afraid of growing.
Let me explain these a bit more.
Vasco’s Scrum Master Heuristic #1: Don’t shrink anyone
I see many of my fellow Scrum Masters focusing on simple, yet elusive techniques. These techniques are there to either manipulate people into doing something they think is right or saving people from their own psychological traumas.
A simple example is when a Scrum Master tries to “make” team members collaborate who clearly are not mentally equipped to work in a collaborative environment.
Come closer. Just between you and me: not everyone is ready to take on what it takes to be a team player. It’s that simple!
Should you as a Scrum Master motivate, cajole and ultimately manipulate someone to “become” a team player? No!
Professional psychologists have looked into what are the characteristics and personality traits that help a person become a great team player. Some of those can be developed with the help of a professional, which you probably aren’t! However, some of these personal characteristics are innate to the individual – impossible to change.
Without the skills that psychologists develop over decades, it is nearly impossible to help people overcome the barriers to becoming a great team player.
My own check-list for great team players is below. But in simple terms: some people will always prefer to work alone. If that’s OK in your environment, great! If not, then step back and let that person follow their path. Focus on the team instead! You are there to help the team grow, and sometimes that means growing out of a person’s contribution.
A checklist for detecting great team players
- Offers help in the Scrum Daily, without wanting to force others to take their idea
- Accepts feedback, and recognizes contribution by others even when they disagree with the content of the contribution
- Challenges other’s perspectives, but does not make that challenge a competition for the “only truth”
- Asks for help when in doubt if the Sprint Goal can be reached
- Accepts help when offered help by others
- Raises problems in meetings, and quickly focuses on finding possible solutions with the rest of the team
- Asks for a clear goal when the goal is not clear
- Sometimes, goes beyond the call of duty to deliver on a team-goal.
If you don’t see at least 3-4 of these in a team member, then you may want to focus on those team members that have those behaviors! Remember, if you amplify collaboration and being a team player you will get more collaboration and more team players!
Vasco’s Scrum Master Heuristic #2: Don’t focus on safety, focus on impact
It is currently popular to focus on Psychologic Safety. Here’s the thing. What’s a safe environment for me may not be for another person. Let me give you a concrete example.
As a senior developer gets challenged, that developer may receive that challenge as a gift. A tool to help them think through the problem in a deeper and more insightful manner.
If the exact same challenge is delivered to a junior developer, that developer may feel their competence being challenged, rather than their proposal.
To some extent this is unavoidable. We all have insecurities that get triggered in some situations. So my choice in these situations is simple: bring the discussion back to the goal of the team.
In practical terms, I try to help the team discuss and agree on their goal. The impact they hope to create. The goal for the team can be, for example, the Sprint Goal. And it is that goal that should be the driving force for the interactions. Not safety.
When the team believes the goal they share, they are able to recover more easily from moments of temporary lack of safety. Remember, lack of safety is unavoidable to some extent.
The Ethics of the Scrum Master
These simple heuristics are not “right” (or wrong), they are simple guides that help me in my work when I have doubts or need to quickly react to a situation that the team faces or I face.
Heuristics like this are what will evolve the Scrum Master profession. Over time, I hope, we will develop a code based on real-world experiences, which may become a set of ethical standards.
One such ethical standard for me follows directly from the heuristics above: Don’t try to act outside your domain of expertise. I’m no psychologist. If you are reading this, chances are you aren’t either. So I choose to focus on my domain: collaboration with the aim to reach an explicit goal.
As a Scrum Master, my domain of expertise is collaboration!
2 thoughts on “Two simple heuristics that will solve (most of) the problems you face as a Scrum Master”
Comments are closed.