By Dr. Thorsten Janning, SPCT at Kegon AG

Introduction

The Scaled Agile Framework^® (SAFe^®) is the world’s leading Framework for scaling Agile across the enterprise. For many, the best-known and most mature parts of SAFe are the roles and practices on the program level— the home of the Agile Release Train—the heartbeat of any Agile business.

But as the industry matures its Lean-Agile practices, more enterprises are now implementing Lean Portfolio Management (LPM) on their journey toward becoming a true Lean-Agile enterprise. This involves a more extensive application of SAFe, applying SAFe principles to strategy formulation, evolving the governance structure, and aligning to delivery.

The backbone of the Lean portfolio process is the Portfolio Kanban, as it defines the flow of new enterprise initiatives within a portfolio. The Kanban implements Lean-Agile principles on this level and describes the roles and activities of the portfolio process.

In this paper we will explain our experiences and practical knowledge about the roles, artifacts, and practices in implementing the Portfolio Kanban, in some cases going beyond what SAFe describes. We hope this background will help improve planning, budgeting, and the governance of your enterprise, giving you the ability to react faster to changing markets and make value-based portfolio decisions rapidly, with transparency, and without losing control.

The Importance of Lean-Agile Principles

Before we begin however, we must take a moment to dwell on SAFe’s Lean-Agile Principles, as they are the basis for all successful practices at the portfolio level. When it comes to strategic planning and guidance of the enterprise portfolio, we find three particularly relevant:

• Principle #1 – Take an economic view
• Principle #2 – Apply systems thinking
• Principle #9 – Decentralize decision making

Why are these three so important? For managers, the suggestion to “take an economic view” seems obvious. But it’s important to recognize that the tools and metrics of the Lean economic framework differ from traditional project-control and resource management practices. After all, if we want to move from optimizing the utilization of our teams and knowledge workers to optimizing the product development lead time, we must change a lot of things, including:

• Project management techniques
• Metrics and roles
• The structure and agenda of various steering committees
• The tools for planning, estimating and prioritizing initiatives
• How the new budgeting process should be implemented

Secondly, applying systems thinking affects the portfolio process in different ways. For example, the Lean-Agile portfolio process provides new mechanisms to align stakeholders (sometimes even competing divisions) to a single prioritized backlog.

Decentralizing decision-making further informs the needed behavior of ourselves and our leaders. If we want our enterprise to respond faster, we must decentralize more decisions, letting the people make them who are closest to the problem and have the local knowledge. This results in fewer people having to wait to take action, and better, faster decisions. But to do that, we need organizational alignment. Every knowledge worker—our defacto decision-makers—must understand the vision and strategy, and be aware of risks and rewards that come with making decisions daily.

That is why it’s necessary for management not only to have a clear strategy but also to communicate it to everybody repeatedly, along with changes. This allows everyone to align their work and decisions with the communicated strategic themes and objectives, resolve conflicts between business and IT, and handles continuously changing priorities of different business divisions individually and amongst the teams.

The SAFe Portfolio Kanban System

With that background behind us, we turn our attention to the fundamental tool for the Lean-Agile portfolio process—the Portfolio Kanban system, as pictured in Figure 1. It describes the state of epics (larger enterprise initiatives) as they proceed toward their decision point.

The above Kanban system illustrates the workflow through the product development process in a state of continuous flow. One of the most effective ways to orchestrate that flow is to provide Work in Process (WIP) limits.

The practice and theory of WIP limits is easy to understand. But the practical application of those limits within the Portfolio Kanban is one of the most difficult parts of the transformation initiative. In nearly every portfolio process we’ve seen during recent years, too many strategic initiatives were started simultaneously, attempting to satisfy as many stakeholders as possible. And in most cases, the same stakeholders became frustrated later on when the IT teams were unable to implement all their requests.

For the business customer, it appears that IT is responsible for delays, long waiting times, and missed expectations. But they are doing their best, the real problem is the lack of WIP management.

An investment banking department wanted to introduce scrum to their IT-teams. A short analysis of their development process showed that the IT teams were not the bottleneck of the process: Over 70% of the cycle time was spent in analyzing business tasks before the development teams received the new investment product requirements. After we implemented an Agile portfolio process with a WIP-managed Kanban, the analysis time decreased by over 50%.

During the portfolio process, we limit WIP by only analyzing and committing work that can actually be delivered by the Agile Release Trains (ARTs). This can be a political tightrope act as demand always exceeds capacity.

These experiences illustrate why implementation of the Portfolio Kanban is not a trivial task. For it to succeed, we need to answer the following questions:

• How are the defined SAFe roles working and cooperating at the portfolio level? And who else, based on our experience, should be working at the portfolio level to drive the epic forward?
• What are the results and policies for the different Kanban states and how will they be documented?
• How can portfolio practices like leaner estimating and governance be explained and implemented?

The Roles in the Portfolio Kanban

The Kanban system is a workflow management mechanism, but people do all the work. SAFe describes the roles of Epic Owner and Enterprise Architect to help with this process. In addition, in the SAFe ‘Coordination’ article, we also see Solution Portfolio Management and Agile Program Management Office (APMO) as additional roles on the Portfolio Level.

But how can they be implemented successfully and what are the known patterns and antipatterns for their work? We’ll describe some of our experiences in the sections below.

The Epic Owner

In SAFe, the Epic Owner is a responsibility assumed by an individual, not a job title. The Epic Owner plays a central role in our Lean-Agile portfolio process because they must drive their epics through the whole Kanban system.

Besides their experience in their business area and in managing complex topics within a politically diverse system, Epic Owners have to understand the foundations, characteristics, and tools of a Kanban system, as well as developing an understanding of broader Principles of Product Development Flow [1]

But who is qualified to take on this responsibility in organizations just starting their Lean-Agile journey? Often, there are Program Managers or Business/Project Managers who have some of the required skills and traits of an Epic Owner. However, since most of them have worked in traditional, non-Lean-Agile environments, they need to be trained in the new mindset, principles, practices, tools, and metrics.

The Enterprise Architect

Enterprise Architects promote adaptive design and engineering practices while driving architectural initiatives for the portfolio. In doing this, they act like Epic Owners, who start architectural initiatives across Large Solution Trains and ARTs and drive them through the Portfolio Kanban. This role usually is working successfully if the enterprise architect is not captured within an ivory tower of traditional top down thinking. That is the reason we do not have to describe this role in more detail here.

Lean Portfolio Management (LPM)

SAFe describes an LPM function which “has the highest level of decision-making and financial accountability for the products and solutions in a SAFe portfolio.” The first step before implementing LPM in an organization is to understand the existing management teams, processes and steering committees:

• Which committees are active?
• Who is a member?
• Who has the authority to make which decisions?

When we start an Agile transformation, we usually see many committees with overlapping sets of members disagreeing or even overruling each other, which leads to gridlock and internal politics. Therefore, the essential requirement for building a successful LPM is that there is only one committee deciding on one portfolio backlog

In a development department employing about 500 knowledge workers, before we started the new LPM, we eliminated more than 20 committees, mostly project-specific steering committees which had accounted for about 80% of all existing prioritization decisions.

After you have successfully defined your LPM, the preparation begins. The next step is to define the calendar for the monthly LPM events and to create a meeting agenda. The agenda in Figure 2 is one starting point.
The policies for decisions are mostly defined in the columns of the Portfolio Kanban.

As we can see in the agenda, the LPM looks not only at the Kanban and the backlog but also at the reports on the current state of the implementation. The Agile PMO can play a vital role in providing those reports, as we will learn in later sections.

Of course, not every epic pulled into the next Kanban state has to be discussed in detail, only a subset needs to be reviewed. The selected portfolio backlog items will be presented by the responsible Epic Owner. In our cases, we have seen that only about 20% to 30% of epics have to be discussed in detail. All others are decided by the responsible Epic Owners in collaboration with their Business Owners. The higher the percentage of ‘not discussed’ epics in the LPM is, the higher is the maturity of the organization regarding decentralized decision-making.

Budgeting and Planning

Experience also shows that most sessions have a special focus. At least once, and possibly two or three times a year—the focus should be on budgeting and longer-term planning, as we describe below. There are several aspects of budgeting:

• Defining budget size and allocation for Solution Trains and ARTs. The LPM has to decide whether the portfolio promises enough value to expand the implementation teams ( the existing set of ARTs and/or Solution Trains) to increase or extend their budgets, or perhaps to reduce them as solution lifecycles naturally wane.
• Capacity allocation for maintenance, technical debt, and new architectural work. Allocating funding to the type of work is important, too. LPM takes a fairly broad view of these factors, but prioritization in the allocated budgets should be decentralized to Product owners and System Architects, and need not be managed in detail by the central portfolio process.
• Managing resources and skills. After reviewing the portfolio epics with the highest values, LPM also has to estimate which knowledge and skills are necessary to implement them. Are there growing ‘know-how’ bottlenecks? Do we have to educate and train current staff and/or hire people with the desired knowledge? (For this, we sometimes implement an additional role within our leader team: the Skill and People Lead. This person is responsible for coordinating all activities in the organization regarding the “leader as people developer” role.)

Every few months (depending on the PI cycle) the LPM has another main focus: deciding which epics are to be pulled into the implementation column to be planned in the next PI Planning.

A third area to review are the ideas in the funnel, deciding which have the potential to be high-value epics. Sometimes it will be necessary to dive deeper and make a detailed analysis. This might utilize some capacity from of the trains and, therefore, has to be discussed in the next PI Planning session.

A sample calendar is shown in Figure 3. We see that there is a clear rhythm of focus between a more strategic view and a more operational view on the portfolio backlog.

The Agile PMO

The Agile Program Management Organization (APMO)—along with the Solution Train Engineers (STEs) and Release Train Engineers (RTEs)—is typically responsible for supporting decentralized but efficient program execution. It provides support for standard reporting patterns, shared best practices, and the growth and dissemination of institutional knowledge.

The APMO works as a service unit for the trains. It collects the data from the running trains and aggregates the reporting to inform the work of the LPM, the Solution Portfolio Management, and the Epic Owners.

A clear indicator of the maturity of the Agile transformation initiative is when the portfolio has defined a new system of metrics and reporting. Often, when first attempting to build a Lean-Agile portfolio, the controlling team does not want to relinquish the well-known traditional project management metrics, such as supervising projects as cost centers or objective of scope-orientation. But traditional metrics in a so-called Lean-Agile environment are the controlling surface of a conventional project management culture. A closer look often reveals traditional project budgeting processes as well as traditional management practices. If we truly want to implement a Lean-Agile portfolio process, we have to change our reporting as well as our metrics. That is the subject of the following section.

Portfolio Metrics

The following metrics have proven fairly straightforward to collect and accurately reflect the progress and effectiveness of the trains we have been involved in.

Value Stream Map

The starting point for our learning about the whole development value stream is a so-called value stream map [2] to identify bottlenecks in the system, as shown in Figure 4. The ratio of the sum of value-adding working times and the overall lead time is a good indicator of the progress and maturity of our Lean-Agile transformation initiative.

Cumulative Flow Diagram

If we have got a good understanding of the value stream, we are able to define our initial Kanban system. This Kanban system provides the most important metric set: the Cumulative Flow Diagram (CFD) of the Portfolio Kanban system. An example is illustrated in Figure 5.  The CFD helps us to identify bottlenecks, the size of batches in our Kanban states, and the average time an epic stays in a state. With all this information we can more actively manage flow in the portfolio process.

Epic Progress Report

Tracking epic progress is somewhat similar to traditional project metrics. In Figure 6, we see the baseline of the first estimate for the job size of our epic (red line) in comparison to the current estimate. Furthermore, we see how much of the epic has been finished compared to the original estimate.

Value and Cost BurnUp

But there is one important difference in the Lean-Agile management of the epic’s progress: Because we are following the Lean-Agile Principle #4 – Build incrementally with fast, integrated learning cycles, we always have to compare the Weighted Short Job First (WSJF) of the rest of the epic- against the WSJF of new or competing epics in our backlog. To visualize this, we can use the Value BurnUp and Cost BurnUp metric for epics, or bundles of epics, as shown in Figure 7.

When we are working with stable teams the cost burnup is typically linear. Conversely, the value burnup should be growing quickly in the beginning when the small and most valuable epics and features are developed and delivered. The ratio of the value Cost of Delay (CoD) against cost is getting worse and worse over time and therefore, in most cases, we will finish the implementation with less than 100% of the total scope. This is very different from traditional project management.

Implementing Solution Portfolio Management

As described in the Coordination article, when portfolio value streams cooperate to a larger end, the Solution Portfolio Management role is responsible for guiding a portfolio to a set of integrated solutions. This can be an individual, a function of LPM, another construct, or whatever, but we’ve done it several times by implementing a scrum of business people on the portfolio level, which we call ‘the Portfolio Scrum Team.’

The Portfolio Scrum Team

In addition to driving the epic through the whole Kanban system, the Epic Owner must be able to manage communication in a team of stakeholders—including Business Owners and/or Business Analysts—to deal with scope, competing requirements, and constraints according to the epic.

To foster fast learning cycles with rapid decisions, we have to implement a communication process that enables all parties to recognize dependencies between epics and design in a transparent environment. Fortunately, we know the successful communication pattern for this: the Scrum Team! This is why we implement it at the Portfolio Level. All stakeholders meet regularly to share their current state of knowledge and work, and to review dependencies between their business areas.

We created a portfolio scrum team within an investment bank portfolio process. A value stream analysis indicated that over 70% of the lead time of the development for a new financial product was spent for analyzing the business requirements and restrictions, before any IT assignment. While our portfolio scrum team discussed the current state of their analysis every week, and each member pulled new tasks for the next week, the lead time for the business analysis has been reduced from the estimated nine months to less than three months!

This portfolio scrum team is able to analyze an Epic and provide a rough estimate. If they need more detailed information, they talk to the responsible Product Managers or Product Owners and–if necessary–ask them to estimate future epics or parts or variants (MVPs) in their teams’ refinement sessions. If that isn’t enough, they could also define an analysis enabler feature to be prioritized for the next PI of the associated ART. This makes it possible to get valid estimations of CoD and job size to define the WSJF for the epics after a short time and with minimal effort.

While epics were going through the portfolio Kanban, the team was collecting knowledge and design decisions for it.  For example, rough product ideas and visions could be refined to advance:

• Epic hypothesis statements
• Business outcome hypothesis
• Personas
• Requirements non-functional requirements (NFRs)
• Architectural design decisions
• Business case calculations

This information is collected and consolidated from workshops organized by the Epic Owner. Our experience shows design-thinking workshops, mapping the operational value streams and architecture workshops yields the most useful insights, as shown in Figure 8.

The result of the analysis is to build knowledge about the business and design decisions which can be collected in SAFe’s Solution Intent. We find that the SAFe standard template to describe the epic, the Lean Business Case, is often insufficient for the complexity of such products. We have been very successful in using the Product Canvas or Business Model Canvas [3] as templates for complex solution intent.

During the preparation phase before the next PI planning, the canvases provide a valuable foundation to refine the epics even further and split them into features. Impact Mapping [4] helps facilitate this step.

The final result of the analysis during the portfolio process is not only the description of design decisions and specifications but also the estimation of value, (CoD) and cost (job size). We apply WSJF to prioritize them. WSJF is defined as the estimated  Cost of Delay (CoD) divided by job size, which determines the WSJF value (see Figure 9). To be able to rank our epics in the portfolio backlog, each of the four WSJF parameters has to be estimated. By performing the team estimation game, we were able to prioritize up to 40 to 50 epics in half a day.

Even though we now had the first ranking, the hard part of prioritizing the portfolio backlog lies ahead. In nearly all of our customer cases, at least one of the portfolio team members was not satisfied with the result: “This strategic epic is ranked too low by the WSJF! It is obvious that the metric doesn’t work!” Usually, the reason is the large job size of this important epic. Now, it’s the responsibility of the facilitator to start a discussion about whether it’s possible to define a smaller MVP of the epic, one with most of the original value but only a fraction of the job size. When you succeed, you will be implementing a real Lean portfolio process!

To split the epics, we can use well-known Agile requirements engineering techniques, such as story mapping and story splitting. Because new epics arise, and the values (especially the time criticality value) are changing over time, we have to repeat this estimation workshop every few weeks. If the prioritization of an epic has changed dramatically, it will be discussed in the next LPM meeting.

Summary

The Scaled Agile Framework supports the Lean enterprise via the principles and practices of the continuous solution development flow. The entire product development process—from epic to user story—is implemented by a nested Kanban system. The Portfolio Kanban describes the highest level of this flow over the product lifecycle. As we apply SAFe and scaled scrum practices to limit the WIP on the program and large solution level, the Kanban on the portfolio level has to serve to guarantee the flow to fill the higher level backlogs effectively, without overloading the system.

The roles, practices, and artifacts of existing Portfolio Kanban systems described in this paper have proven to be successful for the implementation of a complex— but Lean—portfolio process. But, to be honest, we are all on just the beginning of this long, Lean portfolio, learning journey

Learn More

[4] Adzic, Gojko, Impact Mapping Making a big impact with software products and projects, Provoking Thoughts, 2012.

Last update: 2 April, 2018