Growing in a Scrum Master Roles and Duties, Evolution of a Scrum Master
Evolution of Scrum Master Role
What does one need to become a good Scrum Master? How can you grow in this role of yours? This article will help you find your way through all the stages of one’s evolutional development as a Scrum Master.
Not all companies striving to integrate Scrum in their working processes manage to benefit from it — i.e., receive high-quality output product with maximum business value — and, as a result of that, make the stakeholders satisfied. There are reasons to opine that the success rate and the swiftness of Scrum implementation are directly related to the competence level of the Scrum Master.
Who, then, would be the perfect candidate to fill in Scrum Master role? Would that be the Project Manager, the Team Lead, or anyone of the Developers Team? Should he only possess the corresponding technical skills or should he, first and foremost, be a good manager of his team?
The more mature Scrum Master becomes, the higher is the potential benefit which he provides to his organisation. Each new version is an enhancement of the version preceding it and comprises all of the quality of its precedent.
All Scrum Master roles and Scrum Master duties will be described below.
An Office Worker
Quite often, in the early days of the Scrum Master’s role introduction, the organisation usually selects one of the participants of the Developers Team with experience, say, Team Lead. Since he has proven himself to be a success in certain human resources management matters, this apparently points to the fact that this guy might as well cope with a range of additional assignments.
Day in, day out, an Office Worker accomplishes a number of administrative assignments; one should not expect much of him, considering the fact that an Office Worker is, by and large, focused on his primary responsibilities and on the right section of the Agile Manifesto (instruments, processes, documentation and suchlike).
A Supervisor is aware of the values reflected in the Manifesto (a working software product, collaboration, interaction, and willingness to implement changes). He understands how the Scrum mechanisms can assist him in the achievement of these values.
He is the one ensuring that each and every member of the team is in compliance with Scrum rules. Quite often, this requires mechanical implementation; this is the case when a team has all of the necessary Scrum events, roles, and artefacts—but the team fails to accept them—hence, they do not operate in Scrum spirit.
Given that a Supervisor is, in fact, providing support to the team as the team is executing technical assignments, he — quite often, actually — does not have enough time to concentrate on anything else, except on his Development Team.
Unlike an office worker and unlike the supervisor, an Organiser has succeeded in effectively delivering and implanting the Scrum values (loyalty, focus, openness, respect, and bravery) into his team. He is aware of the fact that, had he decided to implement the entire set of technical assignments on his own, he would have failed to give his team an opportunity to learn.
Unlike the Supervisor, an Organiser strives to do everything he can to enable the team to accomplish their work on their own. An Organiser teaches his team the basics of self-organisation and encourages judgment calls on how to approach the accomplishment of a certain task. In addition to the above, he sometimes also lets his team fail. He is aware of the importance and of a lesson learned through the experience of a failure and knows that his subordinates will also value it, as they rise again after a fall.
As a result, he does everything he can to ensure that people live by the Scrum values. An Organiser also registers the metrics (statistical data) so that people are able to act by referring to facts and not to intuition. An Organiser is acting pursuant to the Scrum values — his team, though, is still learning these values and is thus in need of his constant attention.
The Team of Developers that have a Trainer is able to work in Scrum on their own. Sometimes, a mechanical mode is required — by and large, however, the team starts to really live by the values. As a result, a Trainer comes into possession of a sufficient amount of resources enabling him to focus on the Product Owner and stakeholders, management etc.
A Trainer is able to influence others whereas an Organiser is only applying his knowledge to himself. Developing self-organisation skills is one of the most important tasks of a Trainer. The self-organised team is making judgment calls on their own as they decide how to transform the elements of the Product Backlog into Increment. Everyday Scrum can also be taking place without the presence of a Trainer — provided that the Team of Developers understand the significance and the purpose of the event and provided that they cope well on their own.
By and large, a Trainer is able to bridge the gap between deliberations on «how can we do this» and the actual «doing of this». He also knows how to help his team members to understand themselves in order to unleash their potential — that is, he can captivate people’s attention and communicate ideas to them. A Trainer can take the first steps in the chosen direction; he can also discover new standpoints and opinions and develop them further.
If a complicated situation arises, he helps his team members find a solution, whereas he himself always stays calm. In addition to usage of metrics to take decisions, a Trainer is prone to listen to his own intuition, too. Gradually, his focus shifts from the team towards the organisation. He, however, is not always successful in finding common ground with the management and with other departments.
A Consultant used to be the team’s trainer in the past and, as he was fulfilling this role he managed to launch successful Scrum teams. He succeeded in getting the desired results and now the team does not need his assistance on a regular basis. The team is, however, in need of his council from time to time, in certain situations. In this particular case, the Consultant is not so much a Trainer as he is a Mentor.
His focus, therefore, has shifted towards organisation. He eliminates barriers on the level of the organisation; he can, also, prevent these barriers from even appearing in the first place. A Consultant helps new Scrum Masters grow. Quite often, managers seek his assistance, asking him to help them resolve complex issues. In an organisation with complex and large scale products, a Consultant fulfills the Scrum Master duties for a number of Scrum teams. He, however, still fails to make the organisation more flexible to the full extend.
A Scrum Guru is a super-competent individual, committed to the ideas of Scrum. He does, however, realise at the same time that Scrum is not the limit. He is also competent in Kanban, Lean, XP. He knows the strong and weak points of each framework. He also applies his intuition to consult/coach the others as they are making their decisions.
A Guru can operate in any segment of the organisation. He provides advice to managers, HR specialists; he steers the organisation towards greater flexibility. A Guru helps create new rules and standards in the company. Certain Guru still remains participants of a Scrum Team: such teams become exemplary role model teams for other teams within the organisation. Guru like to call themselves Agile Coaches.
Quite often, they are respectable members of the experts’ associations and they also share the experience not only with their colleagues from the organisation in the course of conversations but also with other specialists outside the organisation — say, during conferences, seminars and so on. Regretfully, there are many organisations that fail to completely grasp the importance and the value of such Gurus, or fail to motivate them. If they leave the workplace, it is a great challenge to fill in the vacuum which they have left behind.