Hi, welcome to this lesson where we will look at SAFe portfolio scaling.

What content is covered in this lesson?

We’ll talk about in the next few minutes:

• Corporate strategy,
• the Business Model Canvas and the Lean Canvas,
• the SWOT Analysis and the TOWS Matrix derived from it,
• Budgeting,
• the Corporate Portfolio,
• the Portfolio Backlog,
• and the requirement objects Epic, Capability and Enabler,
• and ultimately also about Prioritization.

But now to the content of this lesson:

How does Portfolio SAFe scaling differ from Large Solution SAFe scaling?

As announced in the last lesson, the SAFe portfolio complements the strategic requirements from business management. The Large Solution SAFe is not absolutely necessary for this. Depending on the requirements, the Portfolio SAFe can also be directly based on the Essential SAFe – as you can see in this overview. The Large Solution SAFe layer covered in the last lesson is missing here.

Attached to this lesson you will find a PDF in A3 format with the Portfolio 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 Essential SAFe and Large Solution SAFe scales assume that requirements come from somewhere. Practically out of nowhere. Sure, the requirements are defined in the departments and have received their objective somewhere above. But that hasn’t played a role in the scalings so far. They were just there.

By which influences is the corporate strategy driven?

For the first time, Portfolio SAFe accesses the goals of corporate management and links strategic business requirements as well as regulatory requirements to a vision – the Portfolio Vision.

The strategy of a company is driven by different influences, such as

• from a vision, i.e. the state considered in the long term that the company should achieve in the future,
• or from a mission, the business outlook in conjunction with the vision, which together define the framework strategy,
• or the company’s self-imposed core values, which determine the actions of the company and the individual employees,
• or the changes and trends in the industry that affect the business,
• or the special capabilities that give the company an advantage over the competition,
• or financial targets of the partners or shareholders, targets for sales, profitability and market share,
• or the competitive environment, from which analyses of the greatest threats to one’s own position lead to the constant realignment of corporate strategy,
• or constant awareness of the current status of its own performance portfolio and the achievement of the targets defined by the shareholders.

Most of these goals come from the company owners, the shareholders or shareholder representatives. Only a few of these goals come directly from operational management, such as the board of directors or division managers.

What is a Business Model Canvas (BMC)?

Now it is not as if the design and continuous development of a business model by the operational management, from which the strategic goals are derived, would be easy. No, there are some mutually influencing factors here, for the most important components of which the BMC (the Business Model Canvas) has become established in large companies. As the term implies, this canvas-sized template maps the most important factors for corporate success, making it a permanent fixture in the minds of management. This overview ideally hangs where the business or division management meets regularly – e.g. in a meeting room reserved for this purpose – and is constantly updated and developed there. The aim here is to ensure that there is no time lag in the face of changing market requirements. One of the most damaging situations would be if the management were to deal with the further development of the business model only 1x per year or even less frequently – and unfortunately this situation is not that rare. Experience shows that the smaller the company, the less frequently the business model is adapted to constantly changing market conditions. I won’t go into the consequences of this now, because we are primarily concerned here with the fundamentals of SAFe. SAFe takes a common management method here and incorporates it into the agile organization.

What is the content of a Business Model Canvas (BMC)?

The classic BMC can map any business model – from start-ups to large global corporations. It consists of 9 mostly independent blocks that in sum describe a business model and help us grasp the complexity and focus on adjustments.

• The focus is on the company’s value proposition, i.e. the successful sale of products and services which the company produces and which offer corresponding added value for the customer, but ultimately also for the shareholders and partners.
• On the left side next to it, we record the most important prerequisites, and on the right side we record the most important sales-related plans for achieving the value proposition.
• Key partners include key customer and supplier relationships and competitive alliances that help deliver the value proposition.
• The key activities describe the most important actions to sell the products and services.
• Key resources describe the human, physical, intellectual, financial, and other capabilities and assets most relevant to success that the company needs to achieve its goals.
• Customer relationships describe the various methods of approaching customers in order to sell products and services. Marketing and sales play a major role here.
• In the customer segments, the different customer groups are described according to common characteristics so that they can be viewed and addressed specifically.
• The sales channels describe the ways in which the company intends to sell its products and services through to the end customer – e.g. the involvement of intermediaries, intermediaries or direct service to end customers.
• At the very bottom left we record the cost structure of the company e.g. for
  • Development
• As a counterpart, so to speak, to the Cost structure, the flow of sales records the Revenues for its products and services, broken down by product and service groups.

With this model, a complex corporate structure can be represented as a whole, but also broken down for each business unit in such a simplified way that it can be worked with clearly.

What is a Lean Canvas?

There is one catch to the BMC for an agile organization: it doesn’t quite reflect the rapidly changing business world of a disruptive marketplace with its perceived unfair practices and associated problem sets.

How does the Lean Canvas differ from the Business Model Canvas?

And it is precisely this challenge that Ash Mayura’s Lean Canvas addresses. 4 of the 9 blocks correspond to the standard BMC as far as possible, the other 5 modified blocks I would like to take a closer look at with you:

• The center of the business model remains the value proposition, but in an ever faster changing agile world it becomes the “unique” value proposition. And that’s not just a label: the company’s management really has to think here about how to develop a value proposition that may be comparable with global competition in such a way that it also becomes unique in real terms. This then also includes raising the previous flight altitude somewhat and taking a look at adjacent markets not yet covered or not missing out on emerging technologies that seem to be outside one’s own field of business. Once again, openness to new things is called for and the entrepreneurial courage to take new risks.
• Long-term partnerships are necessary and meaningful even in an agile world – and should be maintained. Due to the shifted priorities, however, the problems encountered in the further development of the business model are replaced by problems that arise in a dynamic competitive environment in which not only traditional competition but also completely new players with new business models challenge the company’s own business model. Above all, however, one thing is important: there is no point in leisurely developing existing products and services on the basis of newly arising problems. Genuine viable solutions with future and margin potential are created through new development based on identified challenges. To do this, it is important to identify and understand the problem for the currently existing business model as comprehensively as possible. This also involves disruptive developments that make previous products and services obsolete or purely a vehicle for value-added services based on them.
• And that is no way to shape the future. Solutions are needed for these problems – which brings us to the next block that replaces the key activities in classic BMC.
• Instead of being aware of the key resources in the company in a kind of self-centeredness and developing products and services on this advantageous basis, orientation to market needs is necessary in a rapidly changing market environment.
  • Where do the existing customers orient themselves?

For all these and similar questions I need solutions and at the same time measuring instruments that show me

• whether my solutions satisfy the need,
• whether this need still exists with my finished solution,
• or whether I was too slow and should therefore use the remaining resources for other solutions.

In the best agile sense, the question here is necessary after each iteration or at each board meeting,

• whether the current solution still meets the current requirement
• if not, whether there is another solution for the changing requirement
• and if not, whether the remaining resources and budget would not be better served by a completely new solution.

And for such decisions, the Board of Management or divisional management needs a basis for decision-making. We then find these well prepared in the block of key metrics.

• Instead of dealing with sophisticated marketing and sales strategies in a market of approximately equal products and services, I try to gain so-called “unfair advantages” in an agile market environment, which would be, for example:
  • tangible or intangible assets that the competition does not have and that cannot simply be acquired on the market, but which relate to the same competitive challenges,

In this way, I arouse the interest of customers with minimal marketing effort and bind them to me permanently due to a lack of alternatives. Ideally, as a company, I develop a reputation as an innovator and market leader that customers automatically follow and stay connected with for a long time, even if the products and services are not quite optimal.

The only question is: how do I get such an unfair advantage? This question is answered by the companies that are making life difficult for the traditional market players and upsetting entire industries with disruptive business models:

They constantly have an open eye and ear for

• companies that have technologies, products or services that support their own business model,
• for companies that have an idea to develop promising benefits for their own business model,
• for companies that have rights and patents that are needed throughout the competitive environment,

and they simply “buy” this advantage with the assumption that one of these investments will pay off in a big way. Please remember the acquisitions of the Big 5 from one of the previous lessons.

What is a SWOT analysis?

Well, we have now understood how a business model can be mapped in such a way that it can be constantly developed. With this, we know where we want to go. To know where we are at the moment, there are techniques, such as SWOT analysis, which can be applied to any small individual area in the company. I compare my own strengths and weaknesses with the strengths and weaknesses of the competition in a quadrant. Or, as we have since learned, even better: I contrast my strengths with the possibilities yet to be achieved and my weaknesses with the dangers involved. The difference results in each case in the need for action. This makes the SWOT analysis a good way to put my existing business model to the test and identify areas where action is needed. But what options do I have to achieve the identified goal?

What is a TOWS Matrix?

The TOWS matrix (also called strategic option matrix) is a good choice for this purpose. As you can easily see, this is derived from the SWOT analysis. The results of the SWOT analysis are entered here in the outer boxes. By looking at the given questions of the matrix in relation to the associated entries from each of 2 associated boxes, we arrive at the strategic issues that need to be resolved to achieve the goals in the business model.

And it is precisely these strategic topics, which are prioritized and budgeted by the operational business or divisional management, that then form the package for a portfolio of measures, which, together with a rough time schedule for implementation, is monitored over the term for target achievement.

What does Agile Budgeting mean?

There are fundamental differences in agile budgeting compared to traditional budgeting for waterfall projects.

• While waterfall projects are budgeted and scheduled based on a fixed plan, agile projects only budget for the value streams of a portfolio. There is no time specification here.
• While human resources in waterfall projects are assigned to a fixed temporary project team, in agile projects human resources are assigned much higher to a value stream of a portfolio – which enables the use of these resources in multiple project teams, and this is necessary in agile organization with its constant adjustments. Personnel are deployed from a higher level where they currently add the most value.

Attached to this lesson you will find a PDF in A3 format with the comparison of traditional budgeting and lean budgeting. Feel free to print it out and hang it on the wall in your project room as a basis for discussion and explanation for the team – especially in case there are discussions with the controllers or the project management again.

While for smaller companies a portfolio with the measures contained in it and a value stream is sufficient, in which the strategic themes map the vision, in large companies we find a larger number of measure portfolios. This then allows several divisions acting in greater independence to be combined into one organization – an organization that can work together via a uniform agile organizational model despite all the interfaces and independence.

How are requirements handled at the portfolio level?

After we have approached the target state of the business model from the existing business model via the measures to be taken, the question for us is how to bring these requirements towards realization. This is precisely why SAFe has the portfolio backlog, in which the requirements of a portfolio are collected, processed, and monitored until they are implemented. So there are multiple portfolio backlogs: a separate backlog for each portfolio. The top level of a requirement from management in the backlog is an Epic. The management member responsible for an Epic is the Epic Owner, but multiple Epic Owners can be registered per Epic. An Epic is broken down to several Capabilities, which more precisely define the required capabilities of the Epic.

There is one exception here for large companies. Here, the operational management is only responsible for the development of the Epics due to the large number of actions to be taken. The development of the necessary capabilities is already taken over by the subordinate organizational structure in the form of the divisional management required for implementation, which assumes the role of enterprise architect with the support of consultants if necessary. In this context, it should be mentioned that in addition to Epics from management, Epics in the Large Solution level and the Program level can also arise in the form of Program Epics. In this case, the management Epics would be referred to as Portfolio Epics to differentiate them. This can be mapped organizationally in SAFe without any problems. However, for better clarity, I personally prefer to reserve Epics for management. In addition, the implementation of SAFe in software solutions is always different and thus often limits the SAFe possibilities.

What does an Epic look like?

What an Epic actually looks like and what content is necessary is basically decided by each company according to its needs. Here we see an example of what an Epic might look like and what content might be needed to fully define it. I’ll go into more detail about all the requirement elements in the sequel to this course series. This should be just a small impression for you that you can do something with the term Epic.

Is an Epic a project description?

Some project members get the idea that Epic, as the top-level ordering structure for defining requirements, could be the project description. But it is not like that:

• A project almost always contains several epics, which are divided downwards in the form of a tree structure into one or more programs and these again into one or more project teams.
• An Epic almost always affects different projects, and therefore the same Epic is used as the top-level ordering structure in different projects.

An Epic is a long-term requirement that continues to exist over the duration of multiple projects and beyond until the requirement is no longer necessary due to underachievement or changing conditions. Unlike the subordinate order structures in the Large Solution level, Program level and Team level, it does not have a fixed start and end time, but is performance-driven.

For example, the Kanban Board for the Portfolio Backlog might look like the one shown here:

• The funnel (the first swim lane on the far left) is where the Epics in progress gather.

• When the Epic is ready, a review meeting is held between the Epic Owner and the department heads affected by the Epic to communicate the content, clarify questions, and initiate any necessary rework by the Epic Owner. A multiple commuting process is absolutely common here because vague assumptions must be avoided. The Epic must be unambiguous in all points and clearly understandable and actionable for the next level of processing. Of course, the same applies to all other request objects.

• When all ambiguities are resolved, then the division managers analyze and complete the Epic with the subordinate requirements necessary to achieve the goals, and use them to work with management. Capabilities describe the additional abilities required in the areas that a solution must bring to the Epic. Due to the higher flight altitude, the top management does not recognize the scope for implementation or only incompletely. Therefore, the addition in the form of Capabilities is explicitly provided for in SAFe.

In the Large Solution layer, the “rough” capabilities of a solution are described by Solution Architects with Capabilities (we already discussed these in the previous lesson, so this layer is not listed here). These are still requirements descriptions at the division manager level. These rough requirements still have nothing to do with the description of a requirement from the business departments, because these are only described in User Stories at the Program level. In addition, there are also so-called Enablers – always when experimental content is involved, i.e. when a solution is not yet tangible or recognizable and therefore a path to the solution must first be found. This includes creating the conditions necessary to implement an Epic or Capability.

For all Capabilities and Enablers, the effort is estimated in Story Points and then summed in the Epic above. This gives the “estimated” total effort per Epic, which then leads to the appropriate budgeting. Between you and me, these estimates are often miles off the actual necessary expenditures. In addition to an exaggerated desire to save money, tight budgets are also due to this estimation process – and not just to poor team or project performance. That’s just by the way. But how is the management level supposed to make a realistic estimate when the solutions are unmanageably complex? This can only be done with the best of intentions and by drawing on empirical values. At this step, for example, due to too high expenses or non-feasibility due to lack of funds, the decision can also be made to drop the Epic again.

• When the complete analysis is finished, the Epic is feasible and enriched with the previously described content, yes: then the Epic with all created subordinate elements (in detail: Capabilities and Enablers) ends up in the Portfolio Backlog swim lane. Once Epic starts implementation, it moves to the implementation swim lane, where it is monitored with appropriate measures, such as milestone reviews. The implementation itself consists of the development and operation (or application) of the Epic. The value contribution is also constantly measured during the application of the Epic.

• Only when the value contribution falls below an acceptable threshold or the Epic is no longer necessary due to other influences, it is moved to the last swim lane Done and thus deactivated. Which doesn’t mean it couldn’t be reactivated, because the effort to implement it has been made. Reactivation is thus associated with little effort.

What does WSJF (Weighted Shortest Job First) mean?

The Portfolio Backlog maintained by management is prioritized using the Weighted Shortest Job First method (also referred to as WSJF for short). Roughly speaking, everything is prioritized upwards that can be implemented quickly and with little effort, while providing as much benefit as possible.

To determine this, there is a point system, the sum of which is then sorted so that the highest values end up at the top. This prioritization is constantly updated and always the top positions are processed in order.

How is WSJF used in release planning?

Once the processing sequence has been established based on WSJF, the Epics and Enablers can be distributed to the next product increments. An Epic is usually divided into several increments until the number of estimated Story Points is distributed – as can be seen nicely here in the example. Since the Epics contain content from different Programs, the respective program content is assigned to the corresponding Release Trains – illustrated here in the figure with the different colors.

Now that the Epics and Enablers are also visually in a coordinated Value Stream, these requirements can be scaled according to SAFe

• together with the Solution Train Engineer (STE for short) and the Solution Management in the Solution Train of the Large Solution SAFe
• or schedule directly into the Agile Release Train of Essential SAFe together with the Release Train Engineer (RTE for short) and Product Management.

Further planning is then based on the released capacity and priority in the product increments. These decisions are made at a PI meeting, which includes all involved roles from all levels. From the team level, in addition to the Scrum Masters and Product Owners, only the most experienced team members suitable for the submitted topics participate. The story points are divided among the sprints (shown here as iterations) according to capacity. This then also enables management to preview the time of realization – in the best agile sense, of course. Planning is alive and the timing is constantly shifting based on WSJF (Weighted Shortest Job First: as a reminder).

That should be it now also to this somewhat more extensive SAFe scaling. We have learned a lot in this lesson about the origins of requirements, which is extremely important for mutual understanding between employees and project teams.

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

• we now know that portfolio scaling contains the strategic requirements of the company’s management and shareholders and thus the corporate strategy,
• with the BMC and the Lean Canvas, we have become acquainted with two tools that can be used to develop a corporate strategy,
• we took a look at the SWOT analysis to determine the status quo in the company,
• as well as to the TOWS matrix in order to identify the challenges to be solved on the basis of the SWOT analysis.
• We looked at the difference between traditional and agile budgeting,
• recognized the portfolio level as a basis for cross-divisional collaboration,
• get to know the Portfolio Backlog and its requirement objects,
• and we took a look at the basics of agile budgeting and prioritization using WSJF.

IIn the lesson after next, we will combine all the SAFe scalings we have learned so far.

But before that, we have another little surprise for you: The following lesson contains a short quiz where you can check for yourself which contents from this lesson have stuck with you. I wish you a lot of fun with it, see you again in the lesson after next!

*Source reference: 07