Essential Skills of Effective System Team Product Owners – Part 1

Identifying the Product Owner (PO) for the System Team can sometimes be not as straightforward as it can be for other teams in Agile Release Trains (ARTs). Here we explore what you need to consider to make this a successful role. This is the first of a series of three articles that explore the role of the Product Owner in relation to the System Team and their essential skills.

In the later articles, we will explore:

• Where you might find candidates for the role and how to plan their personal development to excel
• Funding for System Team Product Owners

What is the System Team?

The purpose of a System Team is to provide the specialized skills to support the environment and toolchain needed across the portfolio to perform its work. While some will assume the System Team works at only the Essential Program level (Program level prior to v5.0), the System Team can, and does, work at any level, hence its addition to the spanning palette.

The System Team may also serve multiple ARTs, Solutions, or the Portfolio. Having a System Team is actually optional, but having the capability isn’t. If an ART has the capability to undertake the work the System Team normally handles within the train, then having the dedicated team isn’t needed.

The SAFe website describes the System Team as a specialized Agile Team, which broadly means it will use Scrum or Kanban, just like the teams within an Agile Release Train, and therefore needs the support of a PO, and for scrum teams a Scrum Master. It may support the goal of continuous delivery with enhancing solution integration and solution end-to-end testing too.

More than a testing team

People often read this as, the System Team does integration and system-level testing only. They are not meant to be just a testing team. ARTs, and the teams within them, own the responsibility to deliver integrated end-to-end code. We should only rely on the System Team where the teams cannot do it. This could be where the integration skills are specialized or there is an economic benefit, like economies of scale, that leads the System Team to undertake that work.

The SAFe Fellow Mark Richards, talks about the System Team, “enabling the ownership to be taken by the dev teams rather than doing the work themselves.” This is a useful lens to look through when you read the SAFe guidance on the team’s role. It also helps reduce misconceptions people sometimes take from it.

What does the PO of a System Team need to do?

The PO needs to understand how to improve the environment and toolchain to best support the portfolio achieving the shortest sustainable lead time. They work solely to support the release of value, and don’t just do things for the sake of it. Therefore, the PO needs to understand the performance of the development value streams so they can look to support their optimization with the platforms and toolchain. They keep in mind the balance of the immediate and the longer-term objectives. This sometimes can be a challenge when a support request comes their way.

They are responsible for the story definition, working with the team members during their planning. This is so the team can effectively estimate and sequence the work and ultimately accept the work when complete. Additionally, they collaborate with the POs and PMs within the ART. Like all POs, not only do they serve the team, but they serve the train too.

This collaboration is key during the lead up to the PI planning meeting to understand the demands on the System Team in the upcoming planning increment (PI). During the event itself they help to sequence work to maximize value delivery and, with the Scrum Master, manage the risks and dependencies across teams.

What are their essential skills?

It should go without saying, that the PO of the Systems Team needs a solid grounding in the act of being a Product Owner, like any other PO in the organization. This includes the normal duties and functions which includes but is not limited to:

• How to handle incoming demand
• Document it as stories
• Collaborate with other POs in PO or ART sync meetings
• Prioritization

They should also have a customer focus too, which for the System Team, predominantly is the development teams, but also includes the ART leadership and Business Owners. Like any team, making sure they don’t forget who they serve and why.

More specifically for the System Team, these additional skills are important:

• Value stream mapping capabilities
• Technical understanding of the CI/CD DevOps pipelines and supporting technologies and the toolchain to implement it
• System thinking, understanding their work is to enable the main act, the ART, to deliver value
• An understanding of architecture so they can work with System, Solution or Enterprise Architects

Stay tuned for Part 2, where we discuss who might fit in the role of PO for the System Team, and more.