“Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple.” Richard Branson

With the introduction of Agile Release Trains and Program Increment Plannings (PI Plannings), the Scaled Agile Framework has mastered the art of synchronizing and aligning several teams that work jointly on one product in an agile fashion. It has provided strong guidance on how to manage dependencies between teams and understand reliances between Features and User Stories. The mechanisms and tools offered in the Framework are universally applicable and useful in various settings and corporations.

However, in practice, we sometimes need to deal with extremely elaborated products that require several hundred engineers to handle the inherent complexity in those systems. This means, that we need to overcome the boundaries of single Agile Release Trains and create a team-of-teams-of-teams that creates a big system. These are called Large Solutions. The Framework foresees an additional level in its Big Picture for these circumstances and scales up the existing patterns in form of Pre & Post PI Planning, Solution Management and Capabilities.

In practice, we have made the experience that, in these cases, we need additional guidelines and creative ideas on how to master the art of product development in those complex settings.

The challenge is, just as Mr Branson says in his quote, not to add additional complexity into the already tricky product by adding additional meetings, artefacts and events but stick to the simplest ideas.

In the past months, we have tried and tested, experimented with and evolved new hypotheses and tools with the aim to help organizations that struggle with delivering value in these intricate circumstances. In this Whitepaper, we want to present our most successful concepts on how to start SAFe in a really Large Solution.

We structured the Whitepaper along the implementation roadmap. It provides a way to illustrate a successful SAFe Transformation and serves very handy in Large Solutions as well. However, along the SAFe journey, there are some steps that need to be altered and tweaked a little bit to completely respect the additional needs and demands of those big systems. Therefore, the paper, step by step, explains and illustrates those differences to make coaches aware of the additional attention they need to pay in those cases.

What are Large Solutions?

SAFe says a Large Solution consists of one or more Agile Release Trains. But a Large Solution Train is not just an additional level of scaling on top of several Agile Release Trains, it is a completely different kind of Train.

In fact, we face numerous additional challenges that need to be paid attention to in order to build up a lean-agile organization.

First, we have the inherent complexity in the product that is to be developed. Simple products usually do not require this vast number of engineers and developers; hence, only complex products require Large Solutions at all. The product complexity is the first difficulty we face.

Second, we have the huge number of people that exceed Dunbar’s number by far. This has to major consequences. The ways of communication do not increase linearly but exponentially with the increase in participants in the network. These additional communication needs need to be managed and aligned in form of events and artefacts.

Furthermore, stable social systems are the basis for the mutual reinforcement of the creative potential of individual people, which is necessary for the required speed of such complex systems. It is not only about well-being; it is about this indescribable experience of mutual acceleration of creative forces. This energy amplification must be understood systemically and standardized as far as possible. Dunbar’s number, however, stipulates that mankind is only able to structurally hold those type of relationships necessary for creative work up to a number of 125 individuals. Therefore, the new organizational structures must be supplemented by sociological considerations that offer answers to overcome the limitations given by Dunbar and allow the formation of large social systems.

The third point is the architectural platform that is shared and used by all participants. Since all Agile Release Trains are working on one shared Solution, this means, they need to also share the same Architectural Runway, the associated standards, guidelines and rules. It is very common that there are platform Trains or shared services that need to be developed cross-Agile Release Trains. These dependencies put additional complexity on the intricacy of the product and the social constraints.

That is why we need to be exceptionally careful already in the design of Large Solutions when we start an Agile Transformation for big systems. Therefore, we start with the Implementation Roadmap to illustrate the differences between the SAFe journey of Large Solutions and Agile Release Trains.

SAFe Implementation Roadmap

The SAFe Implementation Roadmap is a useful tool in order to guide the corporate transformation. It provides 12 steps from the initial decision to start SAFe to the sustainable, learning, agile corporate that constantly improves and evolves to be ahead of the market.

  1. Reaching the Tipping Point
  2. Train Lean-Agile Change Agents
  3. Train Executives, Managers, and Leaders
  4. Create a Lean-Agile Center of Excellence
  5. Identify Value Streams and ARTs
  6. Create the Implementation Plan
  7. Prepare for ART Launch
  8. Train Teams and Launch the ART
  9. Coach ART Execution
  10. Launch More ARTs and Value Streams
  11. Extend to the Portfolio
  12. Accelerate

For the purpose of this Whitepaper, we want to focus on the start and the design of SAFe Large Solutions which includes first steps up to the initial PI Planning (step 8). In our experience, there are three main differentiators in the implementation steps for Large Solutions which we want to discuss in the following: the creation of a Lean-Agile Center of Excellence (LACE), the identification of Value Streams and ARTs and the training of teams before the ART Launch.

Create a Lean-Agile Center of Excellence

The role of the Lean-Agile Center of Excellence in Large Solution is even more important and more dominant than in regular SAFe environments with one or two autonomous Agile Release Trains. This is due to the fact that we have a much larger number of people involved and more coordination effort. The communication of the change vision is much more important in order to really get everyone involved and excited for the change. Furthermore, role coaching becomes much more important, especially on the Large Solution-specific functions as the Solution Train Engineer, Solution Management and Solution Architect. These roles do not have many peers, neither in the organization nor outside of the organization so that agile coaches from the LACE team need to support and guide them carefully. Next, agile tooling becomes more critical. For example, development units should work on one shared backlog their product which requires one common backlog software tool. The last exemplary point for the LACE team we want to raise are the additional need for supplier coaching and training management. Large Solutions oftentimes do have additional dependencies outside of the organizations, especially in the area of cyberphysical products that combine hardwarde and software. These need to be informed and trained in the Value Stream’s development practices and rhythms which falls into the sovereignty of the LACE team.

It becomes evident that the spectrum of tasks for the LACE team and their importance increases in Large Solutions. Therefore, we advise to pay additional attention in the selection of participants in the LACE team and, furthermore, start with the setup of the LACE team very early onwards.

As we already indicated above, the challenge for Large Solutions is threefold:

First, we have the product. Each Agile Release Train and, ideally, each team should be able to deliver end-to-end value independently. With simple products, this independent value delivery is relatively easily reached. For complex and large products, however, we need a more sophisticated view on the setup and try to reach the highest degree of autonomous, incremental value-delivery of each team as possible.

Secondly, we need to deal with the vast amount of people and how to organize them into tribal structures to reflect Dunbar’s number. The existing laws of team dynamics hinder us from putting all people together in one Agile Release Train but let several Agile Release Trains work together. We need to find the right cut of Agile Release Trains to enable face to face communication and transparency.

Third, we want to reflect the underlying architectural setup and slice our teams and ARTs accordingly in order to limit the number of shared services and inter-ART dependencies.

In summary, we have to find the perfect balance between independent-value delivery in terms of product specification, the right number of people and the underlying shared architecture. That means that we have to slice our Value Streams accordingly to enable self-steered and self-organized work. In doing so, we are also able to have an efficient dependency management, because we can exercise the principle of decentralized decision-making and autonomy as intensely as possible.

The usual approach of Value Stream identification is not reflecting all three aspects which can hinder efficient value flow. Therefore, the first step in streamlining and simplifying a Large Solution is to extend the Value Stream Identification and incorporate these three aspects.

Understanding the Product Functionalities

First, we want to tackle the product-related dependencies. We need to systematically understand the different components that our product consists of. We can imagine a big product to be the sum of multiple problem spaces, that jointly solve one overarching customer need. If we want to develop a car, for example, one problem area would be an efficient and powerful engine. Another problem area could be the car multimedia system. Altogether, they solve the customer need for a transportation device. We follow an approach where stakeholders jointly identify those long-term stable problems that need to be solved. Visualization helps to manage the mass of information in this workshop.

Make the Architecture visible

 Once we understand the core problems we want to solve, we want the underlying technical architecture to mirror those product areas in order to enable relatively autonomous development. The concept of Visible Architecture Workshops has already successfully been used to understand and improve architectural design. A visible architecture is basically a physical model of a system. In this format, participants jointly re-build their architecture with Lego in order to visualize underlying dependencies. We can evolve our Lego architecture to match the problem areas we identified in the previous workshop. The models also help to think about future states of the enterprise anticipating any mismatches between product problem spaces and technical infrastructure. It enables teams to understand architecture as it is now and make educated decisions on the architecture to be.

Using visible architecture workshops is especially useful because business leaders oftentimes do not understand architectures and even architects sometimes do not understand each other. Furthermore, they are not able to communicate their view to business in a simple language. Visible architecture creates a shared language for communication and helps all participants to overcome the challenging concepts of conflicting ways of communication in current methods like ITIL SEMAT, TOFAL, etc.

The approach allows to create a more holistic and wholesome view on dependencies between Development Value Streams.

Building Teams

The most important thing is that the teams in the Solution Train are enabled to work on a sufficiently independent and in itself meaningful part of the whole integrated product. This is achieved by fulfilling two important requirements: first, they can, from am environment point of view, perform all the steps necessary to build the complete solution – ideally up to the continuous integration and release on demand – and, second, they have all the knowledge associated with those end-to-end working steps. Teams, that have those properties, namely real cross-functionality and a wholesome, sensemaking problem space are called feature teams.

Finally, we want the problem spaces, the technical architecture and the feature team setup to flow smoothly together into an efficient product development system.

This means that one or more feature team is dedicated to a certain problem space and it can – thanks to the autonomous architecture design – work independently on the solution.

However, in reality, the different problem spaces are coupled since they jointly build the overarching product. But, the degree of coupling varies between and within those problem spaces. This means, for example, that the multimedia system of our car is relatively independent from the engine. But the breaks might be closely coordinated with the power of the engine. We managed to decrease complexity and dependencies to the extent possible, but this is the inherent complexity in the product that we still need to handle in the execution.

The problem spaces that we identified in the workshops vary in their size. That means that one or more teams or a whole train can work on a certain problem space. Whenever we need more than one team, but not yet a train to work closely on one problem space, we form a Solution Area. A Solution Area is a small team of teams that works on solving the specific problem space. As we can see in figure 7 and 8, Solution Areas can exist within a train, but also cross-train or represent a shared service which means they form a platform Solution Area.

In incorporating these three viewpoints in our value stream workshop, we are able to reduce the dependency management significantly because a lot of communication can happen within the identified problem spaces, e.g. teams, Solution Areas and Agile Release Trains.

Train Teams and Launch the ART

In order to ensure an efficient and effective execution, Large Solutions require an additional effort in terms of events and artefacts that need to be reflected in the training. Teams and Agile Release Trains do already have a compelling series of events and artefacts at hand that have proven to be successful in the past. The planning, review and retrospective pattern has already been implemented and understood thoroughly and is widely accepted. With the newly established unit Solution Area, we do also need to introduce a plan-do-check-act pattern and associated artefacts without overloading the teams within the Solution Area with too much overhead. Next to the events, we also need to align artefacts to the joined mission. Therefore, we need a common Backlog for the Increment, shared Definitions of Ready and Done. Furthermore, the Large Solution needs time before and after every PI Planning to update the roadmap, manage expectations for the workload of the upcoming PI and coordinate ARTs. This should also be included in the Team trainings.


We have experienced that, with the size of the Solution, complexity and dependencies increase. This puts additional challenges in the implementation of SAFe as it is proposed in the Implementation Roadmap. In order to overcome these difficulties, we twisted and tweaked the Implementation Roadmap a little bit and enriched the standards with our own practical experiences from the field that have proven to be successful in many circumstances. This Whitepaper is intended to serve as a food for thought for how to facilitate the agile transformation of extremely large companies. The stressing of the importance of LACE team and the extension of the Value Stream Identification Workshop shall represent a first step in the right direction. This should, certainly, be followed by subsequent coaching and accompanying of the execution and improvement items in the aftermath, which is another aspect of Large Solutions.

Our aim was to provide an idea for all coaches and SAFe Program Consultants that operate in large organizations and provide some guidance on how work with SAFe in these circumstances. At the same time, this post shall be an invitation for discussion, research and the exchange of ideas on the topic that is so important to us.  

About the Author

Mrs. Caroline Schmidt completed her studies in Finance in Vallendar at the WHU Otto Beisheim School of Management and is now pursuing her PhD at the chair of Business Information Systems. She combines academic research with practical experience in her role as a consultant with a special focus on lean portfolio management and system design. Being passionate about what she does, she loves to pass on her knowledge in trainings and workshops. Various experiences abroad, e.g. in London, Milan and Tunis as well as her apprenticeship as a certified mediator help her perform and operate in different cultural contexts and difficult situations. Besides that, she is a passionate yoga teacher.