What the heck is a Scrum Master?
An attempt to define Scrum Mastering based on my personal experiences.
If you google “What is a scrum master?”, the results simply leave you with more questions. A few example results: “The scrum master upholds scrum values”, “He helps remove impediments”, “She builds a high-performing team”, “He facilitates a sprint retrospective.”, and “She resolves the conflict between scrum members.” What are scrum values? Is there a difference between removing impediments and helping remove impediments? What is a high-performing team? Further questioning leads you to a realm of esoteric, philosophical virtues — trust, openness, respect, focus, and commitment. If you continue digging, you might find yourself reading Plato’s Apology and no longer working in a corporate setting.
Endless questions can only mean one thing, the SM (scrum master) role is intentionally undefined (or infinitely defined if you’re an optimist). For better or worse, the SM defines their role as SM every day. Let’s clarify the ‘for worse’ instances first. For the sake of your time, we’ll explain the ‘worst’ instance. The SM behaving as a manager. Even a sprinkle of ‘management’ is detrimental to the successful practice of scrum. Many novice SM’s, and companies new to scrum for that matter, can’t imagine losing control. Scrum asks you to put the power in the hands of those furthest from the top. The developers are the ones closest to the work, and hence know what’s best. Sure, provide some direction…but it’s ludicrous to assign arbitrary timelines without having a ‘boots on the ground perspective’. But don’t worry, scrum is an iterative, empirical approach to development; allowing management every couple of weeks to inspect the direction and progress. The development team’s creativity will surprise you and often inspire an even more wonderful product vision. SM’s are not managers.
We’ve ruled out the worst possible SM, now let’s try to understand an effective SM. I could list off the former buzzword definitions but I feel sharing my tangible experiences will be more impactful. Storytime (names are altered for privacy purposes):
Tom Brady is our team’s rockstar developer. The ‘rockstar developer’ theory refers to the almost genius-level persons found in any type of complex work where their minds solve the problems before most people, like me, even know the problems existed. In our case, Tom was feeling overburdened and even falsely claimed credit ‘for all the work’ to upper management behind the scrum team’s back. This objectively was not true (e.g. check Github). The team’s tendency of asking Tom when stumped only made matters worse. In his mind, he was carrying the weight of the world. Tom was also highly conflict avoidant so the other developers could not tell he was fuming — or so he thought. Combine that with this team being fully remote, we suddenly have a problem on our hands — an SM-type problem. Worth noting, I was a developer on the team at this time as our current SM decided to leave the company. My manager asks me to become our new SM. I anxiously oblige knowing that a problem is brewing…our brilliant engineer is pissed and the other developers need a confidence boost. How can you break this cycle of dependency and arrogance without wreaking havoc on each member’s psyche? I first created a mechanism, a checklist of sorts, to be followed when one is stumped programmatically to avoid over-burdening specific individuals. The checklist wasn’t hard to create, the challenge lied in communicating and employing the mechanism. Do I make an executive move by enforcing the checklist? Do I meet with everyone individually? Do I meet with Tom to sympathize and inadvertently validate his ill-thinking? Do I tell the whole team my honest meta-observations? Do I ask for my manager to step in? The possibilities were endless and each had its drawbacks. One evening while watching the Apple TV Series Ted Lasso, an idea pops into my head…the coach can’t prevent the bullying, only the players, eye-to-eye, can bring the appropriate change…I ultimately meet with Tom. He finally shares his honest feelings. I softly counter his thinking by proving the other developers’ competence and hard work. I challenge him to tell the team how he’s feeling. “Nobody will explode on you if you’re the ONE calmly sharing how you honestly feel. If our manager or myself do it, it’s going to be a sh*t storm.” He agrees. The rest of the development is astoundingly receptive to Tom. The next day I casually share the ‘Q&A’ mechanism. Fast forward to a month later, the rough waters are absent and the scrum team is gliding towards completing the product goal.
As I said earlier, a Scrum Master defines his role every day. On Monday she might be Ted Lasso building a high-performing team and on Wednesday she might be Margaret Thatcher tactfully forming valuable relationships with stakeholders. If you become a Scrum Master, be prepared to learn and grow every day! There is no college degree, Udemy certification, or Medium article that will teach you how to Scrum Master. Even asking other Scrum Masters what to do in situation x will only take you so far because SM-type situations are as unique as snowflakes. You are your teacher and experience will be your curriculum.
P.S. Please feel free to leave any questions, comments, concerns, or violent disagreements in the comments.
