Nope. But it sure does help.
Let's look at this academically, then practically. Please open up your copy of the Scrum Guide and turn to page 7 (of the English PDF). Fine. Nevermind. Here's a link to the section online. Let's read together. Hmmm... blah blah blah, OOH, there's this introductory bit:
The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
See the bits I underlined? To better serve the Scrum Team, it's helpful to know how that team works, the environment they work in (...its limitations), and some of what they're working on, so you can better judge how to address these interactions.
Let's say that in the middle of the Sprint a manager tells a developer that they are suddenly on an interview panel. Besides the actual interviewing, there may be an expected time sink to read & assess a sample code submission, and then conferring with the other panelists, and then the context switching time on either side of each of those activities. This can be a particularly disruptive event, and if this is unavoidable, expectations may need to be reset. In my experience, this had resulted in a discussion at the subsequent Retrospective, and then a question was added to the Daily Scrum: "Anybody unduly distracted?"
This is very much treating the team like a closed system, with these 'interactions' crossing the system boundary, from the outside going in. This mental visual soothes my engineering brain, but it's also very cold: the Scrum Master interacts with the system (team) herself as well. Being technically savvy can be helpful here, too.
Open back up the Scrum Guide, please, same section, a little further down... there's a list of bullet points regarding 'Service to the Product Owner'. Let's pick the first one.
Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible
A happy team is usually an engaged team. An engaged team is usually a team that knows why they exist, who they are serving, and how what they're building is helping someone, or contributing to the business. Working with the Product Owner to clarify 'the why', and then infuse it in every story, crafts a team that can bring more of their complete selves, since they are better connected to the work. If the team can empathize with the user, then they will have more informed opinions in story refinement, and even story creation. Now the Product Owner has a team... of collaborators in 'the what'. A test of this that has informed my stance is: if you, as Scrum Master, know something about the product domain, ensure the team does, too. Be the lowest bar of product knowledge - this is another way to serve.
Back to the Scrum Guide, to the 'Service to the Development Team' sub-section, we have this:
Removing impediments to the Development Team’s progress
Automated testing is a key part to delivering a potentially shippable work increment at the end of every Sprint, yet each additional automated test, for each additional story, is more easily writeable & runnable if there is an automated test framework. Not having one of these, or enough of one, may mean you consistently cannot meet your Definition Of Done. An alternative consequence is that your regression testing suite is mostly manual, thus taking a while to execute before you're able to release.
As a Scrum Master who understands some aspects of the software delivery process, you may see this impediment, and then ask the (whole) Delivery Team if there is enough pain here such that they want to do something about it. You may not need to be technical to spot this opportunity, but some technical chops may help you appreciate that building up this automation framework requires some investment, e.g., for the Java developers to help, they may need to learn Ruby before they can contribute to the framework in place.
So far, I've assumed the Scrum Team develops software, but you 'n' I know this isn't always the case. What if you're on a hardware team? Or running a classroom? Or maybe you're all marketers? Scrum can still be helpful in these contexts, and I think you'll agree that if your Scrum Master is technically knowledgeable in software development, then her technical background won't be the most useful to you.
If your context is hardware, the Scrum Master will want to know that recommending a 'mob programming' approach would involve folks shuffling from one piece of machinery to another, which may not be efficient, effective, or even safe, especially when compared to using this practice around a keyboard.
If you're in a classroom setting, what is a Retrospective format that is age-appropriate, captures the kids' attention, and gets to an actionable item of improvement they can all understand, appreciate, and recall, maybe by way of a drawing, especially if they can't read?
If you're on a marketing team, a campaign may not be a feasible output in a two-week Sprint, but other work may.
So... does a Scrum Master NEED to be technical?
Well, it first depends on the 'technology', as per these most recent examples, and even then, I'd argue that it's more important to pay attention to the team and the environment through the lens of servant leadership, pulling from your trusty ol' copy of the Scrum Guide:
Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
So... do that. Then lean on your technical know-how, whatever it is, as appropriate.
(Reading this back to myself, I wouldn't put this blog post neatly in the #ScrumStories category, per se, but there are several of my real world experiences sprinkled in here, so I hope this meets the spirit and is similarly helpful.)
Comentarios