Scagilize Network Partner (Trainer & Consultant), Advisor & SAFe Fellow
Lean Portfolio Management (LPM) is intended for the management of investment portfolios – it is set up to help balance the investments across a set of value streams and / or solutions. It is not intended to be an administrative function to handle a set of projects or manage the flow of work for a single solution. By definition, you do not have a portfolio if you are only responsible for one value stream, one solution or, as in many cases, one Agile Release Train.
Experience though tells us that LPM techniques can be useful in these situations, particularly if you have a large amount of discretionary spend or receive your funding from a variety of different sources.
In this latest short blog series, we will look at several ways that your Agile Release Trains (ARTs) can benefit from adopting LPM Techniques, starting with the idea of using Local Epics.
In SAFe the Portfolio Backlog is made up of sets of Portfolio Epics that cut across multiple Planning Intervals (PIs) and / or multiple value streams and ARTs.
Each Portfolio Epic represents a large, longer-term investment and requires 1) a lean business case, 2) the production of a Minimal Viable Product (MVP) to prove the business hypothesis and 3) portfolio-level supervision.
To deliver a Portfolio Epic one or more trains will need to implement Features typically across more than one PI. Portfolio Epics are such significant investments that they need portfolio approval before they can be addressed by the ARTs.
The concept of Epics is also useful at the train level – previously these have been referred to as Program Epics and Solution Epics but are now referred to as Local Epics. Before Safe Version 6 I always referred to these local, non-Portfolio Epics as “Epics of Convenience” to distinguish them to more formal Portfolio Epics covered in detail in the SAFe training. I did this because 1) they do not obey the same rules as a Portfolio Epic, 2) they are optional, 3) they behave in the same whether they apply to and ART or a Solution Train, and 4) you only use them when they are convenient and make the work of the ART easier to understand.
Note:
There are times when a Portfolio Epic will align nicely with one of the Portfolio's ARTs and only require effort from that one ART to be completed. As the work is localized to a single ART, some people refer to these Portfolio Epics as Local Epics. To be clear, our Local Epics are always non-portfolio Epics and are not created as part of managing a Portfolio, they are a train level concern created whenever it is convenient for the train’s Product Management Team to do so.
This provides a simple place to start as, to be honest, it doesn’t really matter what the things you place onto the Kanban are – they could be Projects or more SAFe-like Epics – or how they are being conducted – they could be traditional waterfall projects or more agile initiatives. The simple act of visualizing the work and its state is enough to get the conversation started.
When designing your initial Kanban, make sure that it is something that everyone can relate to and that will enable them to intuitively place their work into the right columns.
Some organizations have a well-defined existing way-of-working that they can use to seed their initial Kanban. Others don’t appear to have any process at all and can start from a generic Kanban board layout, such as SAFe’s Example Portfolio Kanban. For example, my personal favourite ‘starter for ten’ board is shown below.
The Local Epics are typically created to 1) help manage the ART’s backlog and discretionary spend or 2) to represent the ART’s contribution to an external, separately approved initiative.
In the first case, the Local Epic is acting as a placeholder for a set of Features that share a common goal. They could represent, amongst other things:
These Local Epics are Epic in that they will take more than a single PI to achieve their objective.
In the second case, they make it clear what the ART has agreed to do to support a wider business initiative. For example:
The key thing to remember is that these are not Portfolio Epics – they are just created when it is convenient for the ART. Because of this, there
is:
When creating a Local Epic, it is always a good idea to follow the standard SAFe Epic Template and make sure that you clearly articulate the expected business outcomes as a set of measurable benefits. I find the best way to do this for a Local Epic is as an OKR. If the Local Epic has more than one objective, then I would split it into multiple Local Epics, one for each objective.
Leading Indicators are less likely to be applicable for Local Epics as they tend to be smaller and more focused than Portfolio Epics, and consequently generate business benefits much earlier.
When dealing with Local Epics, you don’t always need to produce a Lean Business Case.
There will be situations where creating a lightweight business case for a Local Epic will benefit the ART, particularly when attempting to justify budgets or raise funds, but generally the support of the train’s Product Management Team, Architects and Business Owners is enough.
There are many cases where Local Epics won’t need an MVP.
But be careful if the Local Epic is risky, it is not clear how the business benefits will be realized, or the Local Epic will require significant architectural change; then it is always beneficial to adopt the full Lean Start Up Cycle.
The ability to use Local Epics is a powerful tool to have in your Product Management Toolkit.
They are not part of Essential SAFe and are therefore not something that every ART will need, but they are a tool that can help you in many ways including:
The key thing is not to think that because you are talking about Epics that you are a Portfolio or undertaking Lean Portfolio Management. You don’t need to create any more roles, teams, or events to benefit from the use of Local Epics.
Attributions:
★★★★★
★★★★★
★★★★★
★★★★★
★★★★★
★★★★★
★★★★★
★★★★★
★★★★★
Copyright 2023 Scagilize GmbH