Blog: Optimizing Shared Services Using Jira Align

As agile organizations organically grow and evolve, certain issues always arise. Routine cross-team dependency based around a particular skillset or tool is an example that is bound to occur. At a larger scale, these dependencies and related enablers can also pop up across programs and portfolios.

This is costly at every level of the Enterprise because it:

• Disrupts plans in execution
• Increases cost of delays
• Destroys confident, predictable delivery

In the spirit of continuous improvement, enterprises need to accept that these issues exist and that they can and should be addressed. If we understand that we disrupt ourselves, the question becomes how best can we turn this into supporting ourselves?

The best way to mitigate the potential problems caused by these dependencies is to optimize one or more Shared Services teams (or teams of teams) whose job is to focus exclusively on enabling the other teams, programs, or portfolios as needed.

Let’s break down the nuts and bolts of Shared Services, take a look at a real-life example of how this works, and then highlight a tool that makes this process easy and effortlessly scalable.

What is a Shared Services Team?

Essentially, a Shared Services team is just an Agile team formed for the express purpose of working on stories and features that will enable other teams to move ahead on their own stories and features in future sprints or planning increments (PIs).

Ideally, the team will be cross-functional and self-organizing (as every Agile team should be) and will have a home within the team of teams (or ART, in SAFe terms,) program, or portfolio that most often requires its unique set of skills. Unlike other Agile teams, however, the Shared Services team will be working on bits and pieces of other teams’ committed features rather than their own most of the time.

How Does a Shared Services Team Operate?

Generally speaking, a Shared Services team will need to set aside about twenty percent of their time for interruptions—vital stories or features that other teams or ARTs need to complete their work in the current sprint or PI. The rest of their time goes to stories and features other teams depend on for their next sprint or PI.

So, to optimize Shared Services, planning is crucial. That’s where teams will identify dependencies and related enablers. That way, product owners can assign stories and features to the Shared Services team backlog appropriately to ensure the other teams have what they need to accomplish what they’ve committed to in each iteration. Though the Shared Services team shouldn’t need to run on a completely different cadence, they may need to adjust cadences somewhat to accommodate the time required to handle their planning and maintenance while still completing features before other teams require them.

What Does This Look Like in Real Life?

One of Cprime’s clients—a large financial services company based in New York City, U.S.A.—came to us for help guiding a large-scale digital transformation and modernization of their development organization. As coaches worked with them to plan and execute this process, it became clear that dependencies like those described above created bottlenecks and hindered delivery across multiple value streams.

To address this issue, the coaches worked with client stakeholders to optimize the environment in which the Shared Services team and the SMEs could collaborate. The team quickly mobilized around standing up one of the release trains and running it through PI Planning. They created a series of value streams for the release trains that relied upon a series of shared services.

As that PI progressed, the team took what they learned and established a model which included sessions called “architecture look-aheads” to consider solutions for the following PI (10 weeks) while also exploring (at a very macro level) solutions for the next two to three PIs. A new operating model was thus implemented that allowed the team to better understand and plan for future PIs.

For example, it highlighted that some future changes might have data impact. Even though the precise nature of the change is yet unknown, it alerted the team that there would be at least two to three future sprints of work for the data team. The team can now plan and set capacity for that data team to join and be a part of PI three and participate in that release train planning. This resolved many of the shared service problems that the team was experiencing. It also increased efficiency and response time from all teams involved.

In the end, the client saw a 50% improvement in productivity in just six months. Learn more by reading this case study!

How Jira Align Empowers Shared Services

When you boil it down, the establishment and maintenance of one or more Shared Services teams come down to visibility and transparency. The more clearly and farther out you can identify and plan for dependencies and appropriate enablers, the more valuable and effective your Shared Services organization will be.

Jira Align is all about visibility and transparency. Its Dependencies Mapping module makes it simple for product owners, program managers, and portfolio managers to identify individual dependencies and trends that can inform future improvements. Then, as planning occurs and work is accomplished, the real-time visibility afforded by the application makes it quick and intuitive to ensure bottlenecks and roadblocks are eliminated, and interruptions are kept to a minimum.

To explore Jira Align further, we recommend speaking to a Jira Align expert and setting up a demo today!