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

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

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

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