Who Should Be the ScrumMaster?

Who should be or become the ScrumMaster for your new team? That is, which role: project manager, lead developer, functional manager, or anyone but one of these roles?

Although, understandably, most management wants a standard answer for who they should select to be the ScrumMaster in this new work paradigm, there is not a one-size-fits-all answer. And the reason is because it depends on the person, the team and the environment.

Before I walk through some of the roles, I think it's a good question to ask "Who is deciding who becomes ScrumMaster?" I see management decide often times, but they make the decision without knowing what Scrum is and, more importantly, how it works. The decision on who the ScrumMaster will be does not need to be made months, or even weeks, in advance. I've seen teams decide hours before their sprint begins. If at all possible, take this important decision to the team to see what they think. There needs to be prudence in this, certainly, but I'd rather lean towards making this statement of empowerment and trust of the team from the very start of adopting Scrum.

I commonly see Project Managers given the role of ScrumMaster, but there's a trade-off. What makes a great project manager may not make a great ScrumMaster. In fact, it might be counter. Often, management wants project managers who "get things done." That is, they drive performance. They push the team. They may even micro-manage for results and visibility by tracking every task, status, risk, change and deviation from the plan. And management might love this (or, more truthfully perhaps, love the results). On the other hand, I've also seen Project Managers who provide management what they want (helping get more productivity and more visibility to progress, issues and options) by serving, empowering and trusting the team. If you are currently a Project Manager, which type are you? My experience has been about 50% of project managers are on each side, with very few changing. For some, their "driver" approach impacted the team so badly that management was considering removing the person from the team.

I've seen managers also take on the ScrumMaster role. This, more often then project managers, has negative consequences, only the consequences are not so obvious, but these can be corrected more often and more easily than I've seen with project managers. Some managers, due to their company's culture and expectations, carry the responsibility of getting results from their people (for the projects their people are on). Along with this, many more are expected to make sure their direct reports are busy (that management is getting their money's worth from the employees). For these managers, even if they wanted to embrace the transformative qualities of the ScrumMaster, the company culture will push back, and most often win. For managers in these tough positions, I'd rather see them find someone else to be the ScrumMaster, and then the manager can focus more time and energy towards the bigger need of being a heat shield, organizational impediment remover and management mindset and company cultural change agent. Truthfully, that is the great need and value immediately and long term. For those managers not in culture or carrying those "busyness" mandates, and who have the right attitude towards their role and their team, I have seen great things happen. For these managers, this new role in the business and IT world of ScrumMaster opens new pathways to work with their team, provides new tools to let their people learn and grow, and fosters collaboration between their people. In many ways, this is what these managers were looking for in terms of moving away from needing to make sure things got done (which now the team commits to and owns getting things done), and wanting to focus on growing their people. For those managers wanting some book recommendations specifically for this new "Agile Manager" aspect of their work, take a look at my Agile Management and Leadership book list on Amazon.

My preferred option for whom should be the ScrumMaster is to look to those who are individual contributors (developer, lead developer, business analyst, QA). Ideally, the ScrumMaster is a fulltime role, which has the downside of giving up a fulltime employee. Again, this is contextual. The ScrumMaster will certainly need to be fulltime if the team (and/or company) is starting with agile, or if the project or product that the team is working on is fraught with challenges outside the scope of the basic context taught in my Certified ScrumMaster classes of a "single, co-located, cross-functional team." That is, if there are challenges of having multiple Scrum teams, or using offshore or remote team members, or a larger team, than the need of a ScrumMaster's time and help will be greater. On the other side of the scale, in a simple context, supportive environment, and/or experience ScrumMaster, I've seen the ScrumMaster still do 50% of his or her time doing development (or other tasks) as a player and coach. The biggest trade-off there is that the ScrumMaster needs to know their personal limits on commitment to tasks and stories they take on, as well as balancing personal and team focus. Not easy. 

I'll end with my favorite stories that illustrates what I'm really after when thinking of who should be the ScrumMaster on team. First, I was at a company that was deciding how much to grow their agile adoption. They had one team doing Scrum for six months with great results and a second team had just finished their fourth two-week iteration and was also doing well. The conversation among the executives came to a seemingly trivial point of who the ScrumMaster happened to be on the six month team. When a manager informed the executives that the ScrumMaster also happend to be the most junior developer on the team, there was unanimous appreciation and excitement about how this was exactly what the company wanted for it's culture - that anyone could make very significant contributions! 

My second story is from when I was working with a team that had a working agreement that included rotating the ScrumMaster every two months or so. After finishing their second rotation, at the meeting to decide whom would be next, the team unanimously, and quite noisily, voted to keep their current ScrumMaster. Forever. They loved her and how she helped them. She had grown to love the role and the team as well. And this was a person who was had a fair bit of self-doubt about even trying out the ScrumMaster role the first time, only agreeing to do it because of the guarantee of the ending (surely in failure, she assumed). 

It's stories like these that show how Scrum can help individuals, teams and companies thrive.

Scott recently posted an updated version of this post on the Rocket Nine Solutions blog: http://rocketninesolutions.com/implementing-the-scrummaster/

He also posted a companion piece: Who Should Be the Product Owner, http://rocketninesolutions.com/who-should-be-the-product-owner/

And you can find a video about it on http://rocketninesolutions.com/ as well.
http://youtu.be/4hqywLT0mWM