Shared services teams always pose peculiar challenges to successful Scaled Agile Framework (SAFe®️) implementations. The nature of their work which is mostly determined by the requests from the other Agile teams on the framework often leads to priority mismanagement, political conflicts and uncontrolled chaos in the system. One of the major issue organizations face is to deal with multiple shared services team under one ART or a solution train.
In this article, we present an approach called “Service Train” to facilitate that scenario. Also, this article will help you in managing the shared service teams in SAFe®️ with service trains.
Get to know more about safe core values.
How to design shared services in SAFe®️ with service trains
SAFe®️ aims to scale-up the agility of multiple teams by aligning them to Agile Release Trains (ART), Solution Trains and Portfolios. Multiple teams deliver in cadence, the results committed to, at various layers viz., Team, Program, Solution and Portfolio. (Refer to the SAFe®️ site for more information)
Scaled Agile Framework (Source: scaledagileframework.com)Tips for shared services Design in SAFe®️ with service trains
Things get trickier when multiple Agile teams started using service trains in SAFe®️ at shared services and Team request the services to the shared services teams. SAFe®️
recommends the operation of the shared services of teams at the ART level but it gets difficult to facilitate them when those teams tend to grow big in numbers.
The simple idea of having all of them at the program level leads to chaos and confusion at times. For example- imagine a team of 30 people trying to help the other teams out. Moreover, when the members of those teams are not generalists, then organizing them by skills would get problematic too.
One workable solution to this problem is to organize all the shared-services teams into a “Service Train” which is similar to the ART but acts as a service pipeline to one or more ARTs. It spreads across multiple ARTs and Solution Trains providing requested services. The teams on this service train may be Scrum or Kanban teams adhering to the SAFe®️ principles and implementing its practices.
While implementing shared service teams in SAFe®️ with service trains, the service teams run their usual cadences (recommended to sync with the ART cadences) and they deliver services to the ARTs continuously on demand. The ART delivery pipelines tie up these deliverables to their own during the continuous integration activities and deliver solutions to the Stakeholders.The service train differs from an ART in the following ways:
- The PI's on the service trains are optional. The teams may opt for sprint to sprint ( Or cadence to cadence ) planning on the Service train. In such cases, all the teams plan the sprints/cadences together.
- There may not be a dedicated “Train Engineer”. The role could be rotating or replaced by a team of facilitators.
- The backlogs of the service teams are generated by the requests of the teams on the ART.
- The metrics on the train are in the context of the metrics of corresponding ARTs.
- Their program board may be linked to one or more program boards of the ARTs.
The service trains come in as valuable constructs as:
- They eliminate the chaos-generating out of having too many service team members at the program level
- Cross-functional teams may be formed around dedicated service areas, so the Agile teams know where to place the requests
- The trains can deliver services to multiple ARTs at the same time - in other words, they are not constrained by the ARTs (Or the Solution trains)
However, there are a few things to watch out for:The team members of Shared services need to grasps the following type of specialized skills:
1. Some traditional leaders may use this as an opportunity to impose the “Matrix Structure” on the teams and misuse this design as a way to break cross-functional teams.
2. There is a scope of the service teams getting siloed, resulting in poor collaboration
3. The service train may become a bottleneck to the ARTs, if it doesn’t run slightly ahead of their schedules.
Skills needed for Shared services
- Agile and Software/Systems Engineering Coaches
- Application/web portal management
- Configuration management
- Data modeling, data engineering, and database support
- Desktop support
- End-user training
- Enterprise architecture
- Information architecture
- Infrastructure and tools management
- Internationalization and localization support
- IT Service Management and deployment operations
- Security specialist (InfoSec)
- System QA and exploratory testing
- Technical Writers
Roles and Responsibilities in Shared services
The shared services employees handle the following roles and responsibilities.
- Participates more actively in Program Increment (PI) planning and pre- and post-PI planning as well.
- Managing the requirements wherever needed, adding to the backlog and taking ownership of that particular task.
- Collaborating with the Agile teams to achieve the Program Increment execution dependencies.
- Actively taking part in the Inspect and Adapt(I&A) workshops, System demos, and Solution demos when any improvement backlog items show challenges with the availability of specialized skills and dependencies on the team.
Generally, the team members of Shared services choose to work as a single team. In such case, the team members iterate on the same cadence because the Agile Release Train (ARTs) work like any other Agile team.
Agile teams need the support of either sustained or transitional specialty expertise. The staff of Shared services might become a part of an Agile team for the shorter duration. During this period, the staff of Shared services not only experience the Agile dynamic but also understands the speed of the development and the quality of the product. It also allows a knowledge transfer decreasing a dependency on specialized skills.