Many organizations that embark on the journey to achieve greater agility are soon confused by who ought to play the role of the ScrumMaster, and by the nature
of that role.
Maybe this sounds familiar. If so, you're probably asking:
What are the key expectations for the ScrumMaster role?
What are the typical tasks a ScrumMaster is supposed to do, in concrete terms, to perform the job well?
Is the ScrumMaster's job a full-time one?
Is it a good idea to rotate the job of ScrumMaster among the team members?
Can one person play the roles of both ScrumMaster and product owner?
What's the difference between Agile coaches and ScrumMasters?
Based on my experience as a ScrumMaster, here I'll try to provide answers to all of these questions.
The role of ScrumMaster is a new one, without exact corollaries in the pretransition organization. It is common for an organization that is new to Scrum to struggle to find the appropriate individual for this role.
Scrum is explicit, however, in its clarification of roles and responsibilities. Scrum has only three roles: product owner, ScrumMaster, and team members. Together they cover the responsibilities needed to ensure a successful project.
The ScrumMaster role is unique, and some of its key expectations
The ScrumMaster is a facilitator.
The ScrumMaster is a coach.
The ScrumMaster helps the team remove impediments.
The ScrumMaster should follow the servant-leader style.
The ScrumMaster is the framework custodian.
Everyone seems to immediately grasp that being a team member is a full-time job -- because he or she develops software all day -- and that being a product owner is a full-time job -- because he or she develops the product backlog all day. But it seems far beyond imagination what a ScrumMaster's job really is and why the heck it would be a full-time job too.
In companies that haven't fully transitioned to Agile, there isn't always a clear understanding of what a ScrumMaster really is. In such organizations, the role of ScrumMaster can be a little different from team to team; it can depend on the context.
Maybe those who ask don't know what it is that a ScrumMaster does all day long. This hot topic came up last year during a workshop of one of the local ScrumMaster communities of practice that I was part of. What are the typical tasks a ScrumMaster is supposed to do concretely to perform his or her job well? How much time should a ScrumMaster spend on each task, as a minimum, to make it effective in an average two-week sprint?
We held an hour-and-a-half workshop, and here is a picture summarizing the results of our discussion:
Typical ScrumMaster tasks
In the picture above, considering the evidence of numbers, we could find a real answer to the question, "Is being a ScrumMaster a full-time job?"
Some people tend to think that since the ScrumMaster is "just" a facilitator, the role should be rotated among the team members. They are forgetting that the ScrumMaster is, first of all, a coach. You never see the coach's role get rotated among players on sports teams.
When a ScrumMaster coaches an Agile team, he simultaneously coaches them at two levels: the individual level and the whole-team level. Lyssa Adkins, in her book Coaching Agile Teams
, helps team members better understand their relationship to the work the ScrumMaster does for the team.
The selection of a new Scrum team's ScrumMaster can impact the success or failure of the team's Scrum adoption. Choose the wrong person, and the team could face an uphill struggle in trying to become self-organizing while under the thumb of a command-and-control type of manager. Choose the right person -- matching the skills of the new ScrumMaster with the initial needs of the team -- and the team will have an incredible head start in adopting Scrum.
I'm with Mike Cohn's school of thought: In his book Succeeding with Agile
, he says, "If you want your Scrum team to be the best it can be, I do not recommend that you make a habit of rotating the job of ScrumMaster." Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members, but I don't support this as I don't think it demonstrates an appropriate respect for the challenges and significance of the ScrumMaster role. I think that in our house, we can rotate who can cleans the table after dinner, or who washes the dishes. However, I would not dare rotating who cooks the dinner. I know that if we, as a family, need to eat good food, my wife, the best cook, is the one for that role. Yes, it is possible to rotate the job of ScrumMaster, but, like Mike Cohn, I would recommend doing it only rarely and temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:
Stakeholders don't really understand the duties of the ScrumMaster, and they can start believing that anybody can do it.
Someone who has rotated into the role usually has other non-ScrumMaster tasks to perform during the sprint, and these often take priority.
It's hard to train enough people to do the role well, since particular skills are needed.
Some people will use their time as ScrumMaster to try to push through changes to the process.
Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.
Another less-than-ideal scenario, and a very bad idea, is having one person play the roles of both ScrumMaster and product owner. In that case, the person who is responsible for guarding the team and its process is also responsible for the direction and profitability of the product. While this has even more explicit potential for conflict of interest, the outcome depends on which of those hats is the more dominant. For example, when a ScrumMaster assumes the role of product owner, the lack of someone pushing business priorities can result in technology-focused indulgences or a team pace that is too comfortable. In contrast, a product owner who assumes the role of ScrumMaster can go too far the other way and see this as an opportunity to take direct control of their very own development team, forgoing the technological needs of the project and pushing for an aggressive and possibly unsustainable pace. In both cases, being both product owner and ScrumMaster is also likely to be a big draw on one person's time, leading to possible sacrifices in either their stewardship of the team or in having up-to-date information on the product.
Another confusion is about the difference between Agile coach and ScrumMaster roles. Both roles are tasked with helping Agile teams use Agile values and practices to deliver value to the organization. Agile coaches and ScrumMasters use similar techniques to guide, facilitate, and coach teams so that they learn and use Agile techniques, confront delivery problems as they occur, and work together as a well-oiled unit. If we stopped here, the two roles would be the same.
However, the scope of the two roles is different. Agile coaches typically pursue the implementation of an organizational vision of Agile, or are tasked with delivering external knowledge and expertise to a team. In either case, the coach is external and is not a member of any specific project team. In order to effect change from outside the project, the coach needs a broader exposure to Agile roles than a typical ScrumMaster. A coach should have played all the roles on an Agile team multiple times. They have the gravitas to influence without direct authority, and from outside the team. They interact with a team (or teams) and then let the team synthesize and internalize the advice. The ScrumMaster, on the other hand, is the Scrum team's tactical coach.
The Agile coach is typically the voice of Agile at the organizational level. This generally requires broader exposure and experience with Agile techniques. The need for an Agile coach is generally transitory; specifically, they are needed when external injections of knowledge or energy are necessary to help ensure the application of Agile as it continues to evolve. ScrumMasters are the voice of the Scrum framework at the team level. The ScrumMaster is a critical member of every Agile team. The team's need for a ScrumMaster is not transitory, because the ScrumMaster and the team evolve together. The role of an Agile coach and that of a ScrumMaster have similarities, but also significant differences.
In this article I have tried to provide some clarification about wrong assumptions about the nature
of the ScrumMaster role. The role is a new one without exact corollaries in the pretransition organization. It is common for an organization that is new to Scrum to struggle to designate the appropriate individual.
Some people tend to think that a ScrumMaster is just a facilitator, but they basically ignore that a ScrumMaster is, first of all, a coach.
References and suggested resources