Why "Scrum" Isn't Making Your Organization Agile: Harmful Misconceptions About Product Owner Role

Поделиться
HTML-код
  • Опубликовано: 17 сен 2024
  • Free comic book version at: seattlescrum.c...
    TABLE OF CONTENTS:
    How Is The Product Owner Role Supposed To Work?
    How Does Your Large Organization Misinterpret The Product Owner Role?
    How Does Misinterpreting The Product Owner Role Delay Customer Feedback?
    How Does Misinterpreting The Product Owner Role Reduce Developer Motivation and Empathy For Customers?
    How Do Real Product Owners Deliver The Highest Customer Value?
    How Does Misinterpreting The Product Owner Role Reduce Value Delivery?
    What Is Unpleasant About Trying To Fulfill The Misinterpreted Product Owner Role?
    How Can We Help The People Stuck In This Role While increasing team self organization and cross functionality?
    Is It Necessary To Create New PO-derived Roles Like Chief Product Owner, Business Owner, etc.?
    This video corrects some errors in my friend Henrik Kniberg's otherwise excellent "Product Owner In A Nutshell" video.

Комментарии • 41

  • @MichaelJamesSeattle
    @MichaelJamesSeattle  5 лет назад +10

    I'm flattered that my hero Alistair Cockburn endorsed this video: twitter.com/TotherAlistair/status/1136145401311088640

  • @YourTechHomeboy
    @YourTechHomeboy 2 года назад +12

    Wow. The perfect illustration of my experiences. Many orgs say they WANT to do scrum but that simply means " Hey we want a Scrum master to help increase our velocity by any means."

    • @MichaelJamesSeattle
      @MichaelJamesSeattle  2 года назад

      I hope the video helped you feel less alone with that problem.

    • @stratotramp6243
      @stratotramp6243 Год назад

      Me too especially the POs ending up being TOOs, hopefully helps me avoid some icebergs in future and things to watch for.

    • @ChrisAthanas
      @ChrisAthanas Год назад +3

      Business people confuse software development with traditional product manufacturing
      They don’t understand it takes much longer to design software than to “manufacture” it. With software manufacturing is now free.
      All that is left is design
      And design is not manufacturing
      Very few business people can make this distinction

  • @Joshmgonz
    @Joshmgonz 4 года назад +14

    Realized I am a Team Output Owner. Thank you for the video and insight

  • @UrsReupke
    @UrsReupke 6 лет назад +3

    A great illustration of common pitfalls. Thanks, Michael!

  • @markwalker1416
    @markwalker1416 6 лет назад +4

    You articulate that wonderfully. Thank you!

  • @rubibi523
    @rubibi523 4 года назад +3

    Great Video to illustrate real life examples of PO

  • @darrelanderson7906
    @darrelanderson7906 Год назад +1

    Good explanation of the problems in large organization.

  • @gotnoshoes22
    @gotnoshoes22 3 года назад +2

    This is spot on but what I have found is so many people that don’t actually want accountability and prefer to hide behind “process” in large companies. They want to be told what to do and how to do it 🤦‍♂️. Do you bring this target culture to the people or do you bring the right people to this target culture. Probably a mix of both.

    • @MichaelJamesSeattle
      @MichaelJamesSeattle  2 года назад +4

      I don't think most large companies are serious about becoming adaptive, learning organizations. I wonder whether they'll be able to compete in the future.

  • @christophklesser7532
    @christophklesser7532 3 года назад +1

    Thank you oh so very much!

  • @b.a9891
    @b.a9891 5 лет назад +2

    Very well said

  • @edbrslagmail
    @edbrslagmail 5 лет назад +2

    awesome !! thanks

  • @PeterGfader
    @PeterGfader 6 лет назад +1

    Great video with very common misconceptions. THANKS

  • @isurujn
    @isurujn 2 года назад +1

    Team Output Owner. That's me. It sucks.

  • @DidYouCropThat
    @DidYouCropThat 4 года назад +3

    How would you handle a situation where PO is violating Scrum rules? Managing the team instead of trusting them? Ignores quality and pushes for the value only? Role definition seems like the only protection of dev teams, but maybe there's more

    • @MichaelJamesSeattle
      @MichaelJamesSeattle  4 года назад +2

      Most of the times I see this, the person acting as PO is some kind of intermediary instead of the actual business decision maker.

  • @scottsnelson1
    @scottsnelson1 Год назад +2

    Often there is an interim period where an organization adopts Scum and succeeds with it before someone insists on metrics that are not relevant will be required to justify further success until it is managed back to the way it was before.

    • @ChrisAthanas
      @ChrisAthanas Год назад

      Yea human politics are always in play and on its own revert back to comfortable ways of work
      Which involve a lot of delays and pushing responsibility off so no one makes the “big mistake” and loses their cushy job

  • @tombaldwin107
    @tombaldwin107 5 лет назад +1

    Really great, little video! (I share your thoughts on the subject.)

  • @Brett5ive
    @Brett5ive 2 года назад

    Great video!

  • @HomelessMillionaires
    @HomelessMillionaires 5 лет назад +1

    Awesome content keep going!

  • @rostyslavlakhtadyr8635
    @rostyslavlakhtadyr8635 3 года назад

    Awesome!

  • @DobesVandermeer
    @DobesVandermeer 2 года назад

    So let's say we have a few product managers now, if we adopt this approach then there would be just one person who owns the backlog. Would the other product managers still have a role if they are helping to do research and write stories? Assistant product owner?

    • @petriheiramo8047
      @petriheiramo8047 2 года назад

      Could be, yes. PO is the "ultimate point of responsibility", not a workhorse. They're the captain of the ship - they have the responsibility that we have the right cargo and are taking it to the right place. The rest of the crew take care of the details within that overarching goal and priorities. AND help the PO when they spot something that might endanger the ultimate goal. Or when they spot something even more valuable than we thought of so far. So these additional stakeholders (SME's, managers, customer service people, sales, marketing, etc.) are usually very important key people for the PO and the team(s).

  • @kasiazych3298
    @kasiazych3298 2 года назад

    Hi! I researched it a lot but still am not sure: Should developers align on dependencies between themsleves or PO should help?

    • @MichaelJamesSeattle
      @MichaelJamesSeattle  2 года назад

      Rule of thumb: if it's a HOW question, it's the responsibility of the [development] teams. If they discover the shared work before the Sprint starts, they could plan how they will coordinate during less.works/less/framework/sprint-planning-two . During the Sprint, they would use patterns such as these: less.works/less/framework/coordination-and-integration

  • @klapyahandzup
    @klapyahandzup 3 года назад

    nailed it

  • @DobesVandermeer
    @DobesVandermeer 2 года назад

    One concern I have about the one project, one owner, multiple teams is extra communication overhead coordinating work between teams. If you divide responsibilities between teams they can become more of an expert in certain areas and don't have to coordinate with so many people. Any thoughts?

    • @petriheiramo8047
      @petriheiramo8047 2 года назад +1

      There's so much communication overhead in current organisations that we can move some of that to inter-team communications without adding anything :). But, there's a few things here I can touch in "more concrete" comments. First, "I" don't divide the responsibilities, I'd let the teams divide (and re-divide as needed) them. I'm sure one big concern they would have is specifically the amount of coordination overhead. So I'd let them decide it. This of course requires that all teams have a view of the whole and understand the purpose of what we're doing. So I'd make sure the PO and the management share that info and ensure teams understand it. Given that I know how much team members usually hate unnecessary meetings and want to get things done, I'm pretty sure they'll figure out good ways. This, of course, doesn't have to happen entirely without any guidance or support.
      The larger the organisation, the more likely some amount of team specialization is. And that's not a bad thing in and of itself. Specialization allows efficiency of action, in many situations. It becomes bad if it calcifies and becomes a power play, or it's used as an excuse to not do something that needs to be done. Even within a team, we have specialists - someone who is good at coding, someone good at testing, and so on - but they still work towards a single goal and are allowed to change and optimize the way they work to be as effective as possible. The goal would be to have similar collaboration between teams.

    • @ChrisAthanas
      @ChrisAthanas Год назад +1

      None of this is taught in any public school so the big issue is getting top down buy-in of the scrum way of working. Most business people do not understand any of this and will try the relabel roles game and revert back to waterfall with extra steps

  • @RJBentlej
    @RJBentlej 5 лет назад +2

    10/10

  • @secretagent314
    @secretagent314 3 года назад +1

    Dear Michael,
    thank you for this clip that invites to reflect the own product owner role.
    I have a question w.r.t. the conclusion of your video:
    What do you think, how many people can share the role of this PO at the end of the video?
    In our project we are around 30 POs and architects that share this role - and it's not manageable. We are so inefficient!

    • @MichaelJamesSeattle
      @MichaelJamesSeattle  3 года назад +3

      One.

    • @RichardKernNZ
      @RichardKernNZ 2 года назад

      @@MichaelJamesSeattle One per product, or one per org?

    • @petriheiramo8047
      @petriheiramo8047 2 года назад

      @@RichardKernNZ One per product. But the point is, one person who ultimately decides and has the ultimate authority. They may be lots of people supporting that work. But they are stakeholders or team members, not PO's. Smart PO's leverage that support and don't try to decide on every single decision. They just make sure the ship is sailing to the right destination (goal and alignment).

  • @MichaelJamesSeattle
    @MichaelJamesSeattle  3 года назад

    Related ruclips.net/video/WEFla0oe4sk/видео.html

  • @MichaelJamesSeattle
    @MichaelJamesSeattle  5 лет назад

    Related video from product development expert Ellen Gottesdiener ruclips.net/video/KawTjfX--Eg/видео.html