Team Leader vs. Product Owner and ScrumMaster for component team

[Team Leader = TL; Product Owner = PO; ScrumMaster = SM]

The real Scrum requires significant organizational redesign. I have seen two common settings to pilot Scrum: 1) project group and 2) component team, as those are existing structures thus convenient to just use them. However, without organizational redesign, you could not adopt the real Scrum.

In this article, we focus on the setting of component team, and discuss two alternatives before we are ready for organizational redesign to adopt the real Scrum.

Here is the starting point.

Blog - TL vs SM and PO for component team 1.jpg

Let me clarify a few terms I use here:

  • Features are requirements on the product, and they are customer centric and associated with business value
  • Component requirements are requirements on the component, and they are actually tasks from the perspective of the product.
  • Component tasks are internal tasks in the component.

Traditionally, TL is responsible for the component team, and held accountable for the delivery of the component work.

The fake Scrum with team PO

This is what usually happens while adopting Scrum for component team.

Blog - TL vs SM and PO for component team 2.jpg

Of course, we introduce the role of SM and PO, right? As there used to be one TL, I have seen a couple of common arrangements.

  • TL becomes the PO, who is a team PO as well as a fake PO, as he is clearly not responsible maximizing value for the product; and find another person to be the SM
  • TL becomes the SM; find another person to be the team PO.

Usually, regardless of TL becoming PO or SM, the accountability is still kept in the TL.

With Scrum roles in place, 1) team PO creates a fake product backlog for the component, which becomes the single source of the work for the component team; 2) SM coaches team to self-organize in completing the component work.

Those are good progress. However, it misses the most important point behind the real Scrum - maximize the value through inspection and adaptation on the product and features. Therefore, this is the fake Scrum with team PO.

The real "Scrum" with TL

An alternative I would recommend is to keep the TL role but transform the role to 1) do the fake Scrum on the component, 2) shift the focus to the product and features, and 3) advocate for the organizational redesign.

Blog - TL vs SM and PO for component team 3.jpg

Let me elaborate:

  1. do the fake Scrum on the component
  • consolidate all component work and prioritize (i.e. what the fake PO does)
  • coach team to self-organize in delivering the component (i.e. what the SM does)
  1. shift the focus to the product and features
  • connect component work to the product and features
  • connect component team to the real PO
  • coach team to self-organize with other component teams in delivering the feature
  • coach the real PO to inspect & adapt on the product
  1. advocate for the organizational redesign
  • spread the knowledge and experience on organizational redesign to feature team
  • prepare with cross-learning and technical excellence

This approach better follows big ideas behind Scrum, even though Scrum roles are missing. Therefore, this is the real "Scrum" with TL.

Only after the organizational redesign to feature team, the team would work directly with the real PO, and it would take end-to-end responsibility for feature delivery. Eventually, TL would be replaced by SM - a coaching role not responsible for the delivery. That would be the real Scrum.

End note

In fact, TL working this way is well defined in the book "Leading Self-Directed Work Teams". It describes the TL role as a boundary manager. Please do not introduce team PO for component team, and TL will do.

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