Accidental adversaries

I recently attended a sprint review. It went on like this. PO checked every acceptance criteria in details, and criticized as much as he could; while team defended and demanded for acceptance, as much as they could. I heard comments as below.


  • From team, "we will only work on what's in acceptance criteria, if you want this, you need to include it in the acceptance criteria. It's your problem if you don't."
  • From PO, "But this should be common sense. Ok, I shall write more details into acceptance criteria, otherwise, you guys will just argue for acceptance."


PO and team are supposed to embody agile value "customer collaboration over contract negotiation". However, it looked as if they were in win-lose situation. How come?


System archetype "Accidental adversaries" well captures the dynamic.


Accidental adversaries.jpg

There are 2 reinforcing loops and 2 balancing loops involved.


  1. It begins with the outer reinforcing loop. PO is responsible for the success of the product, and is capable of defining the right product. While team is responsible for the product delivery, and is capable of building the right product. They benefit a lot from collaboration. When PO invites team into the collaboration on defining the product, team understands why to build, then, what to build deeply. When team delivers the right product to customers, they are more motivated in contributing further on product specification. This in turn helps PO succeed in defining the right product.
  2. At some point, bad cases occurred. For example, product missed some functionality because team thought that it would not be necessary. Customers complained and escalated, and PO got blamed for missing the specification. PO tried to improve by writing detailed acceptance criteria for team, then, strictly checking the written criteria for acceptance. They thought that this practice gave them the control necessary to get the right product. This forms the balancing loop in the upper left.
  3. However, this practice generated the un-intended consequence. When PO declined team's delivery, team's capability was evaluated as poor, and team was hurt. Thus, to fix it, team asked acceptance criteria from PO, blindly followed the written criteria and demanded acceptance based on what's there. This forms the balancing loop in the lower right.
  4. When team succeeds in defending the acceptance, it becomes PO's failure in defining the right product. To deal with this, PO focuses more on the details in acceptance criteria and criticizes the sprint outcome more. This in turn caused team to become more defensive. This forms the reinforcing loop in the middle.


Even though from PO and team's own perspective, what they are doing both make perfect sense, PO and team become accidental adversaries over time. The focus shifts from customer collaboration to contract negotiation, and from improving to blaming.


What are strategies for leverage in this situation?


  • Understand each other's behavior, i.e. their balancing loops, and realize that what they are doing makes sense from their own point of view, and the obstruction to each other's success is unintended. The problem is not caused by people, but by system.
  • Break the middle reinforcing loop by stopping the evaluation for both PO and team based on acceptance criteria and acceptance, i.e. if it is declined, it is team's problem; and if it is accepted but customer is not satisfied, it is PO's problem. Stop the blaming first.
  • Instead, strengthen the outer reinforcing loop by aligning both to the common higher level goal - customer gets the right product. Promote solving the problem and, more importantly, improving together, over blaming each other. When team does not deliver the right product, PO asks team how he can help team understand better; when PO does not define the right product, team asks PO how they can contribute. PO and team are on the same Scrum team and collaborate to achieve the common goal.

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