In this series of articles, we will explore the qualities and behaviours necessary to be an effective Scrum Master and why those qualities and behaviours are important in specific situations.

Before we start, however, here is a spoiler: the secret to being an effective Scrum Master is to help the team manage itself, so you can spend your time managing the outside world (stakeholders, dependencies, etc.)

Easier said than done, of course. Let us see what that means on the ground.

Context

You have been designated to become the Scrum Master of a team you have not worked with previously. With a mix of excitement and anxiety, you start wondering if you will be up to the task – that infamous imposter syndrome that seems to come with adulthood. What, you ask yourself, makes a good Scrum Master anyway?

At this point, you remember what you have read and studied, in preparation for this moment: mostly constructions such as “servant leader,” “team empowerment,” “self-organised teams,” “Kanban board” and “DevOps culture.” All the above are cliché catchphrases for a good reason: they are all genuine signs of success for a team. They are more than buzzwords to recite at a job interview, though.

Semantics

Before we go on, let us do a quick vocabulary check. The role of “Scrum Master” here is meant as “leader of a team,” not necessarily as “leader of a Scrum team.” In close to fifteen years of leading teams of sorts, I have not come across one that did not benefit from some level of management or guidance applied, whether it is following Scrum, Kanban, or any other type of framework, whether Agile or not. Teams that do not need such leadership may exist; they are, however, not as common as literature would have you believe.

Now that you agree that a Scrum Master is useful at the very least, necessary in most cases, why should it be you?

Who should be Scrum Master?

In other lives, you may have seen an engineer in the team do the role; or a Product Owner (PO); a business analyst (BA); or even a project manager (PM) or delivery manager (DM). Did that not work well enough?

Well, here is a specific role that requires a specific set of skills (as Liam Neeson would say). Individuals performing the other roles listed above may be qualified, yet they often have antagonistic objectives and interests: an engineer may be passionate about test automation, or addressing technical debt; a PM may be under pressure to deliver a certain epic by a certain date; a BA might want to satisfy the requirement of a stakeholder they get on particularly well with; a PO should be keen to deliver the next valuable feature. Moreover, they have a day job already. It is unlikely they will be able to dedicate the time needed to be an efficient Scrum Master.

The Scrum Master must be agnostic. They are not trying to please one individual, but all of the above, often by seeking consensus between the various interests. Most often, the best approach is therefore to have a dedicated Scrum Master, so they can remain agnostic and dedicated to the job.

Since you are the only valid candidate for this role, let us go back to this new assignment of yours, then. Over the subsequent articles, we will look at the following in more detail:

• Land

• Get into the groove

• Set some ground rules

  • Define terminology

  • Control scope

  • Start less, finish more

• Empower

• Continually improve

Land

Sometimes, you can prepare ahead of meeting your new outfit. If you are lucky, an engagement lead, perhaps even your predecessor, will have sent you a fact sheet listing the things to look out for in the team you are about to lead. Very often, though, you will fly blind for a little while. Whether the team is newly set up or an existing squad that you integrate matters little: you are new and you do not know each other. Any change in a team’s composition results in a new team, with its own dynamics and performance. The arrival of a new Scrum Master is quite the seismic shift, for a team, and that is felt even more dramatically if the team is already in place when you land.

With that in mind, you could do worse than prepare for a discovery period, in which the team and you learn to work together (they will also have to get used to you). Whilst you do that, make sure you explain what is going on to your client and a time frame for it. They might expect that this expert they have hired has a magic wand to deliver miracles and you do not want them to be disappointed with the reality. Share your vision. Show that you are taking control. Your client will feel reassured that you know what you are doing. Show good leadership by being an outstanding communicator.

As for taming the team, start by observing without judging; every team is different and things might make sense in some circumstances that seem heretic at first glance. Interview your team members: ask them what works well in this team and what does not; ask them for suggestions on what to improve and how. Listen and take notes. It is in this crucial phase that the team will decide whether to trust you or not. (For clarity, if they decide not to trust you, your future in this role is likely compromised.) This is the time for you to be a listener.

Be lucid, though. Regardless of how good you are, you will probably not win everyone over, especially in a pre-existing team. Some will have waited for a change like this to move on; others would have been friends with your predecessor; some may even have wanted your role. In any case, a managerial change, at any level, will trigger some turnover. This is no exception. Be prepared for that change, as you might soon have to recruit.

As you get to know your new colleagues, gauge team maturity. How self-organised are they? How well do they collaborate? How open will they be to change?

When you have heard everyone, decide on a strategy. Whether it is a huge shake-up or minor tweaks in the ways of working, communicate your intentions, the reasons behind them and the objectives you want to achieve. Bring the team on board for the journey. Do not make them passive passengers, as they would have no reason to follow you. Be a federator.

Bear in mind the potential sensitivities of dealing with individuals from various vendors; not all teams are homogenous in that regard, and individuals may be more suspicious of your motives if they are from a competing vendor. Keep the communication channels open, with your team and with whomsoever they report to (engagement manager, account manager, or other). You will have to work closely with the latter when you need to recruit; you may as well nurture that relationship early on. Be a bridge-builder.

And do not rush. If a team could be turned around in hours or days, you would not be needed. Be driven, but patient.

Next time, we will see what you should be doing in the early days.