What’s a Technical Scrum Master and how do you excel in this role? Well, a lot depends on specific circumstances; there’s a myriad of Scrum practices out there that make being a Scrum Master at any one company, or even team, different. Embracing change is integral to being a great Scrum Master. A Scrum Master is someone who molds themselves to fit rapidly changing landscapes; one who rises to challenges and accepts that there is always a better way; one who chooses the most appropriate path for any given circumstance.
New projects, new team members, lost team members, interpersonal conflict, organizational change, workplace politics, unrealistic deadlines—these are just a few of the things Scrum Master’s navigate as their team grows and evolves.
Part-time vs. Full-time Scrum Masters
Ah, the classic part-time Scrum Master! A two-headed monster. Take one part developer, add one part Scrum Master and viola! Scrum Mastering part-time is a constant struggle to maintain focus. One week it might be your code, the next your Retrospectives, but what’s constant is that one always suffers. This part-time focus is not always sustainable in a fast-paced growing company… and so enter the full-time Scrum Master! The few brave few who have given up development to be a servant leader full-time.
Can you remain technical? You’re coding less (or not at all), you’re reading articles like this, or planning retros, or finding common ground with your Product Owner. You don’t have time left to learn new design patterns, or the latest new features in <insert your language here>. Your technical skills start to lag — you’re no longer a developer, you’re now a full-time pseudo-leader. You’re not quite a manager, but not really a developer either. Someone without any real home, and in some cases without any official responsibility, even. You’re a full-time servant (leader)!
Soon you’re able to run the groundhog-day of meetings like a pro: stand-ups, planning, retro, grooming — wash, rinse, repeat. You’re researching new retro ideas, listening to your team, facilitating better, even planning social events. Excel spreadsheets with tab after tab of data are being created that illustrate to your manager just how effective your team is (and how valuable your role is). You’re typing acronyms you don’t understand into Jira stories. You’re throwing Acceptance Criteria into Jira like a modern-day Shakespeare. You exist!
But is your team writing quality code? Is an avalanche of tech-debt building up? What’s a build pipeline again and who’s Jenkins, anyway? Is dev-ops still a thing? You don’t know, you’re too busy building the best retro plans, writing the best acceptance criteria, and spewing metrics into spreadsheets — rinse, lather, repeat. This is where a full-time Scrum Master role can start to break down for some people. Is full-time Scrum Mastering effective? Sure. Can it be more effective? Definitely. What’s the secret? More domain knowledge, perhaps?
Enter the Technical Scrum Master
Full-Time Technical Scrum Master — wait, is that a thing? A lot of Scrum Master’s come from the development world, so of course it is! Full-Time Technical Scrum Master’s rarely do actual feature work though; they might be writing tests, doing code reviews, running technical workshops, waxing poetic about design patterns, but they’re not often building the features. Instead, you have one foot in the development world, and another in the merry-go-round of meetings, metrics, and incremental improvements. Sure, you’re now opening Excel more than your IDE, and maybe you’re even one Excel formula away from becoming a real Project Manager (gasp!), but if you put your mind to it you can be both an effective technical leader and an amazing agile leader at the same time.
Keep in mind, having one foot planted in the technical world requires the responsibility not to abuse that power and force your perspective in technical matters. You’re no longer leading technical meetings as an expert, rather you’re holding your technical cards close to your chest and throwing down cards only when all the other players are folding. As a servant leader, it’s okay to ask questions you might know the answers to. You don’t need to solve every technical challenge anymore, but you do need to help facilitate and guide the team to solve their own technical challenges, whatever that looks like for your team and situation.
Putting it all together
The role of Technical Scrum Master is a complex one with many nuisances. What makes a good Scrum Master in one company, team, project (or even one week to the next) doesn’t stay static. Technical or not, the most challenging part of being a Scrum Master isn’t having a solid knowledge of development or Scrum theory, although it can help in some situations. Rather, it’s being able to remain flexible, to exist in the trenches while also building a map of the battlefield, to ultimately servant-lead your team into battle while embracing and sharing in every challenge, failure, and success along the way.
The views and opinions expressed are those of the author and do not necessarily reflect the official policy or the position of any entity.
