Explore PO team

PO (Product Owner) is defined as single person in Scrum. However, for various reasons, in practice a team may be formed to fulfill the role of PO. I am using the term of team rather freely, strictly speaking, some of them are only working groups. I'd like to explore different types of PO teams, and hopefully generate insights for you to use while designing your PO team.


Types of PO teams


Here's the main types of PO teams I have encountered.


  • PO with supporters

This is probably not considered as a team, since it is normal that PO as a single person needs to collaborate with others such as domain experts, business stakeholders, and the development team. There is certainly team work here, however, to large extent, it is close to the surgical team described in "The Mythical Man-Month" book by Fred Brooks. I am now talking about the PO work - define the right product, not the whole product development.


  • PO with APOs

In large-scale Scrum context, PO together with APOs (see details from LeSS introduction) form a PO team. This is similar to most management team. Each APO is accountable for its own area, meanwhile serving as team member in PO team. The PO is the leader of PO team.


  • Product discovery team

In dual-track Scrum, product discovery is done by a team collaboratively - "the product manager, designer and lead engineer are working together, side-by-side, to create and validate backlog items." It somewhat implies that product manager (or PO in Scrum) still leads the team, but the members work more interdependently as peers.


  • Value team

Value team, introduced by Ahmed Sidky in his Agile 2014 session, in many ways is similar to product discovery team. The composition of the team has a bit different focus. Value team seems accommodating more traditional roles, while i prefer the product focus in product discovery team. However, I view the emphasis of facilitator role in value team as an important addition. It highlights 3 important aspects regarding value team roles - ownership of vision, facilitation of team, accountability for results. I see that two of them (ownership of vision  and accountability for results) belong to PO, while SM should facilitate value team (Ahmed has a different view on this). In this understanding, PO seems still taking somewhat leader role in value team.


New type of PO team


If we view discovery and delivery as two sides of product development, and now look at product discovery team and product delivery team, we may wonder why we define a leader for product discovery team, while we don't for product delivery team. If it is possible to have no leader in self-organizing delivery team (aka development team in Scrum), why don't we abandon the idea of defining one leader (i.e. PO) in discovery team? Instead, we create a self-organizing PO team without one defined leader. SM has the responsibility to coach PO in Scrum, while in this setup, SM facilitates and coaches the PO team (aka product discovery team, or value team), in addition to the development team.


Would the new type of PO team work well? This could certainly be controversial. I am listing a few points to trigger the debate.


  • having one PO helps more efficient decision making, but efficient decision making is possible with self-organizing development team.
  • product discovery is more divergent than product delivery, but there could be much divergence in finding architecture solutions too.
  • there is often one leader behind successful products, but successful products where a group of people stand behind exist too.
  • the cases of having group behind successful products are rarer and more accidental, but is it because there has been lack of facilitation and coaching in making the group work effectively?
  • we need one person to interface with team, but why is it possible for PO to interface with development team (without leader), while not for development team to work with PO team (without PO as leader)?


If you experiment this type of PO team, I appreciate that you share back the experience.

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