When should SM react?

Last post 08:23 pm May 20, 2021
by Simon Mayer
2 replies
Author
Messages
06:32 pm May 18, 2021

I know that inspection and adaptation as well as removing impediment should happen as early as possible, right?

But what if another time could be potentially even better to do so, for instance adding opportunity to learn/ improve self management?

Few real examples to better articulate what I want to cover by this quesrion:

1) if I am not sure whether PO uses enough time with Developers, should I wait till sprint review to see whether he is happy what he sees (the best way to measure progress is delivered value, right?) and then see whether developers adress it during retrospective (or raise it on my own if they dont). Or maybe should I react earlier during sprint based on my suspect the communication is not enough good and ask Scrum Team from my initiative about it? Earlier but less coaching to build self management.

2) if stakeholder disturb team with her questions and they cannot fully focus during sprint but they do not raise impediment for some reason (I do not know, maybe they are afraid of her position in company). Should I wait to retrospective and see whether they raise it during the event and if not raise it on my own and coach about scrum values (openess and courage) or should I react earlier and discuss with team  (my inititiative) and later discuss with stakeholder? Later but more opportunities to learn. 

What is better ?

 

07:11 pm May 18, 2021

Would the lessons be better learned if you refrained from taking action, and let people learn for themselves? Sometimes that's true. It can sometimes be better to let people learn by making their own mistakes. At other times the risks involved would be too great. A Scrum Master should be prepared to judge each situation non-prescriptively, and on a case-by-case basis.

08:23 pm May 20, 2021

Another option might be to lay down some breadcrumbs, so that the team can retrace its steps and spot the learning opportunity at the Sprint Retrospective without you having to raise it.

For example, regarding the first point, you might observe the Developers being unsure of the way to proceed, before eventually sticking rigidly to the acceptance criteria, even though they have doubts.

If you say nothing, the Developers might not realize that they even made a decision; but if you ask something like "What do you think is the right way to proceed?", they might later reflect on that as the moment an opportunity was missed or a mistake was made.

If this still isn't enough for them to spot it, you might ask more questions during the Sprint Retrospective like "what were the key moments when you could have gone in a different direction?", and "what did you need to make the right decision at that moment?"

They might come to the same conclusion that they needed the PO to be involved. They might also come up with other solutions that they find more appropriate, like needing a better understanding of stakeholder needs, or being allowed to talk directly to the customers and users.