In my last post, I explained the pattern of the evolution of the Product Owner. This blog is about the evolution pattern of a Scrum Master.
Do you want to know more about what it takes to be a good Scrum Master? Would you like to know how to grow in your role? Then you should probably keep reading.
In the last 10 years, I have helped a number of organizations to implement Scrum.
For a lot of these organizations, the Scrum implementation either takes a long time or they never reach the real benefits of Scrum (happy stakeholders & maximum valued products with high quality). There is a close relationship between the speed & success of the Scrum implementation and the maturity of the Scrum Master role.
So who is the perfect person for this role? Is it a (project) manager, a team leader, or maybe one of the Scrum Team members? Should they have technical skills or be more of a people manager?
The answer to these questions is not simple. These answers are hidden in the way many of these organizations have implemented the Scrum Master role. Another pattern appears that describes the evolution of the Scrum Master:
The more mature the Scrum Master becomes, the higher the expected benefits. Each of the versions in the graph is an upgrade of its predecessor and incorporates all qualities of the previous version:
As a first attempt at implementing the Scrum Master role, organizations often start with one of the members of the Scrum Team (maybe he used to be the 'team leader'). Since they have proven to be good at organizing stuff, we think that this person can easily pick up some extra tasks ('how hard can it be to be a Scrum Master, right?'). While their main responsibility is operational work on the Sprint Backlog, being a Scrum Master is something they do in their spare time.
On a day to day basis, the Clerk typically removes a lot of administrative duties from the Developers (like updating the Sprint Backlog, burndown graphs, preparing the Sprint Planning, etc).
A Clerk has limited benefits since they are mostly focussed on themselves & the inferior values of the Agile manifesto (tools, processes, documentation, etc).
The Puppet Master
The Puppet Master is aware of the values in the manifesto (working software, collaboration, interaction & embracing change). They understand how the mechanisms in Scrum can help with reaching these values.
They try to pull different strings to make team members move in the right direction: everyone in the team needs to follow the Scrum rules by the book. This often results in a very mechanical Scrum implementation, where people do all the events, roles & artifacts in Scrum, but not really live them.
Since this sort of Scrum Master still supports the team in doing technical work, a Puppet Master often does not have the time to focus on anything but their own Scrum Team.
Compared to the Clerk & the Puppet Master, the Organizer has managed to make their team aware of the Scrum Values (Commitment, Focus, Openness, Respect & Courage). They has realized that by doing all the complex technical work themselves, they actually prevent the team from learning (there is no need for other heroes when you already have Superman).
So instead of being Superman, they step aside. He/she facilitates that the team can do it themselves ('We don't need strings to make the puppets move!'). As a result, this type of Scrum Master can focus on teaching people about Scrum.
They make sure they actually live the values.
The Organizer is focused on making sure that all Scrum events have an optimal result. They also make time to provide data, so people can start acting on facts instead of gut feeling.
Although the Organizer acts with the Scrum Values in mind, their team is still learning. The team still needs the Scrum Master's full attention.
A Scrum Team that works with a Coach is able to run Scrum themselves. Sometimes still a little mechanical, but most of the time they really start living the values. As a result, the Scrum Master has enough room to also focus on the Product Owner and the environment around the team (stakeholders, management, etc).
The Coach is able to impact others with their knowledge, while the Organizer only used this knowledge themselves. He/she doesn't only listen to their own voice. They are able to empathically listen to others. They are able to make people connect to their passion and take action towards that goal. He/she helps people to find new viewpoints & evolve.
Besides using data to make decisions, the Coach starts to listen to their intuition.
The focus of a Coach gradually shifts from the team towards the rest of the organization. However, they still struggle to find solid ground with management & other parts of the organization (marketing, sales, operations, you name it...).
The Advisor has acted as a Coach for more teams in the past. They succeeded in creating\enabling empowered Scrum Teams. As a result their focus has now shifted towards the organisation. They fixe impediments on the organizational level. They use data, but mostly they act on intuition.
The Advisor helps new Scrum Masters with a lower evolution level to grow. They are often asked by managers to help them fix difficult issues.
In an organization with complex, large products, the Advisor is typically the Scrum Master for a number of scaled Scrum teams (in a Nexus they might also be the Scrum Master for the Nexus Integration Team).
While they learn a lot about the organizational dynamics the Advisor still struggles in making organizations more responsive as a whole.
The Expert Scrum Master is highly competent & committed. They use their unconscious competence and intuition to advise\coach others on making decisions. The Expert has a connection with all parts of the organization. They give advice to managers and HR professionals. They lead the organization towards agility. The Expert helps in creating new rules & standards.
Some of the Experts are still part of a Scrum Team, because they love the atmosphere of being part of a team. These teams are often high performing, skilled, and an example for the other teams in the organization.
Experts in an Agile organization often call themselves 'Agile coaches'. They show up at events and are often respectable members of a community of Experts.
Unfortunately, many organizations do not recognize these Experts or don't understand how to keep them motivated. If they eventually leave, it will be a hard job to fill the vacuum they leave behind.
If you would like to use the personas described in a workshop, you can download them here
Want to know about the evolution of the Developer, Product Owner and the Agile manager? Keep reading the upcoming blog posts, there is more to come!!