Mastering Large-Scale Solutions: A Comprehensive Guide to Efficiently Running and Optimizing Big Systems

Extending the Framework to Large Solutions

Hello and welcome to this book, everyone. The majority of agile frameworks are designed to enable several teams to collaborate on a complicated and large-scale product. But what happens when your product is so big that it requires the efforts of at least 50 technical teams working on it simultaneously? In that instance, ensuring that all of the teams remain in sync while working on the same project would undoubtedly require the implementation of a few more procedures. And that's precisely the subject of this book.

To ensure that you are capable of handling the biggest and most intricate goods available, we will examine the framework's massive solution layer. Firstly, this book is a component of the agile learning path that is scalable. Getting Started with Scaling Agile was the first step on this route. Next, we studied two books at the intermediate level: Putting a Program in Place and Leading a Team Iteration. Following this book, Running a Large Solution at Scale, we will focus on Advanced Topics in Scaling Agile and Managing the Delivery Portfolio.

As far as we are aware, our framework consists of a backlog system. At the program level, items are moved from the program backlog into team backlogs, which are subsequently carried out by the various agile teams within the company. But what would happen if there were fifty or more teams working on the same project? Then, using the same backlog for all those teams to work from would not be possible. Rather, the work distribution system will require an extra layer. We thus have a solution backlog, which we use to fill the program backlogs, which are then carried out by the teams in the various agile release trains. In addition to the mechanism for allocating work, the teams must also have a common understanding of the product's technical approach and overall vision. Therefore, in order to ensure that all of the teams are in sync with each other in terms of technical execution and vision, we also need to implement a few more procedures and customs. Thus, in this book, individuals focus a lot on those topics. Upon closer inspection of a comprehensive solution, we discover that essentially four components are required to accomplish this coordination amongst the various teams.

is a continuation of the rituals first and foremost. As you will discover later in this book, we will extend the PI planning event to ensure alignment not only between the various teams inside the overall solution, but also between the various projects within it. Next, we will present the economic framework, which is necessary to enable the various teams to decide on organizational economics in addition to making technical decisions at the team and program levels. After that, roles and responsibilities are examined. Solution management, or your solution layer product management, is what we'll have. The solution layer system architect is, of course, our solution architect. Our solution train engineer is essentially a Scrum master at the top of the game. In addition, the work distribution system must be configured such that it is evident which team will work on which aspect of the technical product and how work is divided among the many teams and programs. We will now move forward in this Book in the following manner.

We will first examine the solution layer and all the intricacies involved in extending the framework to it. After that, we'll examine the economic framework, the method for allocating work, how the various rituals in the framework are expanded at the level of solutions, and, lastly, how a sizable solution is organized inside this framework. Allow me to now magnify this specific chapter—the Solution Layer chapter. We will start by discussing model-based system engineering, which uses models and documentation developed by several themes to accelerate innovation and product delivery. Next, we'll examine set-based design, a technique that lets you maintain complete creative freedom when it comes to product design. Lastly, we'll examine quality and compliance management at the solution layer. Okay, so let's dive straight into this chapter of the book.

Model Based System Engineering

Model-based system engineering is one of the ideas that must be presented at the solution level. When launching complicated goods at the solution level, this is a crucial notion that will save you a great deal of rework and enhance both time and quality significantly. Now let's use a scenario to illustrate the idea. Assume for the moment that we are developing a new jet fighter, that several technical teams are working on various aspects of the aircraft, and that we have a solution backlog. As you might expect, these teams can be software-focused as well as more hardware-focused, such as those that concentrate on the aircraft's structure.

As we all know, if we follow the standard Agile methodology, each team will work on the entire product over iterations. If we follow the standard methodology, however, we begin with a tiny product and gradually develop it. Let's imagine, nevertheless, that at some point we discover that a few components of the product are malfunctioning and that we must refactor. Put differently, we must change course. Thus, after one iteration, we step back and make some adjustments to the main product. We then stick with this course of action until the product is finished, at which point we once more need to pivot. Since you typically only go back one iteration when working with a single Agile release train or team, the cost of performing such a pivot is typically not very high. For example, when working on software products, the core infrastructure can be changed fairly easily because we are merely dealing with code. However, in large solutions, even pivoting the product between iterations can become a very costly business.

Is it possible to envision the need to modify an aircraft's design when it is being developed gradually? To mitigate this risk—which the client would likely find intolerable—we developed the model-based system engineering technique. Basically, what happens when you utilize an Agile methodology is that knowledge about the optimal solution is created incrementally. Thus, there is a constant line in our understanding of the optimal answer if we just begin developing the product and grow wiser as we go. But if, particularly early in the product development process, we base design decisions on models and simulations, we may end up learning a great deal more about the ideal product than if we just started building it and made incremental improvements to it. Therefore, in the early stages of product development, there can be a significant difference between utilizing models to inform design decisions and actually creating the product and making incremental improvements to it. Thus, even if it's uncommon for Agile organizations to produce large, detailed designs and models upfront, it can still be advantageous to allow teams to work on various models and simulations related to the ideal product, since this will aid in the process of determining the optimal design choices.

There are two ways to approach this from a development standpoint. The actual development of the product comes first.