Press "Enter" to skip to content

Scrum Master interview: How a mind teaser can say a lot about the mindset

This mind teaser actually encompasses most aspects of Scrum.

Have you already been interviewed for a Scrum Master position? Or were you the interviewer?

One common question pops often:

According to you, what is the most important Scrum event?

Or the following variant:

If you were to keep only one of the Scrum events, which one would it be?

These questions are actually more of a mind teaser than actual questions, as there is no definite answer. All Scrum events are essentials. Yet this question is a perfect discussion starter, as the interviewee’s answer will usually reveal a lot about his mindset as well as about his experience with Scrum and as a Scrum Master. But the interviewee’s answer will also say a lot about his previous life before being a Scrum Master and how this taints how he puts the Scrum Master role into practice.

In the end there is not a lot of possible answers: Scrum prescribes only 4 events. What are these answers?

Declining to answer: the result would not be Scrum

Some candidates have a hard time choosing between the 4 events. They try to escape by explaining that all the events are important.

The better candidate will be able to explain why all the events are important.

Scrum events are actually reinforcing each other. Scrum works because of all its elements; keeping only some of these elements would lessen significantly the power of Scrum.

That’s actually a good point, however from the point of view of the interview it is not telling much about the interviewee, apart maybe…

  • Either she is the kind of Scrum Master to follow rules by the book and never adapt the rules to the context. And yes it is not Scrum anymore after that, yet I believe that really mature teams will naturally move away from pure Scrum at some point.
  • Or she is not playing the interview game, declining the invitation to discuss openly about the framework. That would be a shame: Scrum’s introspection and adaptation should apply to the Scrum framework itself too.

So in my book not selecting any specific Scrum event is not an acceptable answer. It might be a good introduction before selecting a specific event, as a way to remind the interviewer that this is going to be an open discussion and that this would not be accepted on the real job. Alright, I’m OK with that, I would even qualify it as a good thing.

Selecting one of the 4 Scrum events

Here we go: the interviewee answers with one of the 4 Scrum events. Interesting discussions follows.

Sprint Retrospective

OK, if I have to pick one out of the 4 Scrum events, I would pick the Sprint Retrospective.

Basically if we strip Scrum down of pretty much everything and keep only one event, the Retrospective will allow to re-build the whole framework by introspecting and adapting every Sprint.

That answer is clearly the most heard, it is what most interviewees will answer.

And it’s definitely a good answer.

Indeed, considering introspection and adaptation as the basis of Scrum is a pretty solid point of view.

Inspect & Adapt is at the core of Agile

Take for instance Alistair Cockburn’s Crystal Clear methodology, which is an alternative to Scrum: continuous improvement is at its core. It’s actually at the core of the Agile Manifesto too:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

(last of the twelve principles)

As the Junior Scrum Master’s answer

I would also rate this answer as the common answer for junior Scrum Masters. Because if you only know the theory, then it is hard to match the beauty of the Retrospective’s inspect & adapt.

Yet once you’ve spent some time in the trenches, you come to truly understand how important are the other events. And you’ve also learned in the process that actually leveraging the Retrospective opportunity is both not always easy and not the only way to bring continuous improvement to the team.

By the way, the “inspect & adapt” motto is actually at the core of all Scrum events.

As the former developer’s answer

Finally, former developers will also favor answering “the Retrospective”. That makes sense as while — at first sight! — the rest of Scrum is not that different from how it went before Agile, on the other hand having a formal opportunity to inspect & adapt is rarely seen. At best, it happens once the project is over, trying to get better during the next project.

Doing that Retrospective stuff once every few weeks??? That would have never been accepted by “the management” before Scrum!

Sprint Review

I’d say that the Sprint Review is maybe the most important Scrum event because that’s when we improve the product.

That’s also the moment when you make sure the project is on-track.

And it’s the moment where the team makes one with stakeholders. The team gets to really dive into the business, while the business gets to really know how Scrum works. It’s essential for getting the good mindset into the team, and it’s also the single most important thing that will drive Scrum adoption in the rest of the company.

These are all good points.

Inspect & Adapt with a focus on what really matters

Indeed, “Inspect & Adapt” applies to all Scrum events — not only to the Retrospective — and since Scrum is designed to build products, it makes sense to consider the Sprint Review as the most important opportunity to improve.

Once in Retrospective, you should not improve your process for the sake of improving your process but because it will have a valuable impact on the product, directly or indirectly.

Checking the compass

And yes, it is also the moment where we check that everything is on-track, which is essential in Scrum since Scrum revolves around planning.

It is also a way to feed actual data into the inspect & adapt process.

“Are we doing good?” Well it depends, how would we know? What’s our measure of success?

Sharing with stakeholders

Well, the candidate said it all:

  • You get a motivated team through a product vision and the Sprint Review is the ideal moment to reinforce it.
  • You also grow the product mindset and the business knowledge of the team by getting them closer to the actual business people: the stakeholders.
  • Your best chance to convince the rest of the company that Scrum is the way to go is through example.

The Sprint Review is the perfect moment to share that Scrum works, but also how Scrum works. Scrum evangelization starts with the Sprint Review.

As the former Project Manager’s answer

This is a common answer for former Project Managers since, well, it is the single Scrum event that really takes care of Project Management. I’m not saying it is bad thing!

Sprint Planning

The most important Scrum event is the Sprint Planning. It is the moment when expectations from the team are clearly expressed.

This answer is more debatable than the previous ones.

I am the first to remind new teams that:

Getting the next Sprint ready is more important than finishing the current Sprint.

Another motto on the topic:

Garbage in, garbage out.

Yes, Sprint Planning is definitely important. But…

Beware of not being too rigid

Me talking about the Deifnition of Ready. From my car. In French. https://youtu.be/C9XoZQdnKbA

The point of attention here is that while Definition of Ready (or DoR) can be of great help in many cases, it can also be an anti-pattern depending on the context. DoR may introduce (or keep!) waterfall habits, always demanding more and more requirements ahead of actual Sprint work.

So hearing this answer during the interview leads to more discussion: is the interviewee a seasoned Scrum Master who understands how things works in the field, or a Scrum Master whose mindset might be a little “off”?

Driving the team towards transparency and collaboration

Another output of the Sprint Planning is the detailed plan of the iteration — what I like to call “technical tasks”.

Technical tasks are key to the transparency of the team: the team uses them to display openly what’s going on inside the Sprint Backlog Items, which may be quite big. Seeing if a Sprint Backlog Item is stuck or not is easy if you expose the technical tasks.

In addition, technical tasks play a major role to instill a true collaboration mindset in the team.

Technical tasks show how each team member can contribute towards the Sprint Backlog Item completion. Without technical tasks, it can be quite challenging to get there.

Giving a goal that brings everybody together with the business

And of course, as a result of the Sprint Planning the team should be provided with a Sprint Goal!

The Sprint Goal will be the major focus of the whole team at all times.

If we were to strip Scrum down to the bare minimum, maybe we could rely on nothing more than the Sprint Goal.

All the rest is only helping the team to realize the Sprint Goal.

As the bad Scrum Master’s answer

If you answer “the Sprint Planning” as the only event that makes sense, as the event where tasks are assigned to individual developers, then I’m sorry but you will have a hard time passing the interview.

As the seasoned Scrum Master’s answer

On the other hand, answering “the Sprint Planning” might be great if you mean that it’s the event where you really help the development team to get self-organized and product-focused.

Daily Scrum

The Daily Scrum is the most important event in Scrum. It’s the moment when the whole team synchronizes and passes critical information.

I have never seen Scrum working without the Daily Scrum.

This is the most rarely heard answer. I must say that such an answer puzzles me a little.

Ditching the Daily Scrum is possible, and sometimes even encouraged

First because it’s easy to get Scrum working without the Daily Scrum. Sure you still need the team to communicate and synchronize, but this can be achieved without the Daily Scrum. Some go as far as to say that ditching the Daily Scrum is a worthy maturity goal in itself.

Indeed if the team reaches the point of continuous communication, staying synchronized all day, then clearly the Daily Scrum is a waste of time.

On the other hand if your team is waiting for the next Daily Scrum to get or share information, then the Daily Scrum practice might be hurting the team more than something else…

As the micro-managing Scrum Master’s answer

If you are turning the Daily Scrum as a status meeting and as the moment where you can control individual members of the team, then you’re clearly doing something wrong.

As a Scrum Master, you should be OK with a team asking to stop the Daily Scrum practice — as long as it does not hurt the team’s capacity to communicate and deliver.

Hell, the Scrum Guide is clear on the matter: the Scrum Master doesn’t have to be present at the Daily Scrum. The Scrum Master should make sure the meeting happens, and should coach the team to facilitate the event by itself. If you feel like you must be present at the Daily Scrum, then it raises question marks.

As the remote team’s answer

There is a situation where I can understand why the Daily Scrum would be so essential: when the team is remote. As you certainly know, having proper communication between team members is one order of magnitude harder when team members are not collocated.

So I can get that the Daily Scrum becomes so important with remote teams, first for synchronization but also to build and maintain a proper team spirit.

You know, when you’re collocated you just happen to chat from time to time. Remote workers simply miss that, so the Daily Scrum can be a healthy substitue.

My personal answer… “It depends on the context”

If I were to get asked this question again in an interview, I think my answer would be very elaborate… And in some way, might be playing around with the question 😁

Well, the event I would select would depend on the context of the team.

If the team is not really mature, I would go with the Sprint Planning. Because what new teams really need above all is a stable context and scope during the Sprint. As a Scrum Master I would put a lot of effort on getting the Sprint Planning right: Sprint Backlog Items are ready, not-ready items get ready before starting, driving the team with a real Sprint Goal, fostering transparency and collaboration through technical tasks.

If the team is moderately mature, I would go with the Sprint Retrospective. That’s the next stage once the team has a stable Sprint environment: the focus is now mostly on improvement, self-organization and getting the mindset right.

Finally, if the team is quite mature, I would go with the Sprint Review. It’s about seeing a bigger picture than delivery. It’s about behaving like a mini-start-up inside the company. Vision & Mission is paramount. The most important thing that Scrum brings to this team is the feedback on the product itself. Let’s rock with Lean Startup!

What do you think?

Would you hire me?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top