A specialist is a man who knows more and more about less and less.

—William J. Mayo, American Physician [1]

Shared Services

Shared Services represents the specialty roles, people, and services required for the success of an ART or Solution Train, but that are not dedicated full-time.

Because these individuals have specialized skills—often single-sourced and typically quite busy—each Agile Release Train (ART) and Solution Train must plan to engage the shared services personnel it needs when it needs them.

Details

ARTs and, by extension, Solution Trains assemble all the necessary knowledge, skills, and abilities needed to deliver value. Without it, teams can be blocked waiting for information or decisions that delay value delivery. However, it’s impossible to devote some specialty functions to a single ART. There may be a shortage of a particular skill available or it is simply impractical to staff all ARTs with that expertise. Also, the needs of the ART may fluctuate, making full-time commitment impractical. To address this, Shared Services support development by quickly focusing specialty expertise on the areas of the system or Solution that require unique knowledge and skills.

In some cases, the effort may contribute directly to the Architectural Runway (for example, security and information architecture) that supports new Feature or Capability development. In others, the effort can trail core development a bit (for example, customer training, localizations, and compliance audits). In some cases, merely being supportive and reactive quickly is sufficient. These services on the trains ensure their work is performed early and in smaller batches to make delivery more predictable and provide team feedback.

In either case, the programs will struggle to meet their objectives without timely support and synchronization. Shared Services may participate full-time with a single ART or distribute their efforts across multiple ARTs across the Enterprise. And in some instances, they may embed themselves directly on a single Agile Team for a short time. In all cases, they commit with the teams and ARTs to the shared goals and PI Objectives.

Shared Services often include people with the following types of specialized skills:

  • Application/web portal management
  • Site reliability engineering
  • DevOps specialists
  • Configuration management
  • Data modeling, data engineering, and database support
  • End-user training
  • Enterprise architecture
  • Information architecture
  • Infrastructure and tools management
  • Internationalization and localization support
  • IT Service Management (ITSM) and deployment operations
  • Security specialist (InfoSec)
  • Regulatory and compliance
  • System QA and exploratory testing
  • Technical writers

Responsibilities

Depending on the type of service they provide, Shared Services personnel may engage in the following type of activities:

  • Participating in PI Planning and Pre-PI Planning for Solution Trains.
  • Contributing requirements where necessary, adding to Solution Intent and taking ownership of their portion of dependent backlog items.
  • Collaborating with Agile teams to fulfill the dependencies that occur during PI execution.
  • Participating in System Demos, Solution Demos, and Inspect and Adapt ( I&A) workshops, when appropriate, as many improvement backlog items may reflect challenges with the availability of specialized skills and dependencies.

Occasionally, members of Shared Services may choose to operate as a single team. In this case, they would iterate on the same cadence as the ARTs and work like any other Agile team.

Patterns of Shared Services

Beyond the generalized purpose and responsibilities of shared services in SAFe, there are multiple patterns for how Shared Services are deployed in the organization, depending on the context. The following paragraphs describe three common patterns observed in the field.

Centralized Services

The most frequently observed use of Shared Services is when one or more individuals with specialized skills from a functional department provide periodic support to an ART. For example, if an ART needs to acquire products or services from a supplier, they will likely need focused help from procurement, legal, and accounting. Launching a new or updated product will require various specialized skills from the marketing department to support the release process. Even highly specialized technical skills such as enterprise data architecture may be managed centrally, and support provided to ARTs as a Shared Service.

Embedding in Agile Teams

Shared Services personnel may temporarily become part of an Agile team for short periods. In doing so, they experience the collaborative, quick, and high-quality way Agile teams produce products. It also accelerates the larger teams-of-Agile-teams dynamic that—only by acting together—can they deliver enterprise value. Embedding also transfers knowledge rapidly and in real-time, reducing delays and dependencies on specialized skills. For example, one government customer brought in front-line personnel from the field on six-month temporary duty assignments to serve as embedded Product Owners in the Agile teams. That action accelerated the development of the next-generation software that those agents would use when the solution was released.

Shared Services as Enabling Teams

In many cases, Shared Services personnel may operate perpetually as a shared service due to the nature of their specialized services. However, as Agile Teams grow and mature, and as responsibility for delivery across the whole value stream moves to teams and trains, shared services may appear as perpetual dependencies and bottlenecks to flow.

Another approach is configuring Shared Services teams as enablement teams (see applying Team Topologies in SAFe). As such, they are chartered with teaching and enabling Agile teams and ARTs the specialized technologies, services, and practices they have been providing. One example of this pattern is teams of site reliability engineers (SREs) equipping Agile teams with the skills and practices necessary to assure site reliability themselves.

Mastering this approach is a hallmark of business agility as it moves authority and responsibility for full value stream product and solution delivery to the teams and trains who deserve that charter.

Tips for Successful Application of Shared Services

The following is a short list of tips for successfully applying the concept of Shared Services in SAFe enterprises.

  • Use Shared Services when specific skills are truly not needed on an ART full-time (if the skill is required full-time, staff the ART accordingly)
  • Ensure Shared Services is a full participant in ART events, working agreements, DoD, standards, and norms
  • Encourage Shared Services members to share their expertise freely to build T-shaped skills on the Agile teams
  • Share wins with other Shared Services to support their relentless improvement efforts
  • Prioritize Shared Services contributions to unblock value streams

 


Learn More

[1] Mayo, William J. Reader’s Digest, 1927.

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.

 

Last update: 16 May 2023