Being a Scrummaster in today’s tech is a tricky proposition. In a lot of ways, you’re forced to become a sort of car salesman, using various techniques to convince someone to do something as the role itself generally lacks any type of authority in the traditional sense. Gone are the days of being able to use the tricks Mom and Dad got to use when you were a kid. “Because I said so” doesn’t fly as you have no reportables and you aren’t a people manager. Compound this with the fact that being a Scrummaster means that you are basically told (by way of the scrum manifesto or whatever home-grown version of Agile you may have) what needs to be done (eg. stand-up, retro, etc) but you aren’t given clear directions on how to do it. These two things lead to what I feel is a bit of an epidemic, an inescapable feeling of ‘what am I actually bringing to the table’ or ‘I’m a fraud, anyone could do this’.
Now, I think there is an argument that could be made that yes, anyone can be a scrummaster (any role where you take PTO and literally anyone can fill in for you does feel bad, skilled labor this is not) BUT being a good scrummaster takes a special kind of individual. Before that can happen, you have to look past those feelings of insecurity, past the impostor syndrome, and realize you can bring so much more to the table than you think.
The first piece of advice I’d offer anyone feeling this way is to simply acknowledge that you are, more than likely, not alone. There are at any time, dozens or hundreds of other people who also feel like they’re faking it, winging one day to the next. When you look at it like that, you start to feel less like a weed in a garden but rather just another blade of grass. Getting comfortable is part critical to gaining that self confidence and that confidence will drive changes in behavior – both for yourself and those you interact with.
After gaining some confidence it’s important to identify, in your unique role, what you are responsible for, and what you arent and let the latter go. I know that Product owns the backlog. At the end of the day, I can’t make my Product Owner build the beautiful, organized, tagged, bounty of feature work that I would love to see. That’s on them. What I can do is help them by creating some basic reporting to help identify the features and stories that need the most help while staying out of their way and trusting them to complete it. Likewise, I’m (sadly) no longer an engineer. If one of my engineers hits a blocker, know that I will bend heaven and earth to find you a solution, but I’m not going to lose sleep knowing that I, personally, can’t solve it – I’m just the middle man. There are plenty of battles to fight in this role, just as many hills to die on, but it’s crucial to know which battle to pick, and what hill to avoid. This becomes easier as your confidence grows, and others will naturally start to understand where those boundaries are (and they’ll come to rely on you, as well).
Lastly, as the boundaries become more clear and you become more comfortable with knowing what you own and what you don’t, it’s necessary that you become a subject matter expert on those topics. While most everyone has heard the phrase, “Jack of All Trades, Master of None”, being a good scrummaster is almost the inverse. You want to master the few small bits you do control and leave the rest to others. Become an expert on Scrum, SAFe, or Waterfall – whatever your methodology is (and however your organization chooses to execute it) – master it. Know it top to bottom and sideways. Follow-up your ceremonies with data points, take retro topics and own them like they were your own children and avoid the ‘retro black hole’ that engineers hate. There may not be a lot there (a recent study put the average time a single scrummaster spends for one team at around 10-15hrs a week) but what is there, you need to make sure you are an expert on – and that everyone knows if they haven’t a question on that, they go to you!
At the end of the day, ‘fake it till you make it’ has some truth to it. People see even the manifestation of confidence and that drives changes in behavior, usually for the better. That said, when that day comes you had better be prepared with the knowledge needed to defend that position and reinforce the value you bring to the table. The more folks can come to rely on you as a domain expert, even for what you may perceive as small or inconsequential information, will ultimately be what solidifies you as a ‘good’ scrummaster and a truly valuable member of any engineering team.