Tuesday, July 10, 2012

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


10 comments:

Anonymous said...

I'm a big fan of Agile, but your article about how to pick an effective ScrumMaster didn't work for me. ScrumMasters do need to be good at getting things done, they just need to do it a lot differently than the old fashioned whip-cracking PM. As far as providing insight on what to look for, the post was pretty much useless.

Ninna said...

I'm not sure I agree with the previous post. Isn't the point that there is no right answer for what constitutes a good ScrumMaster? The method for finding one is to identify the individual that the team "peaks" with, e.g. empower the team to make the decision. Or did I get it wrong?

Miguel Sousa said...

I agree with Ninna. In SCRUM teams should be empowered. You should not say them how to do it, but point them the direction you want them to go and where to reach!
They should decide how to achieve the objective and in this line of thought, they can (for sure) also define they ScrumMaster...
... my 5 cents!

DonM said...

Scott, I agree with your observations 100%. I have managed several agile projects and found that a good SM is a rare breed of manager. The role of the SM is more of a Risk Manager then a PM. This allows the SM to focus on facilitating the scrum process; and the team can focus on the work at hand and the PM can focus on clearing impedements. On the teams that I managed this resposibility was shared with each team memeber (only if they wanted to). When acting as the SM, that person wore only the SM hat and did not participate in their normal team role, unless it was critical that they participated in the discssion and it was clear that they were NOT wearing the "SM hat" at that time. This also helped prevent the overbearing PM from running the show and really opened up communication in our scrum meetings. As for selection, the SM will become apparent by his/her leadership skills and clearly stand out.

Anonymous said...

Mark Cohn states that a great ScrumMaster should have the following attributes, Humble, Collaborative, Committed, Influential, Knowledgeable, and Responsible. Therefore, I believe if the ScrumMaster has the tools, training, and also developed their skills as a change agent anyone can become a great ScrumMaster. I also believe having ScrumMasters at every level will strengthen an agile organization.

Leyts said...

Zero stars for this. Shaking my head about these organizations; if they even actually exist.

Scott Dunn said...

Anonymous and Miguel, thank you both for your comments. My point isn't to look to traditional roles, my point was to share my observations for those companies who do need to decide which role (given that they aren't doing it on a per-person or team basis). And this might be just (or at least) a starting point. Some companies would open up a big issue by "cherry picking" people for this role, rather than a standard approach. Many large adoptions need to quickly pick out 8 or 20 ScrumMasters weeks or months before their big agile kickoff, and the outside agile coaches aren't even there yet.

Ninna, I agree with you. There is no right answer except what works for the team. I do look for Servant Leadership, get-things-done Impediment remover, Coach and mentoring heart, Educator and evangelist's passion (these spell out S.L.I.C.E.)

DonM, thank you for your comment. I like the hat clarity and the Risk Manager insight.

Leyts, thanks for sharing, and I ask you to consider that these are companies are precisely the ones who need our help the most. They don't get better on their own (at least, not very well).

Unknown said...

Hello Scott. Thank you for the piece, it provides a great insight for outsiders like me. I need an advice:

I am a telecom engineer with little over two years of experience in my field. I recently got an offer from a software house for the position of Scrum Master. They have offered me the certification course and then a permanent role with the organization. Meanwhile I'm asked to read about this concept.

I have tried to comprehend through internet as much as I could, but I'm still confused whether or not it's a good career move. Can you help and assist? What's the future of this type of job? Will I be pigeonholed for life?

Your response would be appreciated.

Unknown said...

I need to discuss something in detail with you, about which I scarcely mentioned earlier.

I am telecom engineer with little over two years of experience in my field. I recently got an offer from a software house for the position of Scrum Master. Meanwhile I'm asked to read about this concept.

I have tried to comprehend through internet as much as I could, but I'm still confused whether or not it's a good career move. Can you help and assist? What's the future of this type of job? Will I be pigeonholed for life? Where will I be after, say, 5 years?

Unknown said...

I am working professional and have good real project implementation exp. of scrum process.

I want take CSM certification, its possible for direct take certification of CSM.