SAFe System Team and their Product Owner, 4 patterns to be successful in choosing the right person
Identifying the Product Owner for a Scaled Agile Framework (SAFe) 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 anti-patterns to be aware of and some quick wins.
What is a SAFe System Team?
The purpose of the System Team(s) in SAFe is to provide the specialised skills to support the environment and toolchain needed across the portfolio to perform its work. They are pivotal enablers of benefiting from DevOps and Value Stream Management. 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 by 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?
A System Team Product Owner needs to understand how the environment and toolchain can be improved to best support the portfolio in 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 program 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 include how to handle incoming demand, documenting 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.
Where might a systems team PO come from?
Being they are a PO like any other when identifying candidates for this role, you may find your existing product management function doesn’t have the technical product domain skills to effectively work within the team. This can naturally lead people to look within the technical domain, but this means they won’t likely have the PO skills needed.
There are four patterns that we have seen, each has its own pros and cons, and you will need to make your own trade-off decision in your context. For each, you will find an outline of the considerations you need to make.
- From the existing Product Management function
- Team Leader or Senior Team Member
- Business Analyst or Architect
- Source within the team
From the existing Product Management function
Taking them from the product management function means they will know the role, but potentially struggle with the ‘product’. Here you have a captain who knows where to go but doesn’t know how to get there. They will have to rely heavily on the team to create stories and find solutions. This will have an impact on their capacity to deliver while supporting the new PO. You may also find that your existing PO community does not have a personal interest in this domain and doesn’t see it as a product they want to work with.
On the flip side, the existing relationships they have with other POs can support the adoption of new capabilities and provide a fast feedback loop of what the other teams are doing. Exploiting these relationships can give positive results and improved alignment.
This choice can be one of the hardest to implement, as the learning curve can be high if the PO doesn’t have the technical skills necessary.
Development opportunities include:
- SAFe Agile Software Engineering course
- SAFe DevOps
- Joining Communities of Practice from the engineering disciplines
Team Leader or Senior Team Member
Some teams have sourced the PO from their team leader or senior team member roles, which means they have the technical skills, but they will be lacking in the PO skills. Also being the ex-lead or senior dev (or worst wearing two hats), means the job of the Scrum Master in the team can be challenged. Team members might find confusion over if they should take their lead from the ex-leader owing to their previous role and stature in the team, or the Scrum Master who is coaching them to improve.
Development opportunities include:
- SAFe PO/PM course
- Agile Product Management
- Getting a PO peer mentor
- Working with a Scrum Master to coach them on servant leadership
Business Analyst or Architect
You might find a Business Analyst (BA) or Architect (potentially System or Solution) who already has some of the technical skills, and is often the case for BAs, has some PO-type skills too and therefore has to work at being a PO and improve their technical skills.
This pattern of using the System Architect is one Em Campbell-Pretty, and Adrienne L Wilson echoes in their book, The Art of Avoiding a Train Wreck. They outline that, “this should help keep the System Architect grounded in the reality of the health of the system that Agile teams are working in.”
Potentially, you could stretch this pattern and look wider in the enterprise to someone from within release or service management. They could help bridge the needs of the delivery teams with those processes and organisational structures needed to release to production.
Development opportunities include:
- SAFe PO/PM course
- Agile Product Management
- SAFe DevOps
- Pairing with POs and technical team members.
Source within the team
One possibility is to look within the team, is there a natural person to take on this role? Someone might want to pick up this role; the same applies to the Scrum Master role. If there isn’t a taker for this, look wider than the team and see if there is a stakeholder that we can look to do this role.
Development opportunities include:
- SAFe PO/PM course
- Agile Product Management
Across the board, anyone who takes on this role, may wish to consider the following:
- The DevOps Handbook – practical guidance on DevOps tooling, culture, metrics etc
- Broaden awareness of the technology – checkout the annual DevOps conference, annual AWS conference
- Meetups – There are groups that meet to discuss AWS, Azure, CICD etc
- Establishing a CoP within the organisation sharing knowledge/skills etc
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 on 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 are 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 about who are their taskmasters.
So remember, it’s not about the budget or reporting structure!
In Summary
In closing, regardless of who 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 into the main Product Management function in the organisation, although that is an option. If they do not report into it, the practice lead lives within that function, so they have a responsibility to work together on standards of the capability.
Thank you to my reviewers, Darren Wilmshurst, Virpi Rowe, Sukie Kang, Kay Overend, Mark Richards and Neru Obhrai.
