3

I am working with a team that had a P.O. that micro-manages the team, has a very directional approach to working with the team. Often asking them 'when things are finished' etc. I am obviously coaching him on how to behave as a P.O. and that this approach will hurt the team in the long run. So this is part of my role as Scrum Master is to remove this impediment to the teams success.

However, I have an opportunity to do a retro without the P.O. (they are away) and I wondered if anyone has any retro format approaches that would allow this dysfunction to surface from the team. So a way of getting the team to express any challenges or concerns (if any) they have with the PO's approach? Perhaps they don't have any issues with their approach, but it would be good to surface they opinion about it.

Improve this question
3
  • 4
    This question is tagged scrum, so I'd like clarification in the context of the Scrum Guide's Scrum Values. 2 values that should be embraced by are courage and respect: "Scrum Team members have courage to do the right thing and work on tough problems" and "Scrum Team members respect each other to be capable, independent people". Why is the team waiting until the PO is not present to have these discussions? As Scrum Master, what are you doing to coach the Scrum Team in approaching these difficult conversations with courage and respect?
    – Thomas Owens ♦
    May 21, 2018 at 15:20
  • 1
    Have you asked the Product Owner what pressures he is facing forcing him to ask these questions? Does he have unreasonable stakeholders to manage? Empathise with his/her role.
    – Venture2099
    May 23, 2018 at 10:17
  • 1
    @Venture2099's point is well taken, which is why I'm recommending the 5 Whys. If he's micromanaging, it's unlikely to be just because he enjoys it. Understanding the process or communication failure that's reinforcing this anti-pattern is essential to solving it!
    – Todd A. Jacobs ♦
    May 23, 2018 at 15:58

3 Answers 3

Reset to default
9

Waiting for the Product Owner to be away before having the conversation is not a good Scrum approach.

It is better to have an open discussion as a team and resolve the problem with everyone present.

If the team will not speak openly in front of the Product Owner then that is the problem that needs to be solved, not the Product Owner's behaviour.

Improve this answer
1
  • Agreed. One pillar of scrum is transparency. Scrum master is responsible for raising this issue and educate the team to follow scrum practice.
    – TFS
    May 30, 2018 at 13:33
3

I do not know what kind of political hot bed your organization may be in but I would avoid trying to uncover the teams' opinion of an individual member of the team in an open group. I think asking for such a thing would jeopardize overall team trust. After all, what would the team be saying about me when I am absent on a retro?

If you are hypothesizing that this PO's behavior is adversely affecting performance, investigate this behind closed doors where anonymity can be assured. And be sure NOT to ask questions in a leading way so as not to inadvertently confirming your hypothesis in a biased way. So avoid doing this in a retro entirely and conduct one-offs privately.

Improve this answer
3
  • I mostly agree with your post, especially about confirmation bias preventing an effective root cause analysis. I'm less sure about the advice to hold the conversation behind closed doors. There are times when that's useful, and times when it's counterproductive and not in the spirit of open team communications. I want to give you 4/5ths of an upvote, but the system won't let me. :)
    – Todd A. Jacobs ♦
    May 23, 2018 at 7:01
  • 1
    @ToddA.Jacobs, I agree about open communications but the OP wrote some items that made an open forum contraindicated. 1) he has an unverified hypothesis; 2) the PO is already being "coached" which signals a personnel problem; 3) the entire write-up has a few signals of a less than optimal team maturity and using mature tactics on an immature team is unlikely to work. The biggest driver is that it feels like a gang-up ready to happen on a possible personnel issue. That, to me, requires discretion.
    – David Espina
    May 23, 2018 at 11:59
  • 1
    You're right, David. I was taking a broader view, but when you put it that way (I occasionally miss the close target for Too Narrow) your advice is sound. I appreciate the clarification, and hereby tender a +1.
    – Todd A. Jacobs ♦
    May 23, 2018 at 15:56
2

Overview

Barnaby Golden, Thomas Owens, and David Espina have all given good answers, but I want to address your core question in a different way. You ask:

I wondered if anyone has any retro format approaches that would allow this dysfunction to surface from the team.

As the Scrum Master, it is your responsibility to facilitate respectful, courageous, and sometimes difficult discussions within the retrospective. Team working agreements, roles and responsibilities, and team communications are all topics that are well within the mandate of a typical retrospective, but it's your job to ensure that it's done constructively.

I realize that you're looking for a simple format for addressing the topic, and while I provide one below I feel like that aspect of your question is actually part of the problem. The general tenor of your original post already implies a strong judgment about the situation and the participants, and that is not conducive to holding a healthy retrospective because it sets up a Team-vs-PO dynamic that is likely to devolve into defensiveness and finger pointing.

Instead, if people are raising the issue with you in you role as Scrum Master or Team Member, then as a member of the team you're well within your rights to call out the issues that have been brought to your attention within the retrospective. Then, be sure to facilitate the discussion to keep it on track and constructive, and keep the team focused on walking away with a concrete plan or action item.

A Worked Example

The Scrum Master's goal isn't to assign blame; it's to facilitate continuous process improvement. With that in mind, an experienced Scrum Master might use the following format to uncover, address, and resolve a role- or communication-based process problem within a Sprint Retrospective.

Scrum Master Mini-Script

This Sprint a number of people have raised concerns about status reporting to the Product Owner reducing Development Team productivity as measured by...To address these concerns, I'd like us all to examine:

  1. Whether it's actually a problem for the team as a whole or for individual members.
  2. If so, what's wrong with our process, communications, or transparency that's triggering these what feels to them like excessive status pulls?
  3. Now that we've identified the issue, what are our action items as a team?

You can also use techniques like 5 Whys to identify a root cause, and make sure you step in firmly to prevent ad hominems or any attempt to ascribe evil intent rather than uncover a reason. Remember that the goal is to identify process problems, and then identify process-oriented solutions.

Okay, Then What?

As a further practical example, it seems likely that in this case the 5 Whys might identify a lack of Product Owner confidence in the Development Team's ability to meet the Sprint Goal, or uncover a less-than-transparent development process where the Sprint Backlog, Kanban Board, or other information radiators aren't reliable or aren't being used to best effect. Whatever the problem turns out to be, think of it as a process problem and find a process-oriented solution as a team that the whole team can get behind.

Adapting the team's working agreements and practices to solve process problems is at the very heart of Scrum, Kanban, and the Agile Manifesto. The roles, ceremonies, and processes that form Scrum are meant to facilitate effective negotiation of sustainable working agreements, and not to affix blame. Always make sure the entire team (and especially the Scrum Master) maintains a relentless focus on the process problems, not on finding individual fault!

Improve this answer
1
  • When I had this situation, the Devs wouldn't speak up because the PO was a senior exec and could get 'scary'. But they were obviously not happy, so I chose to handle it myself via one-to-one with the PO. As the Devs expected, the conversation did get quite 'robust'. Although this ultimately forged a better agreement with the PO, your answer makes me wish I could go back to at least try to get a Team agreement in the way you suggest. As you say, avoiding a Team-vs-PO dynamic is vital. I since learned that 'Avoidance of conflict' is one of the the five dysfunctions of a team™. Excellent answer.
    – onedaywhen
    Jun 7, 2018 at 7:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.