PO behaviour uncovered during Sprint Review
Situation - PO acts surprised with the outcome of the Sprint and expresses unhappiness/anger during the Sprint Review. This is not first time though. This behaviour results in low morale among the developers. How can the SM handle this situation?
In my view,
- Conclude with the agenda of Sprint Review
- During the Sprint Retro, see if any one raises the topic. If not, ask - Are we all happy with the value being generated lately? If not, what could we do about it? (I am assuming that conversation will go from "Low Value->PO behaviour->Low Morale" and eventually address the situation.)
Where I am leading here - I sense few things here (1) PO involvement- Not sure if PO is actively involved during the Sprint to clarify/make decisions, OR whether it is PO behaviour issue that can be sorted out with coaching (2) Morale issue - Assuming if PO is there with the team when needed, What could be done to address the morale issue? (3) is it team that is not working together?
PS - This is hypothetical situation and hence trying to understand 'What best SM should do' and approach this situation.
PO acts surprised with the outcome of the Sprint and expresses unhappiness/anger during the Sprint Review
This shows that there is a mismatch between PO expectation and what the team delivered. PO need not be actively involved in the Sprint (only during planning, retro and review) Developers should reach out to the PO in case some clarification is needed during the sprint (as a SM you can facilitate the discussion may be). As a Scrum master this topic must be raised in the Retrospective (obviously this is something that did not go well). The solution might be more focus in the sprint planning and ensuring each task is clearly understood by all and have some mechanism in place to reach out to the PO during the sprint in case developers need some clarifications wrt the requirements.
Did the Developers make an achievable Sprint Goal commitment and was it met or not?
What is your role on the team in this hypothetical situation?
If you're the Scrum Master, you should know if the Product Owner is actively involved or not. Whether it's through facilitation of the various events or people on the team raising impediments for you to help them work through, you should, at the very least, be aware of the Product Owner's behavior throughout the Sprint. If the Product Owner's actions are the problem, you could have that conversation more immediately.
Generally, the Sprint Retrospective is a good place to address this as a team. That doesn't mean that the Sprint Retrospective is the only place to address this. The Scrum Master may coach individuals, small groups, or the whole team throughout the Sprint. Impediments may be raised anytime, and waiting for the Sprint Retrospective to review, prioritize, and plan actions isn't always possible.
Hypothetically, how did this team get into a situation where this is occurring? Hypothetically, it sounds like the team does not trust each other, does not communicate and does not understand the Scrum framework.
Hypothetically and realistically, there is no correct answer to this situation. Every situation will be different and there is no "'What best SM should do' and approach this situation. " The situation is not the Scrum Master's responsibility to deal with. It is the Scrum Team's issue that needs to be addressed by the Scrum Team. The Sprint Retrospective's purpose is for these kind of honest conversations. However, if the only time this is discussed is during a Retrospective, the team is failing themselves in becoming self organizing, self managing.
PO acts surprised with the outcome of the Sprint
Is the PO not happy due to how the functionalities are working(Acceptance Criteria not met) or the amount of work done in a sprint(Velocity) ?. Retro is definitely the place to hear the discussion from PO and the developers about this conflict. Whole team can identify the improvement that should be made in their process or people approach. SM should not preassume that its only a problem with PO.
As agreed with Daniel, while retrospectives serve as a vital element of continuous improvement within a Scrum team, fostering collaboration, empowerment, accountability, and adaptation for sustained success and development, I also advocate for the implementation of workshops aimed at crafting a team working agreement.
Developing a working agreement offers numerous advantages within a Scrum team, complementing with psychological safety to cultivate a conducive environment for clarity, collaboration, trust, innovation, and resilience. This holistic approach contributes to heightened performance and well-being among team members.
The scope of a working agreement extends beyond achieving the following objectives:
-
Establishing clarity and alignment
-
Enhancing communication channels
-
Resolving conflicts effectively
-
Fostering team cohesion and trust
-
Encouraging innovation and creativity
-
Cultivating resilience and adaptability
Embracing a comprehensive working agreement empowers the team to navigate challenges, resolve conflicts and capitalise on opportunities, ultimately fostering a culture of excellence and continuous growth.
During a sprint review, when behavioral issues between the Product Owner and the team arise, it is imperative for the Product Owner to re-examine the fundamental values of Scrum, particularly regarding the aspect of respecting the team. In this scenario, it is advisable for the Scrum Master to take the lead in facilitating this crucial initiative.