7

In a new team, an ex-development manager, who's been in that position for many years, opted in as the team's Product Owner. The team has decided to do Scrum.

The PO's Agile mentality is certainly there, but he can't get into the habit of focusing on the "what" and stray away from the "how", and trust the development team to worry about the "how". As an added difficulty, half the team members are very junior developers, and the PO is trying to guide them (or play daddy) so that he best supports them.

However, that "guidance" is bleeding all over the team, to the point that everything is passing through him. The Scrum Master has called that out and had a discussion with the PO regarding this behavior, and the PO's arguments were that first, old habits die hard, and he is trying towards changing his stance, and second, that he needs to hold the junior devs' hand a bit, until they learn the product and mature a bit, so that they're in a position to take ownership and make their own decisions.

All in all, the PO has a good technical background and is able to make suggestions and give guidance (he does so every day in the morning scrum), however, there is a risk that this behavior will be the norm going forward, therefore cutting off the developers' wings.

Do you see anything wrong in this paradigm, and if so, what would you advise this PO (or Scrum Master) to do on such occasions?

Improve this question
1
  • If anyone in the team notices something that can be improved or some issue that can turn into a risk, then they should raise it at the retrospective. Then with the problem on the table, everyone decides what the next steps should be to improve the issue, minimize the risk, etc. Raise the concern at the retrospective and let all of the team figure it out.
    – Bogdan
    Feb 18, 2021 at 11:00

6 Answers 6

Reset to default
11

I think the timing is important.

During the daily scrum, he needs to focus on the "what".

During the rest of the day, if he feels his experience (to juniors) is valuable, then there's no reason to stop him from dispensing valuable advice.

But he cannot pollute the daily.

Once he has to "walk around" to dispense his advise individually, he probably will be more picky as to whom he interrupts, and the "bleeding" will also stop.

Improve this answer
1
  • 2
    I like this one, good point on focusing on the "what", at least for the morning scrum.
    – dqm
    Feb 18, 2021 at 12:10
4

This is a problem with a simple solution which unfortunately is hard to implement.

It's simple because the PO just needs to change his style from hand holding or making decisions for the team, or being prescriptive, to someone that acts more like a coach and mostly focuses on asks "the right questions" so that people figure out things by themselves. Everyone also needs to be comfortable with failure, because people will make mistakes and you need to accept that making mistakes is sometimes the best way to learn something.

It's hard to implement because it involves changing habits and being mindful of the situation at all times. You have to catch yourself doing the current behavior and change to the new behavior. This is hard simply because of human nature. The PO needs to be mindful of what they are doing and think on the implications. They need to catch themselves and say "hey, I'm doing that thing again". The SM can have a discussion with the PO and agree on how to handle things, then the SM can help catch the old behavior and say "hey, you're doing that thing again".

You very well noted that the current way of working can become the norm and create a dependency on one person while the rest of the team just look to them for everything, but you can't just quit cold turkey. You will have to transition to a new way of working. So raise this issue at your next retrospective with everyone (not just something between the PO and SM). And together decide on what you think is the better long term approach, and what are some first steps to get you there (maybe you pair program, maybe some people bite the bullet and try to do something by interacting less with the PO, maybe some training sessions are needed, etc). Then inspect and adapt.

Improve this answer
2

I would recommend getting the team together to discuss roles and responsibilities.

They might list the pros and cons of having somebody in the Product Owner role who has a technical input to the work and also has authority over team members.

Ideally, try and think of a way to track if the behaviour is problematic or beneficial. Perhaps a frequent check-up in the retrospectives?

Improve this answer
3
  • I see a few potential hiccups with this approach, albeit in theory, it holds. Team members, may not be brave enough to come forward and state that they feel undermined by the PO, or feel micro-managed; not even in a retrospective. Granted, this raises the topic of trust, however, it is a reality that in some companies people are just not brave enough to step up. This is also more apparent when it comes to junior staff and the PO dynamic ("who dares to oppose me?!"). Lastly, the actual perception of the behavior might be biased because of the above scenario, and therefore perceived as helpful.
    – dqm
    Feb 19, 2021 at 13:20
  • I noted the original post commented that the "PO's Agile mentality is certainly there" and hoped that would mean they would be open to this kind of discussion.
    – Barnaby Golden
    Feb 19, 2021 at 17:29
  • 1
    Fair point. What I meant was that he wants to embrace the Agile values and he understands some of them, but it's a work in progress, as his attitude still stems from an older mindset.
    – dqm
    Feb 19, 2021 at 19:31
1

You can introduce the practice (agreement) that the junior devs go to their more experienced colleagues in the team first.

Either do this reactively (the juniors have questions) or proactively (a senior sits with a junior beforehand/at appointed moments).

Improve this answer
1

The fact that you say this person "opted in" to the PO role seems like it may be part of the problem. Usually POs do not choose themselves. A PO is usually expected to be a business manager, not a developer or IT management professional. A PO is someone who has responsibility for some business area or product, can make and implement decisions about product direction and will be accountable to key stakeholders and senior management for commercial success.

Does your PO have those kinds of responsibility? If so he did not "opt in" to the role, it was either assigned to him or he was selected by agreement with a wider group of people. If your PO is not truly someone with that kind of role and responsibility then he is perhaps trying to act as a proxy for the real stakeholders. The best solution may be for the team to engage with actual stakeholders and get them to nominate their PO.

Improve this answer
2
  • 2
    As with all Agile transformations, these things happen: the old positions are scrapped, and are converted to new positions. Now, this can be a very long debate whether this is right or wrong, but the bototm line is that we are in this reality and it will never be a case of one scrum master, agile coach or product owner changing how the whole company works and is structured.
    – dqm
    Feb 18, 2021 at 12:13
  • @dqm Sure but maybe I misunderstood your question. I understood that this PO is an ex-manager, not the current manager, correct? Presumably you do have stakeholders who are known to the team and your team's relationship with stakeholders is what matters to your organisation, not the unofficial role that any person has appointed to themselves.
    – nvogel
    Feb 18, 2021 at 13:27
1

I was in a similar position and while being an Agile evangelist, I didn't see any way out in the given situation. So I'll list the issues you have to solve in order to enable your PO to stop with it.

You are missing a technical lead

While the PO's behavior is making it harder to take technical ownership, he isn't involved full-time in your technical solution. He has to talk to stakeholders, write user stories and do a lot of "paper work". If with all this he still has superior knowledge in a way that "everything is passing through him", you are missing a technical counterpart.

The technical lead should be able to answer all of PO's questions to the point, that PO's technical advice becomes obsolete. Also the technical lead must have a personality take up a stance against PO's attitude.

Having said that, do not ignore PO's advice if it's valuable. Work on not needing the advice anymore.

The Scrum Master is not doing his job

I read that your Scrum Master called out PO already, but why didn't anything change?

As a first step I would forbid PO to speak out on his own in the daily stand-up. He is there to answer questions and stay silent otherwise. If explicitly asked for technical advice, he may share all his precious expertise. The same applies to the time between ceremonies. He is not allowed to disturb the team with unsolicited advice.

Next, the Scrum Master should move away all parts in the user stories' acceptance criteria that explain the "how" instead of the "what". In my case I added hints as comments to give the team a starting point, but made it clear that these are just quick thoughts and no requirements. Sometimes my ideas were helpful, sometimes they were useless. The Scrum Master must do this screening together with the Product Owner, because something that looks like an implementation detail might be actually a hard requirement, e.g. another system is relying on it.

Give your Product Owner continuous training

He needs to understand how his behavior is holding back the team. Maybe he doesn't understand some workflows. Scrum is very vague and doesn't give you a clear action plan. Therefore PO needs somebody guiding him and teaching best practices. Optimally that would be the Scrum Master, but if they are not connected on a personal level, it might be better to search for somebody else in your organization. As the team improves over time, the product owner also has to work on continuous improvements.

Improve this answer
1
  • I like your points, and I can tell that they indeed come from experience. All the answers seem to converge on a few points, such as "ask the PO to keep silent, unless needed otherwise". The question to the PO would be "why do you feel like talking first in the morning scrum?", or something along these lines. Maybe he would have an explanation, which I imagine would be something like "to prevent things from going bad" or something like "they are junior and they don't know".
    – dqm
    Feb 19, 2021 at 19:36

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.