Skip to main content

To intervene or not to intervene on Daily Scrum?

Last post 03:36 pm March 20, 2016 by Dennis Mansell
10 replies
06:28 am March 6, 2016

We all know what should happen on Daily Scrum. Yet, there are many ways that lead to the desired and acceptable state of this event. I would especially like you to share on how you approach interventions.

I got familiar with [1] and [2], but this matter is still not that clear to me:

Do you intervene during Daily Scrum, so that you cut digressions at the origin, or let it go and see what happens and follow up on this after the event is over?

I can see good and bad things for both approaches. A bad thing is this subtle consequence that when Scrum Master intervenes, he might potentially be responsible for event to run over the time box. And then the team might ask to extend it 5 minutes more...
A good thing is you teach in the right moment and right place. That's Gemba Kaizen.

So then:
What factors do you consider when choosing between those two (intervene, let it go) approaches?
Do you run any exercises to teach the Daily Scrum? What are they?


07:17 am March 6, 2016

I would favor intervention in the situation you describe. Digression implies that timeboxing is not being valued, and it would be the Scrum Master's responsibility to coach team members accordingly.

Note: I wrote the first article you refer to as part of the Agile Development in Practice series. That's general advice for a general audience, not a rigorous interpretation of Scrum and its rules. For the purposes of discussion in this forum it is more important go by the Scrum Guide.

05:44 pm March 6, 2016

how do you cope with a situation, when effective intervention(s) require so much time within Daily Scrum that, in order to achieve it's goal, you run over event's timebox?

06:51 pm March 6, 2016

A Scrum can be called by any Scrum Team member at any time for any reason. The Development Team are not restricted to their daily one, which has the specific purpose of allowing them to plan their work for the next 24 hours.

Therefore, if the Daily Scrum failed to produce a satisfactory plan, I would call another Scrum to resolve the problem, preferably straight afterwards to minimize waste. I'd use it to coach the team in more effective Scrum techniques, and repeat again if necessary until a viable plan for the remainder of the day is in place.

Without that daily plan the Sprint Goal is not on course to be achieved. If one cannot be agreed then I would invite the PO to the Scrum as a participant, and help to evaluate whether or not it is wise to continue or to cancel the sprint.

09:41 am March 8, 2016

When I have had similar situations (identifying poor practices in a Daily Scrum), I have elected to allow the team meeting to proceed to its conclusion, and then offer my feedback.

I certainly want to take advantage of as many opportunities as possible to educate and make my observations known, but I try my hardest to refrain from stepping in during the meeting.

My "observations" may run past the 15-minute meeting time box, which is why I always preface my input by asking the team if they "a" - want to hear them, and "b" - if they have time to hear them. This way, the team has ownership of my input (if they say "yes" to both questions), and it isn't a command/control situation where I have the team captive to listen to my feedback.

04:35 am March 9, 2016

Next time, may I suggest you try to give them some feed-forwards instead of some (positive or negative) feed-backs ?

07:35 am March 17, 2016

Intersting replies.

If I get it correctly, Ian would call subsequent Scrums (one after another to reduce waste) in case the team didn't come up with a plan for the next 24 hours.

Timothy wouldn't call a Daily Scrum, just ask the team if they'd like to hear his feedback. How do you cope with a situation, that team says: no?

04:03 pm March 18, 2016

The question: "What if the team says no?"

Then they say no. Place your observation on a shelf, and look for other opportunities to make it known. Perhaps the right situation will reveal itself in the Sprint Retrospective? Just be careful to not get "preachy", as a Scrum Master should always be sensitive to dominating conversations.

Another opportunity may pop up when conducting 1-on-1 meetings with team members. Just don't be afraid to file the observation away to be raised at a later point. There are always plenty of areas where Scrum Master input can be valuable to the team. Be "Agile" in your approach to guiding and serving your team.

05:33 pm March 19, 2016

@Olivier, what is a feed forward?

10:45 am March 20, 2016

For instance, if your tennis teacher tells you "your service is good (or not good)" it is a feed-back that doesn't help you very much.
Generally speaking, Anglo-saxon people will use positive feed-back (guys, you're awesome !), where latin people will use more negative feed-back (I have seen better player than you !).

If he tells you, "for your next match, why not trying to launch the ball higher ?", it is a feed-forward.
Hope my example is clear enough.

03:36 pm March 20, 2016

Thanks, yes it is - thank you.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.