The Necessity for a Product Group Owner

There are a few teams each having its own PO (Product Owner), is there a need for an overarching PGO (Product Group Owner)?

Blog - PGO 1.jpg

I have recently encountered two different configurations, and let's explore them one by one.

1. Teams are responsible for elements in the product

Blog - PGO 2.jpg

In the above configuration, each team is only responsible for elements in the product, but not the complete product. Is there a need for a PGO?

Blog - PGO 3.jpg

Those element teams are essentially component teams. Their POs are not real POs, as they are not able to maximize customer and business value on their own. So, the answer would be yes - an overarching PGO is necessary for the complete product. Meanwhile, those POs should not exist. Then, isn't the PGO really the PO? Yes, indeed. We don't need a PGO, but a real PO. Therefore, in this configuration, there is one PO with three element teams (illustrated in the above diagram). While there is one product backlog for the complete product, however, as those teams can only develop elements, some product backlog items will inevitably be across teams. You may consider an alternative structure - feature team.

2. Teams are responsible for complete products

Blog - PGO 4.jpg

In the above configuration, each team is responsible for a complete product. The difference from the last configuration is that POs here are responsible for maximizing customer and business value on their own. Is there a need for a PGO?

Blog - PGO 5.jpg

The first answer would be no (illustrated in the above diagram). Each PO works with one team to develop own product independently. There is no need for an overarching PGO, but only three POs working in parallel.

Blog - PGO 6.jpg

What if we have five teams, how many teams should work on each product? Each PO can't decide on its own. It is possible that they form a committee to deal with this kind of portfolio question, but it is more common to introduce an overarching role to decide. So, the second answer would be yes (illustrated in the above diagram). The PGO is essentially a product portfolio manager. He together with POs regularly reviews the portfolio and adapts. For instance, the portfolio this year is: product 1/two teams, product 2/two teams, product 3/one team; but the portfolio next year becomes: product 1/three teams, product 2/one team, product 3/one team. Within each product, POs still have the complete authority to decide the work priority and are responsible for maximizing value.

Blog - PGO 7.jpg

When those portfolio decisions need to happen more frequently, we can move toward one shared product backlog, so as to embrace the change on sprint basis. Then, the third answer would be yes - an overarching PGO is necessary for the overall product group. Do we still need those POs? Because there is only one product backlog and one priority, we don't. In LeSS, this is called expanding the product definition. Product group becomes the expanded product. The PGO really is the PO (illustrated in the above diagram).

One last question, what is product group? In some cases, those products in the product group sell independently. Product group is just a group of independent products, but it optimizes the value of the whole group by prioritizing together within the product group. In other cases, the product group sells the system, consisting of those products. In fact, each product becomes an element in the complete system. This goes back to the first configuration.

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