Trust between PO and team

In my recent CSPO (Certified Scrum Product Owner) course, we had a discussion exercise about how PO breaks and/or gains trust from team. I'd like to share some points so that any PO can keep those in mind while working with the team.


How does PO break trust from team?


  • push team to commit

Team pulls the right amount of work into next sprint. When PO pushes team to commit, he breaks trust from team.


  • change inside the sprint

Sprint is closed to change, unless PO abnormally terminates it, which should be very rare. When PO regularly initiates change inside the sprint, he breaks trust from team.


  • can't clarify the requirement

PO works with team to clarify the requirements. When PO takes requirements from somewhere with second-hand, and could not clarify questions or give examples, he breaks trust from team.


  • can't state the value

Even when PO can clarify what, but if he can not state why, he breaks trust from team.


  • not available during the sprint

PO works with team not only during sprint planning and review, but also throughout the sprint. If PO treats himself as "customer", and disappears during the sprint, he breaks trust from team.


  • no feedback for delivered features

After product increments are delivered, PO is supposed to collect the feedback from customers and users and share it with team. If team never hears back from PO about the delivered features, PO breaks trust from team.


  • only share good news

If PO selectively shares back to team, with only good news, which demonstrates his good work in defining the product, while PO hides bad news and decisions he made earlier, which he feels embarrassing. When PO does this and team finds it out, PO breaks trust from team.


  • estimate size for team

Team estimates size in planning. When PO does it for team, even says that it is just for their reference, he breaks trust from team.


  • monitor the progress within the sprint

Team self-organizes to deliver the sprint goal, which includes monitoring the progress by themselves. Once team does that and micro-manages the progress within the sprint, he breaks trust from team.


  • decide how for team

Team decides how. If PO enters into the implementation domain and interferes team from self-organizing on how, he breaks trust from team.


Likewise, you may do the same exercise from team perspective. Here is some of my initial thoughts.


How does team break trust from PO?


  • partially done work

Waterfall team often delivers partially done work by the end of the sprint. When that happens, PO has difficulty to know where we are and loses the flexibility to adapt in next sprint, team breaks trust from PO.


  • hide the undone work

Team states that the work is done, while it is not. Later, PO finds it out. Team breaks trust from PO.


  • deliver with bad quality

When team has many production defects after delivery or accumulates technical debts, their velocity on new features gets lower over time. Team breaks the trust from PO.


  • velocity not stabilized

PO uses velocity for long-term planning. While velocity varies greatly, PO loses predictability. When team's velocity does not get stabilized after a while, team breaks trust from PO.


  • not deliver the committed work

When team consistently delivers the committed work, it gains trust from PO. While software development has inherent uncertainty, if team regularly could not deliver the committed work, it breaks trust from PO.


  • under-commit for safety

On the contrary, if team overemphasize the safety in delivering their commitment, it does not set challenging goal for themselves, team breaks trust from PO.


  • blame PO for requirement defects

Requirement clarification is a collaborative activity. When we receive requirement defects, instead of collaboratively seeking improvement, if team blames PO for those and runs away, it breaks trust from PO.


  • do not support PO for backlog refinement

PO gets support from team in backlog refinement or product discovery. When team only focuses on the current sprint and leaves PO alone for future preparation, it breaks trust from PO.


I believe that you would come up with more ideas that will help PO and team gain and maintain trust from each other. Hope that these lists provide a useful start.

Read more

จักระกับระบบประสาท

จักระกับระบบประสาท

ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai