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.
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.
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.
Let me elaborate:
- 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)
- 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
- 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.