SAFe® in a Nutshell – Large Solution

In previous installments of our ‘SAFe in a Nutshell’ series we provided an overview to SAFe 5.0 and walked through the roles, steps, and events involved in launching and running an Agile Release Train (ART), including how to prepare for a PI planning event, executing a PI, and the Inspect and Adapt Workshop. In this installment, we’ll explore the Large Solution Level of SAFe and how these same concepts, as well as some others, operate this level.

 

Scaling From Program to Large Solution SAFe

At the solution level, key roles and processes remain similar, but are scaled up from the ART level. This Large Solution level is used for organizations who are building systems in a much larger capacity. As such, it requires the collaboration and alignment of multiple ARTs.

• The ART becomes a Solution Train comprised of 3-10 ARTs.
• The Solution Backlog is made up of capabilities, which are then decomposed into features.
  • A capability is analogous to a feature for an ART. In order for capabilities to get done within a PI, it is going to take the capacity of multiple ARTs to complete it. Capabilities will break down into features that go to the various ARTs at which point work is integrated back together into a coherent solution at the Large Solution level.
  • As best practice, maintain a roadmap of desired capabilities for a few PIs into the future. The timeline that the Solution Train is working again must be in advance of that of the ART, given that it cascades down from the solution level.
• Solution Trains run on the same PI cadence as the ARTs that comprise them.
  • By default, this implies a 10 week program increment.

Example – Building a Space Shuttle

An example of the use of the Large Solution Level is shown below. We leverage the Space Shuttle to illustrate the concepts. [Note: This is not an exhaustive list of all the ARTs that would be needed to actually build a Space Shuttle.] The Space Shuttle is obviously a very large and complex solution that requires the coordination of a multitude of teams and technologies from various vendors. The Space Shuttle itself is considered the Large Solution and all the ARTs that are coordinating to build it are considered a Solution Train (ART of ARTs construct). While 3 ARTs are shown here, there could be as many ARTs as needed collaborating to deliver the solution. Each ART would then be composed of 5-12 teams as we learned in previous blogs. The Comms (Communications) ART is illustrated here as an example.

An example of a Capability that would be built at the Large Solution level could be “Manual Thrust,” which would allow the operator to accelerate manually, if needed, as opposed to it being coordinated by the computer (refer back to “Apollo 13” for the scenario in which a manual thrust capability might come in handy). This Large Solution Capability could then be broken down into multiple Features across the ARTs. The Comms ART would have to include the handle and/or switches to initiate the thrust, the Propulsion ART would have to receive the command from the Comms ART and actually fire the thrusters accordingly, and the Chassis ART would have to ensure the Chassis was built in a way that could withstand the potential forces that might be envisioned from a manual vs. an automated thrust capability.

Solution Intent

The Large Solution Level includes a key construct that is not mentioned within the Essential Level of SAFe (e.g. associated with an ART). That said, if a given ART found the concept useful, there should be nothing stopping them from leveraging it for a single ART. The Solution Intent is the single source of truth for everything that the Large Solution does today or plans to do in the future. It is a repository that captures everything that was done to get the solution to where it is currently, such as all solution history, context, and important information needed to support validation and compliance. It includes:

• Specifications: Epics, capabilities, features and stories
• Design Artifacts: All information that reflects how the solution was designed, for example architectural diagrams and studies
• Validation Tests to prove the Solution is functioning as designed

All of these artifacts could be classified as either current intent (e.g. backwards facing: have already been specified, designed/built, and validated or are in the process of being built) or future intent (e.g. forward facing: will possibly be built/verified in the future). The mechanisms to convert future intent to current intent are what we call enablers in the framework. Enablers signify how we capture the work to analyze, prototype, and ultimately make decisions on what will be built going forward.

Roles

As previously discussed, the three roles involved include the Content Authority, Execution Authority, and Technical Authority. At the solution level, these roles scale up from the ART level and have very similar functions, albeit on a much larger scale.

• Solution Manager – the scaled-up product manager, Content Authority of the solution who owns capabilities on the Solution Backlog.
• Solution Train Engineer – the scaled-up RTE, Execution Authority of the Solution Train.
• Solution Architect – the scaled-up system architect, Technical Authority of the Solution Train.

In addition, a unique System Team may also be present at the Large Solution Level. [Remember, the System Team is shown on the spanning palette within the framework, which implies it could show up at any level.] The role of the System team in this case is focused on integration across ARTs. Depending on the size and complexity of the Large Solution, the System Teams from each ART may collaborate to accomplish cross-ART integration. Alternatively, a separate System Team could be formed at the Large Solution level to drive collaboration, perhaps with support from each ART System Team.

Lastly, although SAFe doesn’t directly show a Business Owner at the Large Solution Level, it might very well be the case that a different Business Owner or set of Business Owners may exist at the Large Solution Level that are separate and distinct from the ones that are focused on each ART.

Ceremonies/Events

We see similar ceremonies at the Large Solution level that we have scaled up from the ART level.

• Scrum of Scrums – used to discuss current PI execution and ensure that the team is on track with the committed plan. This would be facilitated by the STE and include the RTE from each ART on the Solution Train.
• Architect Sync – used to discuss the architectural runway and the elements that are going to be needed to support the capabilities defined at the Large Solution level. This would be facilitated by the Solution Architect/Engineer and include the System Architect/Engineers from each ART.
• PM Sync – analogous to the PO sync at the ART level, focused on the future and getting the next set of capabilities ready for the next PI. This is facilitated by the Solution Manager and includes the Product Managers of each ART and the STE, Business Owner(s) and Architects for different meetings as needed. There is a feedback loop at both the Large Solution level and the ART level. As the features become more and more refined, the capabilities also become more and more refined. There must be tight collaboration between the Large Solution level content authority and the ART content authority, as well as the architect, to support those capabilities. As the team prepares for PI planning, the Solution Train will have PI ready capabilities at the Large Solution level, and PI ready features at the ART level, all of which are now ready to go into that final sprint of the PI where the ARTs will start to create stories for those features.
• PI Planning – after have draft capabilities and features all captured in the solution intent and are considered “PI Ready,” we can discuss how PI planning is handled at the Large Solution Level. The full PI planning ceremony only happens for a single ART. We hold pre, mid, and post-PI planning events at the Large Solution level to establish and maintain alignment among the ARTs:
  • Pre-PI Planning – an opportunity to align PI planning for all ARTs and address potential blockers across the Solution Train. In this meeting, we obtain final agreement on the Large Solution capabilities and the corresponding features for each ART that support those capabilities. Attendees include the Content Authority, Execution Authority, and Technical Authority at the Large Solution level (Solution Manager, Solution Train Engineer, and Solution Architect) as well as those same authorities at the ART level (Product Manager, RTE, and System Architect), along with the business owners.
  • Mid-PI Planning – after the first day of PI planning, each ART holds what is called the “Management Review and Problem Solving” meeting as the last agenda item of day 1. This is where the ART leadership discusses what was learned that day and determines if any adjustments are required to reach a committed plan. This could include de-scoping, team member changes, etc. Once that meeting has occurred for each ART, another similar meeting occurs to discuss any required changes to scope, ARTs, etc, that may be necessary to support each individual ART getting to a committed plan the next day.
  • Post-PI Planning – lastly, once all the ARTs have completed their PI planning sessions, we formulate an overall plan across all the ARTs. This is an opportunity to review the output of each PI planning session and make any required adjustments to the capabilities that had been planned during the pre meeting. Typically, the input to this event is an aggregated rollup of the PI Objectives from each ART, the Solution Board. This includes ARTs along the left vertical axis, Sprints across the top, and Capabilities (blue cards) and cross-ART dependencies (red cards) with strings connecting them (or lines, in an electronic board). It also shows key milestones (orange cards) at the top. Essentially, this is a high level representation of the plan across ARTs.
• I&A Workshop – lastly, the concept of an Inspect and Adapt (I&A) Workshop also exists at the Large Solution level. Once all the ARTs have held their I&A workshop, a subsequent one is held at the Large Solution Level with the same 3 components (PI Solution Demo, Quantitative and Qualitative Measurement, and the Problem Solving Workshop). This ceremony typically isn’t attended by all team members of all the trains, but by the same audience that attended the other ceremonies mentioned above.

 

Conclusion

Scaling to a Large Solution level introduces additional challenges which are addressed by scaling and adjusting the roles, ceremonies and events. In this post we summarized the recommended approach and aligned it to what happens on an ART. In our next and final installment, we will discuss the final level in SAFe, the Portfolio Level, and discuss how we centralize the strategy for the portfolio and set ourselves up to decentralize execution in the manner that has been described in previous blogs.