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 of this blog series explored the System Team, the PO role, and essential skills. Part 2 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 looking to them to find the person to fill the PO role. Firstly this is dumping the problem on someone who might not be able to resolve it. Secondly, it doesn’t support SAFe principle 2, Apply Systems Thinking.
As we have already 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 to pay for the PO role and wider team, but it can simply come from the value stream funding. The cost can also be shared 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 as to 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 decentralize decision making and let people self-organize, it’s a great way to solve this. However you might need a more structured process depending on the culture of the organization.
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 into the main Product Management function in the organization, 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.