Team Leader vs Product Owner and ScrumMaster for component team

(Originally published by Lv Yi on June 3, 2018)

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

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, it is convenient to just use them. However, without organizational redesign, you would end up with fake Scrum.

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

Here is the starting point.

Let me clarify some terms I use here:

• Features are requirements for the product. They are customer centric and associated with business value.
• Component requirements are requirements for the component. 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 is held accountable for delivery of the component work.

Fake Scrum with team PO

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

Of course we introduce the roles of SM and PO, right? As there used to be one TL, I have seen two common arrangements:

1. TL becomes the PO, who is a team PO as well as a fake PO, as he is clearly not responsible for maximizing value of the product. Another person is found to fill the SM role.
2. TL becomes the SM. Another person is found to fill the team PO role.

Usually, regardless of whether the TL becomes the PO or SM, the delivery accountability is still kept with the TL.

Those are good progress. However, in both cases, focus on the component misses the most important point behind real Scrum – maximizing the value through inspection and adaptation based on features and whole product perspective. Therefore, this is fake Scrum with a team PO.

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 focus to the product and features, and 3) advocate for organizational redesign.

Let me elaborate:

1. Do fake Scrum on the component
   • consolidate all component work and prioritize (i.e. what the fake PO does)
   • coach the team to self-organize for delivering the component (i.e. what the SM does)
2. Shift 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 features
   • coach the real PO to inspect & adapt on the product
3. Advocate for organizational redesign
   • prepare with cross-learning and technical excellence
   • spread the knowledge and experience on organizational redesign towards feature teams

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 and creation of feature teams, the team would work directly with the real PO, and it would take end-to-end responsibility for feature delivery. Eventually, the TL would be replaced by a 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 a component team, TL will do.