Shared Services

My idea of heaven is a great big baked potato and someone to share it with.

—Oprah Winfrey

Shared Services Abstract

Shared Services represent specialty roles that are necessary for success of an Agile Release Train (ART) or Value Stream but that cannot be dedicated full-time. These resources may include security specialists, information architects, DBAs, technical writers, quality assurance, IT operations personnel, and more. As the resources are specialized, often single-sourced, and typically quite busy, each ART and value stream must plan to engage the resources they need, when they need them.


Agile Release Trains and, by extension, Value Streams are characterized by the dedicated focus that can be accomplished when all necessary skills and abilities needed to deliver value are fully dedicated to the ART. However, in many cases it’s simply impractical to dedicate some specialty functions to a single ART. There may be insufficient capacity of skills of that type, or, alternately, the need from the ART varies over time such that full-time dedication is not economically sensible. To address this, Shared Services support development by quickly bringing specialty expertise to bear on areas of the system or solution that require unique knowledge and skills.

In some cases, the efforts must proactively track ahead of the Agile Teams (examples: security, information architecture), such that they contribute directly to the Architectural Runway that supports new Capability or Feature development. In other cases, the resources can trail core development a bit (examples: IT/deployment support, customer training, localizations), and simply being quickly supportive and reactive is sufficient.

In either case, without timely support and synchronization, the programs will struggle to meet their objectives. Therefore, while the Shared Services may not be on the release train per se, they must travel synchronously with it, as the train has to carry some of their cargo, too.

Summary Role Description

Potential members of the Shared Services group include those with specialty skills in areas such as:

  • Data modeling, data engineering, and database support
  • Enterprise Architecture
  • Information architecture
  • ScrumXP, Agile, and Built-in Quality coaches
  • Internationalization and localization
  • System quality assurance (QA) and exploratory testing
  • Documentation
  • End-user training
  • IT and deployment operations
  • Information security
  • Desktop services
  • Infrastructure and tools management
  • Application/web portal management
  • Configuration management


In order to be effective, Shared Services personnel should be trained in SAFe and participate in PI Planning as well as Pre- and Post-PI Planning. There they drive requirements where necessary and take ownership of their portion of dependent backlog items that emerge. Thereafter, they collaborate to fulfill dependencies that occur during Program Increment (PI) execution. They may also participate in System DemosSolution Demos, and Inspect and Adapt workshops when appropriate, as many improvement backlog items may reflect challenges with specialty technology or with availability and dependencies.

Occasionally, members of the Shared Services group may choose to operate as a single team. When so doing, they iterate on the same cadence as the ARTs and perform Iteration planning and demo and retro activities, just as the Agile development teams do.

Maintain Specialized Training

Because technical shared resources are highly specialized (as opposed to the generalized specialists of an Agile Team), their skills must be continuously refined to keep up with advancements in their respective fields.

Periodically Embed in Agile Teams

In order to better help an Agile Team that requires either the sustained or the transitional shared resource’s special expertise, Shared Services personnel may also be embedded with development teams for short periods of time. There they have the benefit of experiencing daily life on an Agile Team. This helps develop an appreciation for the Agile Team dynamic, as well as an understanding of the speed of development and the quality of the product being produced. It also accelerates the larger dynamic of teams-of-teams that, only acting together, can deliver Enterprise value.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 1 November 2015