Hi, welcome to this lesson where we will look at Large Solution scaling of SAFe.

What content is covered in this lesson?

We’ll talk about in the next few minutes:

• the connection to Essential SAFe scaling,
• the Solution Train,
• the Solution Demo,
• Milestones,
• the roles of the Large Solution level,
• the pre- and post PI planning,
• the newly added Solution Backlog,
• the Solution Intent,
• the Enterprise Solution Delivery,
• the Shared Services,
• and in a bit more detail about communities of practice or alignments.

But now to the content of this lesson:

For Large Solution SAFe, the whole lower range will look familiar – it is 1:1 the same as Essential SAFe and will not differ in the other scales. This ensures that team members can quickly find their way around any SAFe scaling and that there are no unnecessary irritations. For this reason, we do not need to go into more detail here about the team and program level.

What are the differences between Essential SAFe and Large Solution SAFe scaling?

If you remember the limitation to only one solution in Essential SAFe, you may notice here in Large Solution SAFe that we find an additional Solution Train above the Release Train. This allows us to serve another layer where multiple solutions make up a total solution, which can also be time phased and continuous. We can also bring together internal solutions and external solutions from suppliers here.

Now, if we have multiple solutions, the Large Solution SAFe gives us the ability to present demos of an overall solution to the customer at set milestones, removing an important hurdle in granting budgets. And with surprise we now find that SAFe indeed provides us within the agile organization with the milestones a first combination with techniques from a planning organization. This step is also important and good in reality, because the higher we get within an organization, we encounter more and more waterfall prerequisites that influence our agile way of working. Without a budget, there is no project. So we need a solution on how to deal with these “un-agile” conditions – and SAFe provides it. A second advantage of the solution demo is that during this process we also encounter any rework that may be necessary to ensure that the individual solutions function as requested in the overall solution.

How does PI planning differ between Essential SAFe and Large Solution SAFe scaling?

While with Essential SAFe with only one solution PI planning is still clear and therefore feasible in one step, with multiple solutions PI planning must be prepared and followed up by the Solution Train Engineer (also called STE), Solution Management, Business Owners and Product Managers. The goal of pre- and post-planning is to coordinate the content of the PI planning efforts so that the result of each PI planning effort leads to a functioning and coordinated intermediate state of the overall solution.

Attached to this lesson you will find a PDF in A3 format with the Large Solution SAFe Overview. Depending on the project scaling you use, feel free to print this out and hang it on the wall in your project room as a basis for discussion and explanation to the team. The requirements for the overall solution are managed by Solution Manager in a separate solution backlog. Similar to the way the system architect defines and provides the basis for the teams in the program level, the solution architect in the large solution level develops the basis for the overall solution, on which the individual solutions from the program level are then built.

What is a Solution Intent?

The more complex a project becomes, the harder it is for teams to grasp the overall solution – and only when every team member knows the goal can they work in a goal-oriented manner. For this reason, SAFe in Large Solution Scaling uses the Solution Intent to define data management at a central point that is accessible to all. It is important to note that the information collected here is not fixed, but rather the open requirements, as well as those that have already been completed, are further developed in the best agile sense. However, it is also a fact that the fixed components continue to increase and the variable (agile) components continue to decrease as the project progresses.

Enterprise Solution Delivery is another competency of the 7 core competencies of Lean Management. Since I will cover the basics of Lean Management in one of the following lessons, I will only say this much at this point: this point further deepens the Lean-Agile Mindset from the SAFe foundation and thus drives the economic optimization of the project process. However, you are welcome to get to know this Lean core competency in more detail right now by treating yourself to the content on this graphic in the SAFe diagram.

On the other side of the Large Solution SAFe overview, we see additional points that we will now briefly discuss.

We already had the vision in Essential SAFe, nothing has changed. It is the same with the roadmap and the system team. We have already discussed the new milestones added in this scaling here in the lesson.

What are the Shared Services in SAFe?

Let’s therefore move on to the next point, “shared services”: it is quite normal that some tasks in the project team do not justify full-time work because they are only required to a small extent in terms of time or very irregularly. When considering a team, these are therefore resources external to the team that are called upon as needed and, because of the rarity of their use, are not integrated into the team structure. In a larger organization, it’s a different story: if these external resources feed many agile teams, then these people are regularly involved in agile collaboration – perhaps even full-time. In large companies, entire departments work to agile project teams. For this reason, with this SAFe scaling, it makes sense to include these resources in the project flow. And the involvement predominantly regulates the cooperation, so that with these external resources, which are often very difficult to obtain, there are no blockades and thus triggered time delays in the project as well as decreasing project efficiency. Shared services are a service unit necessary for this scaling, which takes care of organizing necessary skills either internally so that they are quickly available at the required location, but also procures unavailable skills externally. In practice, this service unit is also the first point of contact for obtaining expertise in the planning phase prior to a project and the subsequent setup of the project teams.

What are Communities of Practice?

Let’s move on to the next point, the CoPs, the Communities of Practice, or in German also known as Regelkreise, which involve the exchange of knowledge between specialists even beyond the project team. While knowledge sharing is automatic in small organizations due to the small number of people involved, islands of knowledge quickly form in large organizations that are unknown to others. On the other hand, the same challenges and problems, for which well-functioning solutions have already been developed elsewhere, exist several times in different teams. To avoid unnecessary effort and increase project efficiency, the Large Solution SAFe provides for the regular cross-project exchange of roles and specialists within Communities of Practice.

What are the requirements for communities of practice?

A CoP must in accordance with SAFe meet 3 requirements to justify exchange in Communities of Practice (which, after all, costs time and thus project efficiency):

1. the members must work in the same field (they must take care of similar tasks)
2. they must have the same knowledge, experience and application techniques
3. and they have to come together “voluntarily” because they care enough about the subject and want to help others move forward

However, it is “always” necessary to consider the lean idea that the control deadlines must bring more benefit than effort! Or, to put it another way, these exchanges must yield more time savings than the regular appointments take up time. A team member should not participate in more than 5 rule meetings, because otherwise the day-to-day work falls by the wayside – and often it is the valuable knowledge carriers who want to or should share their knowledge and experience with others. With 3 CoPs, we would be in the good average. But if knowledge holders don’t share their knowledge at all, that’s not a good sign either.

Who is organizing Communities of Practice?

CoPs can be organized, for example, by developers, testers, Scrum Masters, Product Owners and, of course, many more roles and specialists who want to exchange ideas across teams. The goal is constant learning as the basis for a continuous improvement process.

However, Communities of Practice (CoPs) need not necessarily be limited to the same roles and the same specialized knowledge. If CoPs are formed that have a specific work objective, such as the definition of epics, then a suitable and fixed selection of people comes together who, by pooling knowledge across projects, achieve the work objective faster and more economically than the multiple work by each individual project team that would otherwise be necessary.

Is participation in Communities of Practice mandatory?

The composition of a CoP should always be the same from appointment to appointment. However, the reality is that there is usually a very active and committed core team that drives the goal of the CoP. In addition, there are the regular participants who also give and take. However, there are also participants who attend only irregularly when a topic of interest to them is covered. Others are only called in by the CoP for certain topics, and then there are levels of management who – although rarely – simply want to see what the time in the CoP is being invested in and how. SAFe accepts this reality! What else can we do …

What recommendations for action does SAFe offer for Communities of Practice?

SAFe supports us with recommended actions for PoCs Since PoCs according to SAFe are self-organized appointments by teams, they should also negotiate the type of execution themselves (e.g. in person, by phone, web meetings, in the office, in the meeting room, outdoors, etc.) – and also determine the frequency and timing of the appointments themselves (of course in line with other scheduling – and this is often also where the big challenge lies in differently timed units).

Core team members of a PoC should pay attention to this:

• build and strengthen trust between participants; after all, it’s about sharing critical information: Problems and challenges
• they should keep introduced content as simple as possible and focused on the goal, thus avoiding digressions,
• they should actively speed up communication in the rule meetings so as not to waste valuable time
• they should pay attention to a common understanding of the contents and especially of the results, always asking whether everyone has understood the contents in the same way,
• and pursue the goal that more and more knowledge from all participant areas accumulates in the PoC and is distributed – if necessary also actively demanded if individual participants contribute too little.

Retrospectives should also be carried out for PoCs in order to keep the efficiency of this valuable time as high as possible in the long term.

What does the life cycle of Communities of Practice look like?

From experience, PoCs have a life cycle that can be represented as follows:

• In the beginning, someone recognizes the need for a PoC to better coordinate with others, share their own experiences for the benefit of others, or better learn from the experiences of others to become more efficient and better.
• After the goal of the PoC is defined and the effort for it is approved, participants are invited.
• In the next phase, the PoC takes place regularly, the participants exchange experiences and knowledge, solve problems together, help each other to expand their skills and thus improve their daily work.
• But at some point the open problems become fewer, the participants have built up more and more experience and knowledge. Appointments are getting shorter due to too little content, the distance between appointments is getting longer, participants are showing up in smaller and smaller numbers because, in the best Lean understanding, they are looking to use their manpower efficiently.

In the final phase, the PoC is eliminated and replaced with normal everyday communication with the relationships that have been created. The goal of the PoC has been reached.

How is management considered in Large Solution SAFe scaling?

If we look at the Large Solution SAFe overview on the top left, we see components from the Portfolio level for the first time with the Enterprise and Government icons, where the strategic decisions of enterprise management are handled. We see it here because the development of an overall solution already reflects the influence of this level – but still without tools and events. We will get to know them in the following scaling of the next but one lesson.

Now let’s summarize what we have covered in this lesson:

• we now know that the Large Solution SAFe builds directly on the Essential SAFe and adopts all the elements it contains,
• that there is a Solution Train above the Release Train,
• that solution demos enable the comparison of an overall solution with the customer’s requirements,
• that SAFe actually takes into account milestones of a planning organization,
• we also learned about the roles and their tasks in the Solution level in a very basic way,
• that if there are multiple PIs to coordinate, there needs to be something like pre- and post-PI planning,
• that in addition to the Team Backlog and Program Backlog, there is now also a Solution Backlog,
• the Solution Intent specifies the goal of the overall solution even without a portfolio basis,
• that Enterprise Solution Delivery implements another Lean Management competency,
• that shared services make economic sense in large projects and large companies,
• and we looked in a little more detail at the appropriate use of Communities of Practice.

Before the portfolio scaling that follows in the next but one lesson, there is another little surprise for you: The following lesson contains a short quiz in which you can check for yourself which content from this lesson has stuck with you. I wish you a lot of fun with it, see you again in the lesson after next!

*Source reference: 07