Much of the role of the Scrum Master is intangible. We don’t write elegant code, we don’t craft beautiful designs, and we better not be creating Gantt charts. Instead, we’re masters at soft skills, but how can such a thing be quantified? And if not quantified, how can I know if I’m a good Scrum Master? How can I honestly assess myself in the spirit of continuous improvement? With respect to a Scrum Master’s service to a team, it begins by asking six questions.
- Am I valuing outcomes over outputs? I hope so. Let me explain the difference. An output is a sprint backlog. An outcome is a customer pleased with our latest deploy. In this case, our output (the sprint backlog) led to a positive outcome (a pleased customer), but that won’t always occur. Do we talk often of what we’re about to accomplish, but it never seems to come to fruition? Or can the team tell stories about how and where we contributed to the team’s success or helped them learn a valuable lesson? It’s the latter that we want.
- How does the team look different than it did 4 to 8 sprints ago? I don’t mean do the teams have different team members, or are they doing different work. I mean how are they interacting? How do the things they do differ then versus now? Has the team adopted any new engineering practices? Lean and XP are great places to look for inspiration. After all, we should be inspiring a culture of experimentation and always challenging the status quo. Doing so encourages learning, and fostering a learning mindset is one of our primary responsibilities.
- What data interests the team? Data can be dangerous in the wrong hands, but if used wisely, it can greatly benefit the team. (Check out An Appropriate use of Metrics by Martin Fowler for an explanation.) Have we sought and encouraged useful metrics that interest and benefit the team? We’re not talking about a burn down chart, which is largely a vanity metric. While useful, that’s just scratching the surface. We’re talking about things like cycle time, team or customer happiness, and many more. I cover more ground on this topic here, here, and especially here.
- Does the team see me as an asset or impediment? I’ll admit. I sometimes get in the way of my teams. The culprit is usually the same:
It’s better to go slow in the right direction than fast in the wrong direction.
When I get in the way of teams, I’ll take as much time as necessary to explain why. This why makes the difference between being viewed as an asset or an impediment. In fact, let’s talk more about why in our next question.
- Can I explain why? Talking about what we do is easy. It’s why we do what we do that’s interesting. Knowing why helps us find new and innovative ways of working. In fact, I explain my own whys for each Scrum event here. However, it doesn’t stop at the whys for events. Why estimate? Why groom a backlog at all? Why do we need to work as a cross-functional team when I can’t understand a damn thing the designer is talking about? We should be prepared for these questions and more.
- How much of my work does the team do? I’ve said it often, but I’ll say it again:
Every Scrum Master should always be trying to put him or herself out of a job.
Am I facilitating all the events? Am I removing all the impediments? Am I chasing down information for the team? I certainly hope not. Instead, we should be looking for ways to nudge the team to do so. Take a two-week vacation and don’t answer any emails. How’d the teams do in our absence? My point is this. Never derive value from feeling needed. It should be derived by imbuing in others the mindset that good enough never is.
After answering these six questions, do you think you’re a good Scrum Master? What additional questions would you ask yourself as you introspect? Finally, thanks for stopping by and thanks to Manjari for inspiring me to think through this topic. Until next time.
Update: Learn how to progressively hand over Scrum Master responsibilities to the team in this blog post titled Mastering the Art of Actively Doing Nothing.
Do you want to get notified when new posts are published? Leave your email below.