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

—William J. Mayo

 

Shared Services

Shared Services represents the specialty roles, people, and services required for the success of an Agile Release Train (ART) or Solution Train, but that cannot be 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 value delivery delayed. However, in many cases, it’s just not possible to devote some specialty functions to a single ART. There may be a shortage of a particular skill available. 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 (e.g., security, information architecture) that supports new Feature or Capability development. In others, the effort can trail core development a bit (e.g., customer training, localizations, compliance audits). In some cases, merely being supportive and reactive quickly is sufficient. Having these services on the trains ensures their work is performed early and in smaller batches to make delivery more predictable and provide feedback to the teams.

In either case, without timely support and synchronization, the programs will struggle to meet their objectives. Shared Services may participate full-time with a single ART or may 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, that commit with the teams’ and ART’s to the shared goals and objectives.

Potential members of Shared Services typically include people with the following types of specialized skills:

  • 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 (ITSM) and deployment operations
  • Security specialist (InfoSec)
  • Regulatory and compliance
  • System QA and exploratory testing
  • Technical writers

Responsibilities

Shared Services personnel engage in the following type of activities:

  • Participating in Program Increment (PI) Planning as well as Pre- and Post-PI Planning for Solution Trains.
  • Driving 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 and 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 that case, they would iterate on the same cadence as the ARTs and work like any other Agile team.

Periodically Embed in Agile Teams

Shared Services personnel may temporarily become part of an Agile team for short periods of time. In doing so, they experience the collaborative, quick, and high-quality way in which 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, reducing the ART’s dependence on specialized skills.


Learn More

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

Last update: 18 December 2019

 

Authors