In my last post I explained the pattern of evolution for a 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 propably 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 and maximum valued products with high quality). There is a close relation between the speed & succes 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 development team members? Should he have technical skills or is he more a people manager?
The answer to these questions are also 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 of implementing the Scrum Master role, organizations often start with one of the members of the development team (maybe he used to be the "team leader"). Since he has proven to be good in organizing stuff, we think that this guy can easily pick up some extra tasks ("how hard can it be to be a Scrum Master, right?"). While his main responsibility is operational work on the Sprint Backlog, being a Scrum Master is something he does in his spare time.
On a day to day basis, the Clerk typically removes a lot of administrative duties from the Development Team (like updating the Sprint Backlog, burndown graphs, preparing the Sprint Planning, etc).
A Clerk has limited benefits, since he is mostly focussed on himself and the inferior values of the Agile manifesto (tools, processes, documentation, etc).
The Puppet Master
The Puppet Master is aware on the values in the manifesto (working software, collaboration, interaction, and embracing change). He understands how the mechanisms in Scrum can help him reach these values.
He tries to pull different strings to make team members move into 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 and artifacts in Scrum, but not really live them.
Since he still supports the team in doing technical work, a Puppet Master often does not have the time to focus on anything but his own Development Team.
Compared to the Clerk and the Puppet Master, the Organizer has managed to make his team aware of the Scrum Values (Commitment, Focus, Openness, Respect, Courage). He has realized that by doing all the complex technical work himself, he actually prevents his team to learn (there is no need for other heroes when you already have Superman).
So instead of beeing Superman, he steps aside. He facilitates that the team can do it themselves (‘We don’t need strings to make the puppets move!’). As a result he can focus on teaching people about Scrum. He makes sure they actually live the values.
The Organizer is focused on making sure that all Scrum events have an optimal result. He also has made time to provide data, so people can start acting on facts instead of gut feeling.
Although the Organizer himself acts with the Scrum Values in mind, his team is still learning. The team still needs his full attention.
A Development team that works with a Coach is able to run Scrum themselves. Sometimes still a little mechanical, but most of the times they really start living the values. As a result he 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 his knowledge, while the Organizer only used this knowledge himself. He doesn’t only listen to his own voice. He is able to empathically listen to others. He is able to make people connect to their passion. He also helps them take action towards this passion. He helps people to find new viewpoints and evolve.
Besides using data to take decisions, the Coach starts to listen to his intuition.
The focus of a Coach gradually shifts from the team towards the rest of the organization. However, he still struggles 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. He succeeded in creating or enabling empowered Scrum teams. As a result of that his focus has now shifted towards the organization. He fixes impediments on the organizational level. He uses data, but he mostly acts on intuition.
The Advisor helps new Scrum Masters with a lower evolution level to grow. He is 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 he might also be the Scrum Master for the integration team).
While he learns 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 and committed. He uses his unconscious competence and intuition to advise and coach others on making decisions. The Expert has a connection with all parts of the organization. He gives advice to managers, HR professionals. He leads the organization towards more Agility. The Expert helps creating new rules & standards.
Some of the Experts are still part of a Scrum team, because they love the atmosphere around there. 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 coach." They show up at events and are often respectable members in 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.