My idea of heaven is a great big baked potato and someone to share it with.
Shared Services represents the specialty roles, people, and services that are necessary for the success of an Agile Release Train (ART) or Solution Train but that cannot be dedicated full-time.
Among others, they may include:
- Security specialists
- Information architects
- Database administrators
- Technical writers
- Quality assurance (QA)
- IT operations personnel
Because these resources are specialized—often single-sourced and typically quite busy—each ART and Solution Train must plan to engage the shared services personnel it needs, when it needs them.
The focus that comes from assembling all the necessary skills and abilities needed to deliver value is what characterizes ARTs and, by extension, Solution Trains. However, in many cases it’s simply impractical to devote some specialty functions to a single ART. There may be a shortage of a particular skill available. Or, alternately, the needs of the ART may fluctuate, making full-time availability economically impractical. To address this, Shared Services supports 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 must occur ahead of the Agile Teams (ex., security, information architecture), so that it may contribute directly to the Architectural Runway that supports new Capability or Feature development. In others, the resources can trail core development a bit (ex., IT/deployment support, customer training, localizations). Simply being supportive and reactive quickly is sufficient.
In either case, without timely support and synchronization, the programs will struggle to meet their objectives. Therefore, although Shared Services may not be on the train, per se, they must travel with it simultaneously, as the train has to carry some of their cargo, too.
Summary Role Description
Potential members of Shared Services 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 coaching
- Internationalization and localization support
- System QA and exploratory testing
- End-user training
- IT and deployment operations
- Information security
- Desktop services
- Infrastructure and tools management
- Application/web portal management
- Configuration management
To be effective, Shared Services personnel should be trained with the Agile teams and participate in Program Increment (PI) Planning as well as Pre- and Post-PI Planning. They drive requirements where necessary and take ownership of their portion of dependent backlog items. Thereafter, they collaborate to fulfill the dependencies that occur during Program Increment execution. They may also participate in System Demos, Solution Demos, and Inspect and Adapt (I&A) workshops when appropriate, as many improvement backlog items may reflect challenges with specialty technology or with availability 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 operate like any other Agile team.
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
To best support an Agile team that requires either sustained or transitional specialty expertise, Shared Services personnel may also be embedded with development teams for short periods of time. In this case, 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 teams-of-Agile-teams dynamic that—only by acting together—can deliver Enterprise value.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 24 October, 2017