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

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai