In the final installment of articles looking at the role of the Product Owner and the System Team, we explore a common antipattern to watch out for and avoid, and closing thoughts with a quick win if you need to fill the role in a hurry. If you’ve missed the earlier versions, Part 1 that explored the System Team, the PO role and essential skills, and Part 2 which looked at where to find them and their development opportunities.
An antipattern to look out for: focusing on budget ownership or reporting structure
We’ve seen people start their search by asking who is funding or has line control of the System Team, and look to them to find the person to fill the PO role. Firstly this is dumping the problem on someone who might not be best placed to resolve it, and doesn’t support SAFe principle 2, Apply Systems Thinking.
As has already been discussed, the System Team’s goal is to serve the train to support the delivery of value. Yes the team, guided by the PO, might need to do housekeeping like server upgrades and patches, but their focus is always firstly how to serve the portfolio as a whole (not to be confused with the portfolio level).
Yes we need to know how the PO role and wider team is paid for, but it can simply come from the value stream funding, or be a shared cost if the System Team serves multiple trains or value streams. You don’t want the System Teams allegiance to be to a specific department over a train, as this can lead to interference and confusion who are their task masters.
So remember, it’s not about the budget or reporting structure!
In closing, regardless of whoever becomes the Product Owner, they will likely need support and personal development to perform this function well. Put emphasis that this person is just as worthy of coaching support as those within the ARTs themselves.
If you have the opportunity to decentralise decision making and let people self organise to solve this, it’s reported to get great results. However a more structured process might be needed depending on the culture of the organisation.
Remember that there isn’t likely to be a perfect solution, however if your back is up against the wall, and you need to make a decision today, your System Architect isn’t a bad choice.
Also, don’t feel they need to report in to the main Product Management function in the organisation, although that is an option. If they do not report in to it, the practice lead lives within that function, so they have a responsibility to work together on standards of the capability.
If you have had experiences both good or bad in selecting and building the Product Owner role in your System Teams please share them in the comments below.
Thank you to my reviewers, Andrew Sales, Darren Wilmshurst, Virpi Rowe, Sukie Kang, Kay Overend, Mark Richards and Neru Obhrai.