Product Owner is a new role

It is a well-known but still common mistake that many organizations during their Scrum transformation try to map their existing roles such as project managers into Scrum Master role. Recently, i notice that same happens to PO role as well. Not realizing that PO is a new role is as bad as not realizing that SM is a new role. Let's elaborate why.
Starting from PO's responsibility. Here's PO's role definition from Scrum source.

  • Should have a vision for the product.
  • Defines the features of the product, decides on release date and content.
  • Is responsible for the profitability of the product (ROI).
  • Prioritizes features according to market value.
  • Can change features and priority every sprint.
  • Accepts or rejects work results.

The keyword in the above list is ROI, others are necessary but more as means to great product and maximized ROI. When thinking of who shall be PO, I believe that passion for product is the first consideration, since that is the foundation.
A natural but undesired approach to find PO during Scrum transformation is trying to map the existing role to PO role. Let's look at a few common cases of mapping.
Mapping System Engineer (Architect/Business Analyst)
System engineer is a typical role in telecom industry. It is close to a combination of Business Analyst and Architect, working on both requirement analysis and architecture design. The most appealing reason for them to take on PO role is that they have been working on requirements, while PO clarifies requirements with team too. The close relationship with customers makes it an advantage for them to be customer representative. They may innovate on some product aspects, though it may lack the big context.
However, there are drawbacks on this mapping. System engineers are often technology savvy. Even when they work with customers, they tend to push technology solutions, rather than truly listen to customers and understand their problems first. They traditionally care less about ROI, which makes them perfect the system more than necessarily, without creating more value for customers and realizing the cost effect. PO leads release planning and management, while it has traditionally been program/project manager's responsibility. Few system engineers already know how to do that. In waterfall mode, system engineers are usually located in a single functional team, and they communicate via documentation. Chances are, they continue by writing user stories and handing over to team, which breaks the collaboration spirit in Agile development.
Mapping Program/Project Manager
Program/Project manager already does release management, which makes them good candidate for PO in this regard. They normally have better sense of ROI than system engineers. Their skills on risk management helps them manage the release in more predictable way.
However, there are other hurdles to overcome for them. Traditional project manager is control focused. Many of them are good at command and control type of management, while PO works with self-organizing team. PO looks at the unit of PBI, sprint and team, rather than task, day and individual. Project managers need to fight with the tendency of micro-management in order to effectively work with teams. Though project managers manage releases, they focus more on execution, while PO requires the product leadership based on great understanding on customers and constant product innovation through releases.
Mapping Product Manager
Product managers are great source for PO. They are responsible for the profitability of the product and ROI. They work closely with customers, and execute the product leadership by managing the product roadmap and releases.
The major problem for them is the traditional contract game between product management and R&D. They treat release as one unit, set contract in the beginning of the release with R&D, then, go away for future releases. While for PO, the constant collaboration with R&D team and making ROI decisions on sprint basis is the key to reap the benefit of Agile development.
If we look at the main themes appearing in PO role - ROI, product leadership, collaborate with team, release management, really, no existing role in the traditional organization does all of these. PO is a new role! It will certainly lead to problems, if we try to map the existing role to PO role. Telling people that you are PO from now on, while they keep doing what they used to do, does not make them PO.
On the other hand, people with any of the above background may become PO, with certain qualities and skills, as well as the realization that they need to transition to a new role. I have encountered Scrum transformation in several organizations, during which they introduced PO as new role and selected people with different background to fill it. It worked pretty well.

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