Seeing the system dynamic: 1 vs. n product owners

I thought that this choice was essentially the same as the choice of 1 vs. n Product Backlog. When I examine more, I find it worthwhile to write it as a separate topic. As the two most popular scaling frameworks - SAFe and LeSS, they made different choices on this. ART in SAFe and LeSS (up to 8 teams) in LeSS are comparable in size. In ART, there are product manager and team POs; while in LeSS, there is only one PO working with all teams. In this article, we shall explore the dynamic around having 1 vs. n POs.

In the description of ART in SAFe, it states the reason of having team POs.

"At scale, a single person cannot handle both product and market strategy while also being dedicated to an Agile Team. Therefore, the 'PM/PO' team steers the train together."

Let's explore the dynamics of why doing so and what consequences it causes.

Prioritization over Clarification

The below CLD illustrates the dynamic about introducing multiple POs to share the workload of requirement clarification.

Organize people - 1 vs n PO - 1.png

Introducing multiple POs as a solution to reduce the workload of requirement clarification by one PO is reflected by B1-loop, which can read like this:

  • Higher workload of clarifying requirements by one PO
  • More POs
  • Lower workload of clarifying requirements by one PO

Behind the solution, there is a common misunderstanding about PO solely responsible for requirement clarification. In one-team Scrum, it is more a matter of choice, as described in Scrum guide.

"The Product Owner may do the above work, or have the Development Team do it."

The above work includes requirement clarification.

While in multiple-team Scrum, it is more a necessity if we would like to enable one PO to work with multiple teams, as described in LeSS.

"A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, he encourages and helps the teams enter into a direct conversation with true users and customers for clarification. He acts as a connector, not an intermediary."

This alternative solution is reflected by B2-loop, which can read like this:

  • Higher workload of clarifying requirements by one PO
  • More participation on requirement clarification by team
  • Stronger ability of working with customers by team / Richer business domain knowledge by team
  • Lower workload of clarifying requirements by one PO

The R-loop explains why it is so common to stick with multiple POs. It can read like this:

  • Higher workload of clarifying requirements by one PO
  • More POs
  • More dependence on POs
  • Less participation on requirement clarification by team
  • Weaker ability of working with customers / Poorer business domain knowledge by team
  • Higher workload of clarifying requirements by one PO
  • More POs

If you have read the previous blogs in this series, you must have recognized the system archetype of "shifting the burden" here.

Status Quo of Contract Game

The below CLD illustrates the dynamic about introducing multiple POs from R&D to accommodate the change resistance on business side.

Organize people - 1 vs n PO - 2.png

Traditional way of working between business and R&D is through contract game. Business and R&D negotiate a contract for the release, then, business leaves R&D to deliver the contract. There was no sprint-based collaboration between them before adopting Agile. It means more change needed on business side when you want to have more POs. The resistance ensues and more POs in R&D are created as a result. This solves the resistance problem meanwhile fulfills the need to have POs. The status quo is maintained.

The B1-loop is the quick solution, which can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more POs in R&D introduced
  • the less change needed on business side

The B2-loop is the fundamental solution, which can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more coaching for business
  • the more collaboration introduced between team and business (either as POs or as stakeholders, but the key is to collaborate sprint by sprint)
  • the more value it creates and the more flexibility it creates
  • the less change needed on business side

The R-loop explains why it is so easy to revert back to status quo. It can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more POs in R&D introduced
  • the less collaboration between team and business (as PO-team collaboration becomes internal for R&D)
  • the less value it creates and the less flexibility it creates
  • the more change needed on business side

Again, you see the system archetype of "shifting the burden".

Conclusion

I have seen two common setups when having multiple POs for one product.

In many Internet companies, those team POs are product managers at the low level. They are working mainly on tactical level, not much on strategic level. When they feed teams with detailed specification and UI sketches, the level of team engagement in product discovery is low. This not only misses the opportunity for team to contribute, but also creates barrier to reach shared understanding for delivery.

In more traditional industries, it is common to introduce team POs inside R&D. When they are focused on requirement clarification, they essentially regress to traditional BAs. There are many arguments against BA role, and my favorite is the keynote from Martin Fowler and Dan North in QCon London 2007. In short, "bridges are better than ferrymen".

Be aware of the consequences when you choose to have multiple POs.

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