A Scrum Master mentoring experiment

In the Agile Tour Montreal 2020 I had the pleasure of introducing the model I have been using to up-skill Scrum Masters with 100% of success. It is a model based on mentoring and discovery, creating awareness about the many facets of the Scrum Master role. I was pleased once the new Scrum Guide came out in 2020 just two days before my workshop. In my personal reading, the accountabilities set for the Scrum Master are even more aligned with this work.

This is going to be a rather long post, so grab some coffee to join the ride!

Intention

A mentoring program to elevate the role of Scrum Master to its real purpose and accountability.

It is not uncommon to see companies asking for a Scrum Master but in reality, expecting the professionals in that role to basically become a delivery lead: someone that organizes and guarantees that software output is happening as often as possible. While this is a valid piece of intention, this is NOT what the role of Scrum Master is about. This role is a very clear accountability described in the Scrum guide: A Scrum Master is responsible for the effectiveness of a team. Therefore, for us to have a Scrum Master:

  • We have to have a team. Not a project or "resources" bundled together, but a team;

  • We have to be running Scrum or any Scrum-based framework. Asking for detailed requirements followed by development and then test cycles, meeting up for status review at the end of every two weeks is NOT doing Scrum;

  • The Scrum Master is not a commander, telling the team what to do, but is a key influential figure within the team.

A Scrum Master is a team enabler first and foremost, someone who helps a group of people to self-organize around a common mission for quality and value delivery. It is also an agility enabler for the organization, helping to remove bureaucracy and heaviness on processes beyond the team. In companies that either hire or consult with Agile coaches it is imperative that the Scrum Masters become the first line of partnership with coaches. As an Agile Coach I am rather limited to my scope within an organization, unless the Scrum Masters, whose accountability lies within teams and processes, comes into play as well.

The intention was then, for individuals and for companies, to

  • Create awareness of what the role really is, once and for all. Elevate the Scrum Masters from the front line of delivery to the center of work effectiveness.

  • Generate an agreement of this role elevation between Scrum Masters and their leads.

  • Give the Scrum Master a space to learn and discover; sometimes discover what they already know!, and most importantly, to share among their group, not only their thoughts, but some of the practices they put into place.

After running a few individual pilots, I then came up with a format for groups of Scrum Masters, trying to replicate the success I was having with one-on-one coaching.

Format

Small groups, running together for a given period of time. This was designed for creating a sense of confidentiality and intimacy, to give space for the growth of a community among the members of the program. In a smaller group there is more space for lengthy sharing and for silence. Meeting regularly as opposed to a big-bang two or three days is a lot easier on the brain and for letting people try things in between meetups. Also, those "two full days meetups" are usually too intense and become more training than actual mentoring. They create a lot of excitement, but a lot of the discovery fades away quickly.

In a nutshell, the format was:

  • Meeting for a kickoff;

  • Meeting for 8 sessions of 3 hours each (why 8 sessions? Resources will explain it below);

  • Groups of no less than four and no more than six scrum masters;

  • Two or three facilitators.

Resources

The agile community is constantly creating fantastic knowledge and we all build on top of each other's work. That is how we can all advance through experimentation and adapting, instead of reinventing a lot of things.

Four resources I had used a lot for the past four years just came together to create the mentoring program I put in place. They are the following: for context, the SM Clinics; for content, the 8 stances of the Scrum Master; for structure Training from the back of the room and Liberating Structures.

The 8 stances of the SM

The heart of the concept, I came across this material at some point in 2017 and had used it in my own coaching practice and I was really impressed on how simple the proposition by Barry Overeem is.

Despite the fact that he has his own definition for the 8 stances and that your very own view might differ a little bit, I think his work is just fantastic as a Scrum Master workbook. The stances are:

  • Teacher

  • Mentor

  • Coach

  • Manager

  • Impediment Remover

  • Servant Leader

  • Change Agent

  • Facilitator

In the mentoring program, each stance became a session. We had 3 hours to invest in discovering the why's and the how's of each.

My contribution

Once I was familiar with coaching with the 8 stances as a base framework I eventually proposed an organized navigation through the stances. What became clear from my practice was the natural fit of the Shu-Ha-Ri in the 8 stances and in the overall Scrum Master practice.


the 8 stances of the Scrum Master in shu-ha-ri
the 8 stances of the Scrum Master in shu-ha-ri

Here is how I approached them:

SHU: Teacher and Facilitator

Fundamental, but not basic, a scrum master should master, if anything these two aspects of the role. Teaching Scrum specifically, but Agile in general. And facilitation as the art of amplifying voices, structuring interactions, help people navigate conflict and making sure objectives are met. There is a lot of room for personal expression in the practice of teaching and facilitating, but also a lot of "by-the-book": we will not coin yet another 12 principles of Agile or imagine different Scrum values. A lot of the basic has to stay "as is" and this is not limiting, but rather structural, to ground the practice.

HA: Mentor, Manager and Impediment Remover

For the layer in which we start to expand from the rules, borrow from Lean, Management 3.0 and many other disciplines, I felt that these 3 belonged in here. As a mentor, the relationship of once a teacher evolves into sharing experience and giving perspective. A manager, managing systems, not people also felt at home together with the removal of impediments: we learn to see beyond the obvious and treat everything as experiments, with a why and a how and we measure progress. I would say that even seasoned Scrum Masters still spend a lot of their time perfecting this part of their practice because theses stances can get as different as there are teams and the techniques that we put in place need constant fine tuning.