Identifying the Product Owner for the System Team can sometimes be not as straightforward as it can be for other teams in Agile Release Trains (ART). 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 explores 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, followed by antipatterns to be aware of and some quick wins.
What is the System Team?
The purpose of the System Team(s) is to provide the specialised 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 it’s 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 guidance article describes the System Team as a specialised Agile Team (https://www.scaledagileframework.com/system-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 Product Owner (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.
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 and we should only rely on the System Team where for good reason the teams can not do it, not because they just do not want to. This could be where the integration skills are specialised 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 and helps reduce misconceptions people sometimes take from it.
What does the PO of a System Team need to do?
They need to understand how the environment and toolchain can be improved 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 optimisation with the platforms and toolchain. They keep in mind the balance of the immediate and the longer term objectives, as this can be challenging when a support request comes their way.
They are responsible for the story definition, working with the team members during their planning 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 PI. During the event itself they help to sequence work to maximise 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 organisation. This includes the normal duties and functions which includes how to handle incoming demand, document it as stories, collaborating with other POs in PO or ART Sync meetings and prioritisation to name a few.
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
Look out for the next instalment next week.
Thank you to my reviewers, Andrew Sales, Darren Wilmshurst, Virpi Rowe, Sukie Kang, Kay Overend, Mark Richards and Neru Obhrai.