Team PO as anti-pattern

In large-scale product development, multiple teams work on one product. Team PO is prevalent for various reasons, but they are anti-patterns. In this article, I try to describe those and provide the leverages.

In Scrum, PO plays an important role in breaking the traditional contract game and improving the collaboration between R&D and business/product. Thus, I first try to learn whether those team POs are from R&D or from business/product, as they represent different reasons and dynamics.

1. Team PO from R&D

Component team

Blog - team PO 1.jpg


B1-loop: Have PO from R&D to accommodate for component team

While adopting Scrum, there is a need for PO. However, component team structure makes it impossible to have real PO from business/product. B1-loop illustrates one common response to this problem - find PO from R&D instead, which fulfills the need, but is a symptomatic solution.

B2-loop: Adopt feature team to enable PO from business/product

B2-loop illustrates another solution, which is to adopt feature team, so that we can find real PO from business/product to work with team. This requires organizational structural change, thus not an easy path, but it is a fundamental solution.

Having PO from R&D removes the immediate tension of not having PO. The R-loop shifts the burden to B1-loop, thus, the status quo of component team is maintained.

Business/Product disengagement

In case of feature team, there are still team POs from R&D but with different reason.

Blog - team PO 2.jpg


This dynamic is basically the same as in one-team Scrum, where business/product does not want to engage in sprint-by-sprint collaboration with R&D and they are still in the mode of contract game. In large-scale product development, it just creates more resistance as the need for having one PO per team requires more business/product people to change.

B1-loop: Have PO from R&D to accommodate for business/product disengagement

B1-loop illustrates the solution of having team PO from R&D. This releases the tension for business/product to engage into sprint-by-sprint collaboration with R&D, but it is a workaround.

B2-loop: Coach business/product to engage

The fundamental solution is coaching them to engage. Once they get used to collaborating with R&D team on sprint basis, e.g. at sprint review, the required change to take PO role becomes smaller thus more likely to happen.

Having PO from R&D makes an excuse for business/product not to engage in sprint-by-sprint collaboration with R&D. The R-loop shifts the burden to B1-loop, and the status quo of contract game is maintained.

2. Team PO from Business/Product

When POs are from business/product, there are two common reasons why every team still has its own PO.

Overload on requirement clarification

When team counts on PO to clarify requirements for them, PO becomes bottleneck and is constrained to feed mostly 1-2 teams.

Blog - team PO 3.jpg


B1-loop: Have team POs handle the workload on requirement clarification

B1-loop illustrates the common solution of having one PO for each team. As the number of stories for one team is limited, PO's workload gets eased.

When team PO focuses on requirement clarification, she essentially takes BA role. In Scrum, BA is part of team, and works as team member. She may still develop speciality on business analysis, but in the meantime she shares the team's common goal and learns other specialities, while other team members learn the speciality of business analysis too. By having a separate team PO role, it creates the extra handoff.

B2-loop: Have team clarify requirement directly with users and stakeholders

The fundamental solution is to let team clarify requirements, especially the details, directly with users and stakeholders. It eases PO's workload and enables one PO to work with multiple teams by focusing on prioritization. This reduces the handoff too.

Having team PO actually makes it harder to get team involved in requirement clarification, as team POs can well manage their workload thus have less perceived need to involve team. The R-loop shifts the burden to B1-loop and stabilizes team PO role.

Specialization on product domain

There are many domains inside a big product. It is a challenge for one PO to develop deep insights in all domains for effective product discovery.

Blog - team PO 4.jpg


B1-loop: Have team POs specialize on product domain

B1-loop illustrates a common solution of having team POs specialize on different domains. This is essentially a response to capability gap. By defining narrower domains, it reduces the required capability.

Specialized team PO often goes with specialized team. In this case, there is not any more shared product backlog with one priority. Much of the product discovery is restricted in each domain and only leads to incremental innovation, while the breakthrough on the whole product is less likely.

B2-loop: Learn to be capable for the whole product

The alternative solution is to develop the capability through learning. We aim to have one PO capable of leading product discovery for the whole product, with the help from teams and domain experts.

In case of LeSS Huge, APO specializes on certain requirement area inside the whole product , but APO is not team PO, as requirement area usually has 4-"8" teams.

These two balancing loops form the archetype of "Eroding goals". As the size of product development grows, it creates more POs with narrow domain focus and fewer POs with whole product focus.

Summary

Team PO in large-scale product development is an anti-pattern to watch for. In case of team POs from R&D, we shall try to break it by adopting feature team and coaching business/product to engage in sprints. In case of team POs from business/product, we shall try to break it by having one PO with the whole product focus while getting help from teams and domain experts on requirement clarification and product discovery.

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