PremierAgile

In SAFe, each Development Value stream develops either a single or more solutions. These solutions can either be products, services, or even systems delivered to customers. 

In a SAFe environment, all artifacts, activities, roles, pages, and words exist for a single purpose. The purpose is to aid Agile teams to continuously deliver solutions. Most importantly, these solutions should provide worth to customers. As a result, customers can achieve their goals. Helping customers achieve their goals is the peak purpose of applying design thinking tools. This is why it follows the customer-centricity approach. Still, it is not possible to guarantee value even when teams apply SAFe guidelines and functions effectively. It means that customers do not buy the features or capabilities introduced for their convenience.  Rather, they opt to buy the entire product solutions that help them get the desired results. It is for this reason, a solution is one of the key concepts in SAFe. It needs to consider a system's view about the delivery of value.

In short, creating an effective solution that is befitting for its intended purpose is the bigger goal of SAFe. Above all, SAFe expects that the solution should be sustainable, feasible, and viable as well. Here, a solution can either be an end product or it can be a set of systems that enable the Operational Value stream for an organization. In both these cases, the job is similar. It is to identify the needs of the solution ecosystem. It is also to continuously, efficiently, and dependably produce a value flow that needs those requirements.

Solution Development in SAFe – An Overview:

Solution Development is part of every ART and value stream in SAFe. When you take the case of Portfolio and Essential SAFe setups, each ART can release a largely independent solution to the end-user. In the case of large solutions SAFe, they support solutions that involve multiple suppliers and multiple ARTs. More SAFe practices and elements are required when solution development turns more complex and larger. When you take the case of the toughest solutions, they need all SAFe practices as you can understand from the picture below:

Source: Scaled Agile

When you take the case of large solutions, they are delivered by multiple ARTs that function together as a solution train. Considering Agile Release Trains, they function hand-in-hand at the same time. They do this for building the solution in full-integrated increments that you can evaluate through a Solution Demonstration. It can occur a minimum of once during every Program Increment. Here comes the role of Solution Intent. It captures improving hypotheses on how and what to build. Even, it helps with the explaining and exploration of variable and fixed designs and requirements. These are released in part from the context of the solution. 

What is Solution Intent?

Scaled Agile Solution Intent is an archive not only for storing the know-how of the present and expected solution behavior. It also involves the managing and communicating of solution behavior. When it is needed, it also encompasses standard and variable designs and specifications. Even, it may include non-functional and functional tests. The other inclusions may be system models and reference to standards applicable and traceability. Presently, the industry faces toughness when building cyber-physical and large-scale software programs. This is where finding answers to two major questions becomes a necessity. These questions are what to build and how it should be built. 

These questions are related to each other. Also, they have an impact on each other. The reason let us consider that a person does not know how to build something in a technically viable and economical way. In this case, it is time for him to reconsider what is being built. This critical knowledge is named by SAFe as Solution Intent. It means the fundamental knowledge of the present and upcoming needs, intent, and design. In other words, it involves the understanding of a larger purpose of the solution. In the case of solution intents, some of them are fixed. It means that no negotiation can be done on them concerning what it should do and what it has done already. On the other hand, some solution intents are variable. It means that they can be discussed further and facts should be explored to support these intents. These differences should be understood and should be navigated accordingly. In turn, there will be chances of variability to move further. This is how it becomes possible to unlock agility in large-scale solution development.

Let us consider that a team intends to build systems that can cost huge in the case of a failure. In this case, naturally, more rigorous validation and definition of the system behavior is important. However, this approach becomes a barrier to the adoption of Agile practices. Of course, most Agile practitioners follow working software over a comprehensive documentation approach. But, let us consider that they follow this behavior when building a system with a high cost of failure. The result can give way to conflicting priorities in organizations that require both. Highly dependable solutions and engineering complex need a lot of technical information. These requirements can be visible from the solution design and requirements. 

Capturing knowledge in Solution Intent:

As mentioned earlier SAFe Solution Intent is an archive to communicating, managing, and storing what is being built and how it is done.  Other than this purpose, it solves other purposes as well like:

• Holding up Contractual and compliance-related commitments
• Brings together suppliers, Agile Teams, and customers to a common purpose or mission
• Helps with further exploration and analysis
• Keeps track of and communicates needs, system architecture, and design decisions
• Offers a single trustworthy source of information about the expected and actual behavior of the solution.

Complex Nature of Solution Intent:

To better understand the complexity of Solution Intent, SAFe has posted the picture given below on its website:

Source: ScaledAgile

From the picture above, you can understand one thing. When you are involved in the development of complex systems, you should know two things constantly. The first is what exactly the present system does. The second is what changes are intended for future tests, designs and specifications. You can choose a suitable form based on your project or organization for capturing the present and upcoming states. But, when you do this, you will have to ensure one thing. It is that your capturing should have three basic components. They are tests, design and specifications. Here, specifications denote the written explanation of system behavior.

Let us consider that you engage in system building to create a system that reacts exactly as required. In this case, you should encompass mission-critical and life-critical standards with traceability. When you do this, you can be confident that the system will react as you expect. It will realize the full behavior and will connect itself with the elements of solution intent and even to the other components of the system. The Scaled Agile solution intent is created in collaboration and improves based on learning.

You can realize the components of solution intent in many forms. It can be in the form of whiteboard sessions, spreadsheets and documents to formal modeling tools and requirements. SAFe has explained it in Model-based Systems Engineering. The thing to remember when you use Solution Intent is that it is meant for bringing the solution building to the close. So, the methods you use for capturing Solution Intent should not create unnecessary waste and overhead.

Ensure That Options Are Kept Open With Fixed and Variable Solution Intent:

Solution intent serves a lot of purposes. Nevertheless, not even a single purpose necessitates the creation of fully-defined, point-solution specifications in advance. These advanced decisions hinder the exploration of better economic alternatives. In turn, the probability of rework and waste will be more. To restrict this from happening, SAFe explains a couple of elements of solution intent. They are fixed and variable that stands up to the regular adaptive needs and design philosophy. These elements create the best economic results. 

Fixed intent denotes the knows. They may be non-negotiable or they might have come up at the time of development. Examples encompass core capabilities that explain the solution, compliance standards and certain performance specifications.

When it comes to variable intent, they denote the aspects that help teams explore the economic trade-offs of needs and design alternatives. Once they are established, these insights will turn out to be design decisions and fixed requirements as time passes by.

You should be able to decide when you intend to move from variable to fixed. Enablers are vehicles of SAFe to record known and explore unknowns and decisions in the solution intent. To end up with optimal economic decisions, the picture below gives the set-based design practices. These decisions aid with the development of downstream features in the roadmap:

Source: ScaledAgile

At every Program Increment, teams build what they know at the same time while trying to understand what they do not know yet.

Develop the Solution Intent Collaboratively:

When talking about SAFe Solution Intent, you should remember one thing for sure. Yes, it is a collaborative effort. The association in Solution Intent happens between program leadership and teams. Be they system-wide decisions or the highest-level decisions, Solution/System engineers/architects and solution and product management are responsible. Even, they establish the organizational structure of the solution intent for supporting compliance and future analysis requirements. Solution Intent helps with driving localized decisions in the backlogs of the teams.

Solution Intent drives the solution roadmap and in the end the backlog items to execute. In general, Solution Intent starts with a goal that explains the purpose of the solution and its key capabilities. Even, the vision explains the non-functional requirements of the system. Teams get guidance from the crucial releases and milestones, emerging roadmap and knowledge with the creation of backlogs. Even, they get help planning their work. In general, both the Solution Intent and roadmap are filled with assumptions. They should adapt to knowledge gained from execution. This collaborative move helps with the replacement of the conventional approach and strives to bring down uncertainty through detailed plans and specifications. 

The guidance of Scaled Agile Framework for ongoing delivery evaluates assumptions via MVPs expanded as Minimum Viable Products that offer validated learning via quantifiable and frequent experiments. In Solution Intent, validated learning is technical predominantly. 

Enjoin Solution Intent Across Supply Chain:

You might think that Scaled Agile solution intent stands alone at all times. Nevertheless, it is not essential. The reason is that the system is made up of many sub-systems. Also, the solution intent generally spans those sub-systems inclusive of suppliers. These suppliers mostly have their independent needs, other specifications and designs for their capability and sub-systems. From the point of view of these suppliers, it is their solution intent. For aligning teams, ensuring exploration and for communicating decisions, there should be appropriate information present across the subsystem hierarchy. Only then, you can call it the ultimate solution intent. Even, the right solution intent will support compliance as in the picture below:

Source: ScaledAgile

Minimal Yet Sufficient Documentation is Important:

Solution Intent is a tool that will help you with guiding, enabling and disclosing decisions. Even, it is a tool for explaining compliance. When you plan the content of solution intent, documentation and organization strategies, you should instigate with those ends in mind. When you document architecture, design and requirements, it is better to keep them light. Here are some best practices that will help you:

• Keep it Simple:

When you create solution intent, record only what is required. Less is more in this case as solution intent is a technique for building a product with contractual and compliance obligations.

• Keep it High Level:

Do not over-specify and communicate at a high level of abstraction as possible. As against fixed numbers, you can offer a wide range of acceptable values. Only then, you can create a set-based design. Design decision-making authority and unify needs.

• Document Items in a Single Place:

Document any needs and design decisions in a single place. It is better to have a sole source of truth that functions as a storehouse of record for everything and everyone.

• Keep Options Open:

Hold up decisions to meet local concerns. It is better to delay in this regard as late as possible. This will help you keep optimistic options open as you are following an adaptive approach to requirements. Even, it will be possible to keep your decisions economically feasible when you follow this approach. You can protect yourself from keeping your requirements and design too early. The reason is that you can avoid committing when you follow set-based design practices.

References

1. https://www.scaledagileframework.com/solution/
2. https://www.scaledagileframework.com/solution-intent/