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

จักระกับระบบประสาท

จักระกับระบบประสาท

ครูณาส่งหนังสือที่ครูแปล ชื่อ 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