I was recently asked my thoughts about questions scrum masters could be asked during an interview process, particularly in regards to their thoughts around testing and quality. This allowed me to think about the role of being a scrum master. Which in turn allowed me to think about how I would do as a scrum master.

I’ve often told people that, for me, “agile” is nothing more than an approach. But it’s not even a unique one necessarily. What I try to do — whether agile or not — is help delivery teams get small things done more often and make better decisions sooner. (I’ve expanded on that a bit in Reframing Agile.) Then I talk about how we actually do that.

Regarding the overall point, I think Agile (with the capital A) became a bit of an ideology and then, once enshrined, became a bit of a new age-style religion. And when that happens, things can get a little defocused. Ideologies and new-age religions tend to accrete things around them, such that all the sudden to “do agile” and to “be agile” become conflated.

That means you must do these things or “you’re doing it wrong.” Thus does a bit of fundamentalism creep in. And you must do those things in this particular way with, for example, these particular “ceremonies.” (Read “ceremonies” as “rituals.”) Thus can agile become a bit ceremonial and ritualistic, thus stifling a lot of variation.

Yet … that seems like I’m dismissing the basis of agile, doesn’t it? I’m actually not. What I’m speaking about is how people treat agile as a concept but then how they actually practice it in day-to-day work. And that does seem like something a good scrum master should be thinking about.

Question the Masters

So, as to those questions, here were some I came up with that I would hope to be asked during an interview in relation to testing and quality but in a scrum master context.

“In an agile context, quality is something that everyone is responsible for. What do you feel are the scrum master’s contributions to quality?”

There’s various ways to word that but something like that is what I would be going for. This allows the candidate to range over a couple of topics, giving you an idea of how broadly they think about quality.

For example, they might bring up the quality of conversations. Or, more specifically, the quality of communication and collaboration. Or the quality of learning from mistakes via activities like retrospectives. But a key thing there is seeing what their relationship to quality is, whether they see it as very broad or very narrow.

“Let’s say you’re in a situation where you can only keep ONE of the Scrum ceremonies. Which one do you think is the most important to keep?”

I’ve often got a lot of mileage out of questions like these. This allows me to see (1) what the candidate puts the most emphasis on and (2) their rationale for putting their emphasis where they did.

Ideally what I like to see is a candidate that asked me questions about the context. For example, I would want someone to say: “Well, my answer to that might depend on some specifics of what’s currently working well, what’s not, etc.” So it allows me to see what assumptions they make, which tells me a lot.

“A scrum master makes sure that following a scrum process doesn’t impede team progress. But what if team feels that scrum is what’s impeding team progress?”

This can go in a lot of directions and does require the person recognizing that scrum (and scrum masters) can go wrong. So I would hope to see a little introspection here rather than just an immediate focus on “setting the team straight.”

“Sprint is complete. Your scrum team is consistently failing to meet commitments and their velocity is volatile. What are the most probable reasons for this and what would you do as a scrum master in light of this issue?”

This one can fit into a behavioral role play example, where perhaps you throw some complications into the situation to see how the candidate responds. Notice here that this question is focusing on internal qualities, such as commitments and velocity. I like this one because I really see this as a way of getting to this question:

“How does the role of a scrum master help teams find a balanced approach to quality and delivery?”

That is something I really feel scrum masters should be able to answer.

One approach I like in testing and quality assurance is the “skeptical newbie” scenario. I’ll frame a situation such as I’m new to testing and the candidate has to train me. Then I’ll proceed to ask a series of questions around that idea and see how they respond. (For example: “How would I recognize if I’m writing a bad test?”) So with that context applied to scrum masters, I might go with this:

“You have to train me to be a scrum master, but I’m not sure the job is for me. How would you train me to recognize a good scrum master? How about a bad one? What are the some of most common misunderstandings I’m likely to encounter?”

This gives the candidate a chance to range fairly broadly over their own experience while still showing you how much they consider that experience part of a discipline and a craft, as opposed to just something they do.

Here’s one I’ve enjoyed asking:

“How do I make sure scrum rituals don’t become ritualistic? How do I make sure scrum ceremonies don’t become simply ceremonial?”

I rarely hear agile pundits and scrum masters that I’ve interviewed answer that question well. Yet how someone responds to that tells me a lot about how they have conceptualized between form and function; between style and substance; and thus between theory and practice.

Scrum Master and Testers Have Commonalities

I’m convinced the agile and scrum community needs more pragmatically skeptical people bolstering its ranks. And being a pragmatic skeptic is something that test specialists are very good at. Beyond that, the intersection of humans working with technology is exactly where scrum masters sit — as do testers.

Both testers and scrum masters are often more focused on how people reason about and communicate about what we’re all working on. Both scrum masters and testers are focused on what it means to deliver value in reasonable time frames.

Both testers and scrum masters have to be watchful of not falling into a technocracy, wherein human collaboration and decision making is abdicated to tooling.