There are as many definitions of ScrumMaster as there are authors to define it. While there is a lot to learn from all this literature, it is remarkable that there are so many inconsistent definitions of the role.
The variations in the role description mainly arise from Scrumbut environments.
A ScrumBut (or Scrum-But) is any divergence to the way the Scrum framework was supposed to be implemented, either by extending the basic principles or by shortening them (and hence missing some important points). Usually these ScrumButs are seen as necessary or, worse, as acceptable variations of the whole framework. But this is, in my experience, rarely the case. In this article I describe main problems with some ScrumMaster role assumptions.
ScrumMasters could tend to be one of the following:
- Project Managers seeking a better way to manage projects
- Team Leaders/Managers seeking better ways to manage people
- Tech Leads thrown into a role they don’t understand
- Rare individuals with coaching and counseling skills
I believe that the first three types are not useful, not even in the short term. The fourth type, the ScrumMaster acting as coach, has merit. This type of ScrumMaster can help an organization and take steps for positive change. People fitting this fourth type are, sadly, few and are the exception that proves the rule. I believe that, when the ScrumMaster role is not correctly interpreted can risk doing damages to our companies than aiding them to change.
The ScrumMaster role is often abused but I consider it one of the valuable options for organizations. The option that may end in preservation of status quo, but also in creating a space for people who will take the organization to the next level [Ref.1].
Even in Agile mature organizations I see the ScrumMaster role as means that can create space for change agents and catalyze improvements.
I keep hearing things like ”The goal of a Scrum Master/Coach is to make himself unneeded” or ”For a mature team, we can do with a part-time or without a Scrum Master/Coach”. None of these make any sense to me.
People, including most newly assigned Scrum Masters, do not know what to expect from such a role. What value does it add?
Commonly this also leads to the Scrum Master role being implemented as some sort of mix between a meeting booking secretary and a command and control rule enforcer.
But that is completely not the point of having such person assisting a team and an organization [Ref.2], when not correctly interpreting the role.
A ScrumMaster is not a Project Manager
Scrum is often classified as Agile’s ‘project management’ method and yet looks incompatible with the traditional Project Manager role. The Scrum framework defines only three roles: Scrum Master, Development Team and Product Owner. Many of the responsibilities of the traditional Project Manager are covered by these other roles; below I’ve listed some of them [Ref.3]:
- Framework focus (Scrum Master)
- Task allocation (Development Team)
- Managing issues and dependencies (Scrum Master/Product Owner)
- Requirements prioritisation (Product Owner)
- Procurement (Product Owner)
- Risk management (everyone, via daily meetings, sprint planning, reviews and retrospectives)
So, given this is all covered, is there any value in assigning a Project Manager to the team?
Contrary to popular belief, the ScrumMaster and Project Manager roles are highly different and shouldn't be confused. As more companies migrate their project management to Agile, many do so without a proper understanding of what they're aiming for. In particular, there are incorrect assumptions made about the roles in Agile; people often expect that the shift from Waterfall practices includes a wholesale shift of roles. The ScrumMaster, however, does not play the part of the traditional Project manager. In fact, the ScrumMaster is an entirely new role [Ref.4].
The ScrumMaster doesn't manage the team that produces the work; instead, he supports the Product Owner, coaches the team, and makes sure that Scrum framework is adhered to. The ScrumMaster is responsible for the Scrum framework, its correct and continuous implementation, and the maximization of its benefits.
ScrumMasters can come from project management, but that's not a guaranteed fit. Business analysts and team members can also fit the role.
A lot of traditional Project Managers (PMs) struggle with the transition because it means stepping away from a highly structured position: one with them at the helm, steering the development and the team toward a predefined specification. The often overwhelming change controls imposed in traditional Waterfall approaches are no longer there to protect the PM from the risks associated with change. Gone is the overanalyzing, form-filling approach to change. The product owner often now has to deal with change on a daily basis. Those changes aren't always big shifts, but the decisions made to include them can have a big effect on the end product. Being able to make those decisions is important to the flow of the project, and a product definition may change massively from what it looked like at the beginning. In fact, a product doesn't even need to be fully defined at the outset of an Agile project.
A ScrumMaster is not a Team Leader
Team Leader and ScrumMaster roles are very different [Ref.5]. The SM role assumes a way of leading people without having formal authority over them. The SM resorts to setting a shared vision, involving everyone in the decisions, coaching the team and the individuals and works with the rest of the company to remove impediments.
This leads to a quite different team dynamic.
Because there is no longer a central decision point, all team members are asked to contribute equally. The increased motivation and responsibility lead to better results which, in turn, increase the trust and management’s willingness to treat the team as a whole.
Every Team Leader is different, and his responsibilities, as assigned by management are different. The role is rooted in command and control thinking. Unfortunately, having a team leader reduces team involvement. Here are the main ones I’ve seen:
- Assign tasks
- Make technical decisions
- Provide estimates to management
- Talk to outside people
When transitioning to Scrum, task assignment and providing estimates become team responsibilities. Talking to outside people is done both by the SM (for removing impediments) and the team (everything else). The only question left is who makes technical decisions.
Scrum team members should have an equal say when it comes to technical aspects. While I agree with it as an ideal, my experience was that even in agile teams one or two technical leaders emerge. Everyone else defers to their judgement and experience when it comes to tricky technical problems. I am fine with that. My only request is that they dedicate a big chunk of their time to coach the other team members and thus grow the collective knowledge.
There are teams, particularly in software development, who find it difficult to differentiate between the ScrumMaster and the Team Leader. Often a team needs a development lead that has particular skills and experience and is able to manage the team and make its decisions. This is not a ScrumMaster role. It's up to the team to lead itself, with a collective togetherness.
This leads some to think that the ScrumMaster role is not required — but that's not the case. The roles are entirely different. The ScrumMaster is there to facilitate, coach, and provide support.
In conclusion, the Team Leader role is not needed in Scrum. For teams that currently have this role and are transitioning to Scrum, the ScrumMaster should use various techniques to get everyone involved.
A ScrumMaster is not overhead
It’s always interesting to me when I hear ScrumMasters referred to as overhead [Ref.6].
To pay for a person that does not add any tangible value to the product seems unnecessary. It is my ambition to share my experience of the real value a ScrumMaster can add to a software product development.
The concept of servant leadership (described in ScrumMaster 2.0) is a wonderful one. Servant leadership requires humility and stillness, not the busy-ness we could see in some ScrumMasters or Agile Coaches, with their plethora of software tools, spreadsheets, charts, metrics, sticky notes, and schedules, attempting to “master the Scrum framework”.
Some people could ask “What’s the ScrumMasters value?” or “Do we really need a ScrumMaster?” I understand these questions. They are effectively valid questions to ask about every role in an organization. They are especially valid questions to ask about ScrumMasters when you’re not, well, Agile.
I would challenge those who might be asking these questions to first ask “Do we really want to be an Agile organization”? If the answer is “yes”, then ask what needs to be true in order for you to realize the full benefit of your ScrumMasters?
ScrumMasters as coaches help people learn and grow in and beyond their role professionally and, sometimes, personally. They see things that most cannot see anymore and they can question them safely.
The actual idea with Scrum Masters
What a Scrum Master/Coach brings is another focus and another perspective, compared to other team members. For example, it is very hard to be focused on the details and on the big picture at the same time.
For instance pair programming gurus recommend that the ”driver” focuses on the details and the ”co-pilot” focuses on the big picture. Similarly the Scrum framework has different roles, to give each person fewer things to primarily focus on.
For example, deep in the code, you will also probably not be thinking about how to effectively reworking the organizational structures that are impeding improvements and thus slowly killing your organization.
That is one of the reasons that we have ScrumMasters. They have to facilitate positive changes and improvements. They have to do this since it is their primary focus.
Besides you need in each team someone who:
- Takes care about team and its ability to deliver value
- Is committed to continuous improvement
- Is open to think and act in a different way
- Takes care about the efficiency of your systems
- Believes in what you’re trying to achieve through Agile (notice I did not say “believe in Agile”)
- Takes care about team strategic competencies
- Makes every effort to promote and assist team harmony
- Have a blind spot when it comes to titles, age, gender or former role – think about the person and NOT the org chart
- Is able to get over himself
- What else? (I could continue but…. I’m a ScrumMaster)
But how about mature teams? Couldn’t they work well together without a ScrumMaster?
Well, I have never seen anybody, regardless of skill level, successfully facilitating a meeting where they also tried to participate. With that approach, less great decisions will be made and team health will suffer in the long run.
What about for the problem solving part? For a mature agile team the low hanging fruits have already been picked. The remaining issues are probably deep entrenched in individual habits and organizational culture.
Big problems require even more time and focus. But when progress is being made, payback can be equally large.
And if you think that things are working fine in your team, remember: This does not mean that you have no problems; it just means that you are clueless.
What Organizations need to do?
Should all organizations invest in a 100% ScrumMaster for each team then? Or is it a 80% job, or a 50% job? Well that depends doesn’t it? It depends on how much value the ScrumMaster adds to the team and to the organization.
If the organization is able to produce significantly more value with some person being a full time ScrumMaster (as described in Playing the ScrumMaster role) for one team compared to with the same person splitting his time between two teams, then keeping that person focused on one team seems like a good idea, doesn’t it?
You will just have to evaluate this. Just as with all changes in the complex adaptive systems that are our organizations. There are no one-size-fits-all recipes you can follow.
What organizations need to learn is not how to follow some ”Agile recipe”. Organizations need to learn how to learn. That is, how to come up with experiments and how to evaluate if those experiments improved things or not (see also PDSA model) [Ref.7].
And if you happen to be a ScrumMaster, to make this happen is your job! And it is a pretty challenging one [Ref.2].
I’ve been a ScrumMaster and practitioner for a while and it seems I’m nowhere near being fully trained for the job anytime soon.
Everyday there is something new to learn.
If you are like me, and want to pick up the speed of your learning journey, there are lots of things you could do.
Like reading some more books. Working with other ScrumMasters in your organization. Developing and improving your coaching skills. Attending some trainings and conferences. Visiting a local user group. Doing some more experiments at work. Learning in any way you like and making sure that your role is a value adding position.