In addition to our regular podcasts, I host a couple lean coffee meetups every month where we get people dropping in who are less experienced yet very curious about Agile methodologies and lean principles. One common theme at these in-person sessions centers around the role of a ScrumMaster, and it’s a topic that engages us old-timers just as much.
Many of us have been serving as ScrumMaster of our teams, but the job description changes for every workplace and every team. For this reason, I trust the responses from my peers; still, we’re often left with more questions than “correct” answers. Here are a few of the questions with some of my observations.
What is a ScrumMaster?
There are many good starts at a definition, but I like Mike Cohn’s for its succinctness:
The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project’s key stakeholder, who is referred to as the product owner.
One key responsibility of the ScrumMaster is to protect the team from outside interruptions, requests that could potentially derail the team’s focus and increase its work in process (WIP). In this way, the SM is like a sheepdog guarding the flock. In fact, Ken Schwaber uses this analogy often, saying it’s the SM’s role to keep the wolves away.
Another aspect to the role is to remove impediments, and the best ScrumMasters are those who have the technical or political know-how to recognize a roadblock early and see that it gets removed. Speed and tact are two skills that they brandish, skills that improve the more they are yielded.
Does a ScrumMaster need to be dedicated to the role 100% of their time?
The saying is that a good ScrumMaster can take on two-to-three teams, but a great ScrumMaster can only handle one. There’s room to have a debate on this question, but my feeling is that if you’re working with only one team and you find yourself with too much idle time, you may not be looking hard enough. Either that, or the team is mature enough to no longer require a full time ScrumMaster.
Michael James, in his erudite article at the Scum Alliance’s site, fairly well states this case. He spells out no fewer than 42 items for a ScrumMaster to keep on her checklist. Incidentally, 42 is the same number on Bernd Schiffer’s similarly excellent post on a ScrumMaster’s job (be sure to check out the comments – GOLD!) Maybe 42 really is the answer to life, the universe and everything.
I find both these lists comprehensive and extremely useful when discussing the work of the ScrumMaster. In fact, I built my own assessment primarily from Bernd’s article. (Merci beaucoup to Fabrice Aimetti for translating the document into french: Evaluation des compétences du Scrum Master.)
If you can honestly say that you’re scoring eights or nines across each of the rows on the assessment, then maybe you are working yourself out of a job. (That is the goal, after all.) It’s likely that your team has benefited to the point that they are mature enough for you to look for another team to lend a helping hand. Which leads nicely to the next question…
Can another member of the team also be an effective SM?
My own opinion is “Sure, why not?” If the team member – and the team – are willing to try it, I wouldn’t discourage this automatically. It ultimately depends on the maturity of the team and the willingness of one contributor to give of himself to serve others. But keep in mind: if the ScrumMaster is committing to work in the sprint, their bandwidth (and motivation) to help clear impediments or pick up other responsibilities (eg. evangelize Agile outside of the team) is at a substantial disadvantage.
I was a coach in an organization that did encourage team members to try their hand at scrummastering (albeit, out of necessity at first). It’s a great way not only to cross train new skills, but also to strengthen the Agile culture within an organization. Just make sure that everyone is on board with the decision – it should never be forced upon a team member. (I still believe that a dedicated SM trumps anyone who is splitting their time with multiple duties.)
Does the ScrumMaster need to be technically proficient with the software stack?
I don’t believe the SM needs be technical at all. They can maintain a “beginner’s mind”. It helps to have someone who is terrifically unbiased in many situations – especially if they’re focused on guarding the process. That eliminates a potential conflict of interest.
On the other hand, some familiarity with the technology can help when clearing impediments. Anticipating the needs of the team based on historical relationships with the ADLC are certainly valuable.
But the argument can be made that being too knowledgeable is bad because then the SM would be tempted to inject herself into discussions of how, and this could lead to (or be interpreted as) dictating to the team what or how to do their work. Smells of micromanagement arise.
Do they need to understand the product inside and out?
Similar to the need to be technically adept, is it important for SMs to be experts on the product they’re delivering? Again, I can see two sides to the debate. On one hand, that’s the role of the Product Owner, and being completely free of bias can prove to be a large advantage for the otherwise engaged ScrumMaster.
However, everywhere I’ve worked as a ScrumMaster or coach, I realized tremendous value in understanding the product at a moderately deep level. It helped (again) anticipate needs for communication and dependencies, and the PO usually appreciated having someone to back her up from time to time.
So, as they say, “try it – you might like it.”
What other characteristics make an effective ScrumMaster?
One of the most powerful traits is courage. Call it “having kajones” or simply “being comfortable in delivering the message”, this skill sets the effective Scrum Master apart from the many who just go “by the book”. However, willingness alone will not get you there; to be most effective you must also possess a large amount of tact. Being able to deliver news without alienating your audience is critical. (As Ken Schwaber reminds us, “a dead sheepdog is a useless sheepdog“.)
So don’t be afraid to step onto the soapbox. It’s not “un-Agile”. In fact, it’s not only appropriate, but demanded. Remember that you’re more empowered than you think.
Situational leadership is a related skill to be mindful of. By speaking up and identifying that the team is off track, you can provide solutions; but always remember that team needs to own them. When team is too dependent on the ScrumMaster, that could be a learning experience. Maybe the SM should walk away and let the team figure out the path out of the woods.
One final characteristic I’ll mention is to be a continual learner. Our landscape is always changing, and we need to keep abreast of the ebbs and flows. By continuously checking our own orientation, we can become more trusted to guide the team through changes and challenges.
Additional Resources
Don’t just take my word for it. As I said, sometimes there are no right answers – that’s why we continue to have the conversations at the lean coffee meetups. And here’s a list of pretty good opinions, well worth checking out to help inform your own opinion:
