Jira Align Solution Layer ( Capabilities ) to have or NOT to have is the Question?

[#1]

For organizations where the products and/or services are so complex that an Agile Release Train is not sufficient, the intent is to have a Solution Train. This is applicable for organizations in which multiple Agile Release Trains work together on one or more complex services and/or products.

Typically, the solution train is where hardware, software, and/or firmware form an integrated product.

The solution train might also include internal and external suppliers that are required to integrate into the working solution.

In short, the solution trains include these suppliers/vendors just like ARTs.

When you set up a solution train, the ARTs will have dependencies that won't necessarily exist within a single ART.

In a solution train, an ART can't get the product delivered alone but requires integration and coordination across other ARTs to be successful.

Multiple ART dependencies could lead to increased risk and good chances of delays.

One needs to consider whether a solution train is really necessary or whether the product can be delivered through individual ART that is aligned with the product vision.

The Solution layer is primarily for those organizations that support multiple within one Portfolio. It also brings along roles like Solution Train Engineers (STE) and Solution Architects (SA) for coordinating delivery across ARTs. Within the Jira Align platform, the work item for this layer is commonly referred to as Capabilities. Be careful not to mix this up with another common term, Business Capability (structures that house a specific business activity). At the enterprise agile level, Capabilities are solutions that span across Agile Release Trains (ART). While smaller than Epics, the extensive work involved can still be accomplished over multiple Program Increments.

Capabilities are similar to features, but they describe higher-level solution elements than features do. Capabilities should fit within one program increment to ensure that incremental value is delivered. Large enterprises often use capabilities to break down epics to a more refined level.

Do you really need a Solution layer?

There is always a misconception about mapping the internal hierarchy of the organization to enterprise-wide agility layers(Team, Program, Solution, Portfolio). Organizations try “lift & shift”  approaches to map these directly into SAFe hierarchy levels. 

Considerations, when not to opt for Solution Train:

• If ARTs don't need to integrate their solutions
• If there isn't a need to create an integrated increment across all of the ARTs by the end of the PI
• If ARTs have dependencies that can be handled through sequencing Features or Epics in the Portfolio.
• If the Portfolio layer can resolve executive and ART dependencies, and reporting needs.
• If the prioritization of ART’s work can be managed through the Portfolio layer. using Portfolio level Epics and a Portfolio Backlog.

I understand the point that a solution train requires a conventional PI Planning session just like an ART. But unlike PI planning, which involves having Agile Teams become a part of the Agile Release Train, there are Agile Release Trains that participate. The vision and the backlog across ARTs need to be aligned, and the PI planning days need to be in sync across the ARTs.

Challenges of a Solution Train(Jira Align can provide a Solution - pun intended!)

Complex solutions often require a long-term vision, in-depth analysis, design, architecture, and execution, with the most important aspect being a “Single platform to track progress.” 

Below are some challenges:

• Not a single simplified view to answer stakeholder queries about solution progress and risks
• Due to complexity and a lack of visibility, the Solution Team is unable to recognize a problem as soon as it arises
• Delay in delivery of a Solution due to lack of visibility among the deliveries from the Agile Release Trains
• Coordinating the dependencies on a high level is very difficult to maintain as it is the teams on the lower level that provide the key information on dependencies

Process Step Cycle Time: This bar chart displays the average time a work item is assigned to a process step of a value stream during the date range. Below the chart, the average time work items spend in the value stream is displayed. Hover over a bar to see details.

Below the bar chart is a line chart, which plots the total count of days work items have been assigned to each process step over time.

WIP: Bar chart displaying the average number of work items assigned to each process step during the date range. Below the chart, the overall average of the number of work items across all steps in the value stream is displayed. Hover over a bar to see details.

Below the bar chart is a line chart, which plots the number of work items assigned to each process step over time.

Other things to consider from the Jira Align's perspective:

• Capabilities have to be connected to a Portfolio Epic, you cant have stand-alone capabilities
• The feature will not have Portfolio Epics as a parent but as a capability.
• Portfolio Epics can’t be linked to ARTs that don't have a solution layer in place