When we talk about Servant Leadership the first role that comes to our mind is the Scrum Master. It is the first role ever, of its 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 nowadays. 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 an 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 organization, where they believe it means “maximizing 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 of course, their job is to serve the organization, but in very different ways.
For a Product Owner, Maximising Value ≠ Maximising Output
A typical Product Owner will prioritize 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 a 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. A typical phrase in 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 favor 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 fail 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 “maximize the value” from any form of output. PO should know 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 in 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 need to think that focusing on where to add a comma or semicolon.
- If a PO has 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 in 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 organization.
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. The reason why we have Scrum Masters to neutralize 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.
blogagility.com 
SCRUM Masters rarely possess the wisdom and maturity idealized in Agile guidelines, but, in theory, they are supposed to be the coaches of the group. In coaching the servant-first dynamic, one has to contend with fear of failure and fear of condemnation coming from stakeholders and HR managers. At the end of the day, regardless of any of these ideal concepts, people will become fixated on pleasing the one who does their performance review.
The only way to coach servanthood in that context is to do so, iteratively, through retrospectives. This is the notion that Lisa Adkins presents in her tree illustration where the five SCRUM values reside at the roots of the tree and the desired fruit is in the canopy of the tree. If a coach is good, they can help a team self-diagnose their deficits, their lacking of these fruits (and other deficits not necessarily in that tree illustration), the missing of their goals, etc. The masterful SCRUM master can lead them to reflect not only on the 5 SCRUM values that might be deficient or missing altogether at the roots, but to also possibly other root causes that do not fit so nicely in the little 5 values model.
Once the team begins to own responsibility to produce that fruit, regardless of the pressures that are coming at them systemically (and otherwise), the more they can begin to let go of fear as the primary driver and begin to serve one another. This would apply to the Product Owner as much as anyone else on the team.
LikeLike