When we talk about Servant Leadership the first role that comes into our mind is the Scrum Master. It is the first role ever, of it’s kind, which was created specifically for the sole purpose to “Serve”. Only if Robert K. Greenleaf was alive until 1998, he would be the happiest person to know that his whole life’s contribution has an effect on a dedicated leadership role; it changed everything especially the way we see management and leadership now-a-days. Then we started seeing the rise of “Agile Coaches” which was created, I guess, to differentiate that servant leadership exists outside Scrum as well in a equally dedicated role.
But this article is not about the Scrum Masters/Agile Coaches or their unbiased contribution to their teams. Today we are focusing on the role Product Owner (PO); the role which is often seen as biased towards “more and more work in less time”. There’s a reason.
According to the Scrum guide – “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team”.
This is often misunderstood by new POs and their organisation, where they believe it means “maximising the output from a development team”. It is not the same and that subtle difference decides if the person is a traditional Product Manager or a Scrum Product Owner. PO serves the development team (explained later) and ofcourse their job is to serve the organisation, but in very different ways.
For a Product Owner, Maximising Value ≠ Maximising Output
A typical Product Owner will prioritise and try to add work items in the Sprint backlog which may not be part of the Sprint Goal. There is nothing wrong with it, sometimes we have to, if we have higher capacity and we need a live bug fixed asap. As long as majority of the work relates to the Goal, we have a focused sprint.
Things start to become gloomy when a PO knows the true capacity of their development team but still try to negotiate to add that “small” Story, in case someone is free. That’s the biased “leader-first” side which overpowers the unbiased “servant-first” side, so that extra work can be shown as an achievement to a stakeholder who is constantly chasing. Typical phrase on these situations is like “If we manage to finish that too, we will make someone very happy when they are not even expecting it”. That’s a trap.
If it gets done, the stakeholder will assume it is not a one time favour and they can pressure anytime to get more work out of the development team, by going through the PO. If it doesn’t get done and the stakeholder finds out they will most probably be annoyed and blame the development team. Both have side effects and not a very good one. Both fails to manage expectations. On top of that, the development team will now feel guilty when it was clearly not their fault.
The trick is to align, orchestrate and trying to link the work items in a way which have a combined value to someone.
Value doesn’t always have to be for the end user. It can be for an internal stakeholder, operational requirements, legislation or something else. PO should fish for opportunities to “maximise the value” from any form of output. PO should known the capacity of the team from empirical evidence collected on past sprints.
Skill levels play a huge role in slowing down or speeding up the outputs, based on the team we are working with. If we have new team members, expecting same speed of development is futile. Know your team, know the people. If they are new and are on the learning phase, plan more Spikes and let them explore bugs raised which will help them learn the domain. It will also help the more experienced members on those domains, by collecting keys facts that can be used on next sprint. It helps everyone to keep the morale up and have a long term benefit.
Product Owner “Serve” the Development Team
As a Product Owner, we have to choose a “leader-first” bias as we are accountable for the product’s success but we can also serve when it matters the most.
- While facilitating the refinement activity, PO focuses on the business value while keeping the known format of “must have”, “nice to have” and “can live without” in their head but never writes them down for negotiation purposes.
- While fleshing out more and more acceptance criterion from all development team members, PO becomes their scribe and does the admin work which liberates the members who needs to think than focusing on where to add a comma or semicolon.
- If a PO have to be part of the discussion, they ask for help from the Scrum Master to do the same. This is where negotiation begins but with a “servant-first” mindset which is backed by empirical evidence or UX decisions.
- After Sprint starts following the planning session, PO serves the development team by being present on all the daily scrums to answer any query they may have. When they do this, they serve. Taking status updates is not a service; it’s an anti-pattern.
- During the work day, PO again serves the team by simply being accessible to them by any mean. Just being there makes all the difference.
- PO serves by not chasing the team members to create a sense of urgency.
- PO serves by creating a big picture for each work and explain how it impacts the end users. Creating enthusiasm and showing the purpose is one of the most underrated skill.
- PO serves them by showing trust on their commitment and being patient even in the most stressful times.
Product Owners are torn between being the “Leader-first” and the “Servant-first”
From above we can see where the true confusion lies and why POs may be torn between two contradictory ways of leadership. PO is accountable for the product success, a single emotional bias can affect the potential ROI. Unless they lead and focus on getting them done fast, it might seem impossible to even finish in time as every work has a cost of delay. We cannot have the “Servant-first” approach all the time with the development team as we are serving an even bigger team, the organisation.
When it’s possible POs can show the “servant-first” side but is it real? May be, may be not. Usually one person cannot be both.
POs will always remain biased towards the product, the goals and faster delivery. Reason why we have Scrum Masters to neutralise that dominance by guarding the development team when needed. Every role on Scrum has a purpose of why they are dedicated, this is one of many.
1 Rule || Simplicity 