Shared Services and External Services: Partnering to Support ART Flow

The Scaled Agile Framework (SAFe) describes Shared Services as the “specialty roles, people, and services required for the success of an ART or Solution Train, but that are not dedicated full-time.” The Shared Services guidance article provides an extensive list of examples of specialist skills often included in Shared Services. While this list is not exhaustive, it serves as a helpful prompt when considering the needs of a specific Agile Release Train (ART). Most ARTs will only need a subset of these skills. Other specialisations we have seen included in Shared Services include business change, user training, UX/CX and legal. 

Identifying the Need for Shared Services on an ART

One way to identify the Shared Services needs for an ART is to ask the Agile Teams what skills they need access to (that they don’t have) to be able to take a feature from idea to hypothesis evaluated. We like to include questions about external dependencies and subject matter experts in our feature definition workshops (also known as Feature Disco) that occur prior to PI Planning to help inform what capabilities should be considered for inclusion in Shared Services. 

Given the intent of having an ART is to accelerate value delivery, it is worth pressure testing both the ART's level of dependency on these skills and the availability of the people who provide them.  In our view, where there is significant demand for a specific skill, you should attempt to get someone with that skill set dedicated to the ART. 

We consider the level of demand to be significant when the ART indicates it is likely to use more than 60% of an individual’s time. If you get pushback on dedicating someone to the ART as they will be less than 100% utilised by the ART, have the person bring their other work with them onto the ART. In addition to removing a handoff for the ART, you will likely get better visibility of the overall demand for that speciality. For an example of how one customer found this approach “immensely valuable”, check out the PCCW Global case study.

Of course, it is likely there will be people or teams that meet the definition of Shared Services, but they are only needed by the ART on an ad-hoc basis. To distinguish this group from Shared Services we call them External Services as they are external to the ART. 

Forming a Shared Services Team within an ART

If an ART has a quorum of dedicated Shared Services people, we have them form an agile team on the ART. (Similar guidance was added to SAFe as part of the 6.0 update). In practice, we have Shared Services teams on most of our ARTs. The intent is to ensure every person on the ART belongs to a team; after all, it is no fun and rather lonely being on an island.  

Ideally, this team has a Scrum Master; this is sometimes a team member or something the ART coordinator takes on. (Note: ART coordinator is not a formal SAFe role but one we frequently see included in ARTs.) 

___________________________________________________________________________

What is an ART Coordinator?

Program Managers who lead large programs are often supported by Program Coordinators. While an RTE is not a Program Manager, the breadth of the role is likely equivalent, so it is often a good choice to have an ART Coordinator to provide some logistical support to prevent the RTE, Product Manager and System Architect from drowning. 

__________________________________________________________________________

Participation of Shared Services & External Services in PI Planning

Practically, the Shared Services team is a team on the ART and an active participant in ART and Team events. When it comes to  PI Planning, Shared Services is unlikely to have its own backlog of features or a Product Owner. Instead, their work is identified as the agile teams' breakdown their features.  The team should use the ART Backlog priority order as informed by WSJF and the other agile teams on the ART will accept the dependency stories. They will still need to build a plan, write PI Objectives, and participate in the confidence vote. 

During PI Planning, the Agile Teams should include the relevant Shared Services folk in their feature decomposition discussions. If there is likely to be a lot of demand for people with a specific specialisation, it can be helpful to create a timetable to ensure all the teams get access to the specialist they are reliant on. Ideally, these specialists will have also been made aware of the feature, and they helped the team prior to PI Planning to get the feature the Definition of Ready (see feature disco) so they can jump in and help rather than slow the teams down with context-related questions.

External Services will also need to attend PI Planning and plot their dependencies on their own swim lane on the ART Planning Board. However, they will execute and deliver outside the ART. 

Integrating Shared Services and External Services During PI Execution

During PI execution, the Shared Services team members tend to attend specific agile team daily syncs rather than a Shared Services team sync. Some will also attend ART Sync. They also participate in team Iteration Reviews and support the System Demo. This pattern can also be true for some External Services depending on their way of working. It is not uncommon for External Services to act more like a supplier if they are not currently using SAFe or Agile. 

We see the use of Shared Services and External Services as enablers for ART flow. By identifying the necessary specialist skills and ensuring their availability, ART's can significantly reduce external dependencies and enhance their efficiency. Forming a dedicated Shared Services team within the ART fosters collaboration and ensures that all members are fully integrated into the process. Acknowledging External Services as teams or people with less day-to-day involvement in the ART results in fewer expectation mismatches.  Depending on the ART's context, both groups will likely play a vital role in filling in the gaps and ensuring that the ART teams have the necessary expertise to progress features through the Continuous Delivery Pipeline with minimal handoffs and delays.