Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia. Read Statement
To intervene or not to intervene on Daily Scrum?
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  and , 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.
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?
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.
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?
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.
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.
Next time, may I suggest you try to give them some feed-forwards instead of some (positive or negative) feed-backs ?
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?
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.
@Olivier, what is a feed forward?
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.
Thanks, yes it is - thank you.