“Always show your working out!” was the mantra of my maths teacher in senior school. This series of blog posts “On the Nature of Lean Portfolios” is an exploration of Lean Portfolios. It is the thought processes running through my mind, exploring the possibilities so that I understand why things are happening rather than just doing those things blindly. It is not intended to be a fait-accompli presentation of the solutions within Lean Portfolios but an exploration of the Problems to understand whether the solutions make sense. There are no guarantees that these discussions are correct, but I am hopeful that the journey of exploration itself will prove educational as things are learnt on the way.
What Is A Lean Portfolio?
The very first posting in this series tried to answer the question “What Is A Lean Portfolio?” and to provide a storyline around what it is that a Lean Portfolio is trying to do. The footnote to that post was that as it was released to the public I had just had a conversation with Luke Hohmann who suggested that organisations don’t care about the detail of the value streams and development; they just care about the solutions. I didn’t have time to rework the first post, hence the footnote, but as part of the SAFe 2021 Summit I’ve reworked the explanation of Lean Portfolio to be solution focused. This blog is the Summit presentation but with a couple of other asides that didn’t fit the very tight timebox and all the crosslinking to underlying references that can be done in written word but can’t be done as easily with spoken words. The video version is available here.
A long lived, self-organizing, self-directing, investment vehicle.
This differs from the colloquial use of the phrase Portfolio where people tend to mean “a collection of things” and indeed it is that usage that other methodologies use; in PMI:
“A portfolio is a collection of projects and programs that are managed as a group to achieve strategic objectives.”
When we talk about Portfolio think Investments. A portfolio has to be big enough to have autonomy to manage investments; to be able to balance those investments.
- Don’t make the mistake of instigating a Portfolio too small so that there is no scope to move money around.
- Don’t instigate a Portfolio around work, or a collection of work, because work is transient. It is not long lived.
- When instigating a Portfolio think divisions, think about it running as an independent business.
Do not rely on your historic definitions of Portfolio because if the people involved don’t have real choice of how the money gets spent then they are just administrators; we need to head up the line to find the real decision makers. Follow the money and find the people that can make real spending decisions.
The Portfolio isn’t there for the fun of it; it has some Outcomes that it is trying to achieve.
Those outcomes need to be measurable in order to understand whether the Portfolio is, or isn’t, being successful.
The individual changes that the Portfolio is trying to enact can be expressed as OKRs, Objectives & Key Results1. What makes OKRs useful is that the Key Results provide clear indication of a potential strategy for achieving the objective and how it can be measured.
KPIs, Key Performance Indicators are used to measure trends in the emergent properties of the Portfolio. Profitability, system uptime, customer satisfaction; these are not one-off things, they need to be assessed continually. They provide insight into whether the Portfolio is running smoothly. If the KPIs start straying from acceptable limits, take remedial action.
Where do those Outcomes come from?
They could be internally generated and if your Portfolio is the entire organization then they will be.
However, often a Portfolio exists within a bigger business context and the needs of that bigger business will influence the Outcomes that the Portfolio is trying to achieve. In SAFe those needs are known as Strategic Themes, the longer-term aspirations of the bigger business and they become the inputs that influence what the Portfolio is doing.
The outputs should be aligned with inputs; but a portfolio needs to be empowered to do whatever it needs to do to try to achieve success.
“With great power comes great responsibility”2; empowerment runs both ways.
A Portfolio should be empowered to do whatever it likes, but if a Portfolio isn’t contributing enough to goals of the bigger business, then bigger business is empowered to cut the portfolio.
This is business, and the business will close entire divisions in order to save the bigger business.
Conversely, if the Portfolio doesn’t have empowerment to decide on what and how to do things, the lack of ability to pursue at least some of its own work means that its tools, processes and architecture will suffer and most likely fail.
Now we know what we’re trying to achieve, the Outcomes, and that they line up with any bigger corporate goals, the Inputs, then the Portfolio can express all of that as a Future Vision.
A description of what it is and what it is trying to achieve.
- The bigger business will want to check that the Future Vision is aligned with the inputs, the Strategic Themes
- All the staff within the Portfolio need to know the Future Vision so that they can make sensible decentralized decisions that move the portfolio towards that Future Vision.
I will fully admit that there is an argument to be had about whether Outcomes come first or Vision? Chicken or egg? My eventual rationalisation was people tend to know what they want, the outcomes, then they construct a vision to communicate it. Therefore, I chose the sequence Outcomes, Inputs, Vision. If it were Vision, Inputs, Outputs would it matter? As long as the portfolio ends up with a Future Vision to give it direction and a set of Outcomes that describe how progress towards that vision is going to be measured; then it’s good-to-go.
That Vision should be generated in a collaborative fashion. There’s a joke about Agile people hating forms but adoring canvases. Why? After all, canvases are just forms printed on giant sheets of paper. The answer is that forms are filled in by individuals whereas canvases are filled in by groups, and it’s the group collaborating that brings alignment and agreement to that group. The Portfolio Vision is developed collaboratively by the Portfolio stakeholders to bring the group of stakeholders into alignment over what the Portfolio is trying to achieve. SAFe’s suggested process take that one step further and utilise a set-based approach; a number of groups drawn from within the Portfolio are utilised to generate multiple potential future visions from which a Future Vision can be synthesized.
To achieve those Outcomes, we need some Solutions.
I’ll probably upset some within the SAFe community by saying this, but Lean Portfolio Management doesn’t actually need SAFe. A Lean Portfolio can operate completely separately from whatever is going on below, the Portfolio shouldn’t need to care. As long as the Portfolio can get work down to the teams and results coming back who cares what methodology they’re using!
Those Solutions could be generated by:
- Buying them in
- Outsourcing them
- Developing them
Those Solutions could be anything, they don’t really have to be the results of an engineering endeavour.
The challenge with a completely generic Portfolio is not that it’s any harder to manage but that it’s harder to provide training and advice around the details. Therefore, SAFe constrains itself to managing Development Value Streams rather than Value Streams in general.
If we’re constraining ourselves to SAFe’s definition, and to avoid upsetting the SAFe community I probably should, then those Development Value streams are produce solution. Those solutions could be:
- Products or Services we offer directly.
- Systems to allow us to do business. In organisations such as financial institutions the solutions support the products being offered rather than being the product itself.
- The design of what is manufactured by a production line, or the solution could be the production line itself; the means to produce the product.
The business doesn’t really care how it gets those Solutions. It could be Projects, could be Release Trains, could be Dancing Unicorns, the Business just wants those Solutions so that it can achieve the outcomes it desires.
As the people responsible for those Solutions though, we do tend to care how they are obtained. We are after Solutions that are:
- Desirable: in that people want it
- Viable: the Benefits outweigh the costs
- Feasible: we have or can obtain the skills, services and systems to develop the solution and
- Sustainable: we can keep it going for as long as required.
However, those solutions aren’t free…
We need to secure some funding.
If the Portfolio itself sells Product, then the funding is the revenue generated on those sales and because the Portfolio raised that cash itself it will have free choice over how to invest it.
Sometimes the Funding is delivered from on-high, a bag of cash from the bigger business, or other parts of the business. That funding may come with expectations, the bigger business expects certain Outcomes in return for providing the funding. The Portfolio should still have choice over how it invests that funding, but it will have to invest wisely to meet the expectations.
The most problematic is if funding is attached to work being done. The investment decisions are now constrained by the fact that the work will consume the funding first and only once the work has been done can the Portfolio invest the remainder, the profits. It might sound like a good idea to give the work the money but if the strategy changes and you need to do something else, it’s very hard to get the old, now irrelevant, work to give up that money!
If you’ve ever wondered why SAFe’s Portfolio advice seems a little schizophrenic, you can have multi-year roadmaps but also have Lean-Startup that will pivot those roadmaps in an instant, it’s because SAFe’s Portfolio wants you to be an experimental Product company, with complete freedom of choice, but it also has to deal with the constrained scenario where the choice of work is limited. It never acknowledges that there is a spectrum of Portfolio Styles, and that some processes are more attuned with different parts of that spectrum.
With Funding secured; we can start to think about making investment decisions, but to inform those investment decisions…
We need to know our current state.
It’s expressed in the same format as the Future Vision so that we can compare it to the Future Vision. Spot the deltas, the changes that need to be made to reach that Future Vision. Those deltas become one of the sources for the work that we are considering doing in the future.
The work item at the Portfolio Level is an Epic.
This isn’t the “Big-Stories that we haven’t broken up” Epics of small-scale Agile; SAFe’s Epic is a step change in Business, something the business couldn’t do before, now it can.
- New Product or services to sell.
- Substantial changes to existing products or services.
- Savings and Efficiency gains.
- Reduction in losses or penalty payments.
Epics are expensive; they require Executive Attention. They’re long running, spanning out through time, and have a broad impact spanning across the organization. A detailed examination of Epics can be found here.
Eventually they will need a Business Case, Technical Impact Analysis, Costings, enough for a go-no-go decision.
All that detail is in the future; all that’s needed to begin with is enough information to be able to make some investment decisions. A description of the idea, a cost estimate and an understanding of the cost-of-delay if the Epic can’t be done now.
The ideas for Epics can come from anywhere, many will be created to cross the gap between the Current State and the Future Vision, but they can also be bubbling up internally from the Agile Release Trains within the Portfolio.
The Epics inform us of the changes we want to make but we’re also going to need to understand what it costs just to keep the Solution running. No changes, just keeping it powered up and alive.
These two sets of data points feed into the budgeting processes. SAFe recommends a process called Participatory Budgeting. Participatory Budgeting is an embodiment of the Set-Based approach. It uses the wisdom of the crowd to generate a set of potential investment profiles which the Lean Portfolio Management utilizes to create a final investment profile, the budgets, for the next time period.
Demand, the work, inevitably outstrips supply, the funding.
Difficult choices need to be made.
The power of Participatory Budgeting is that by getting the people that will have to enact those budgets once they’re decided, to help decide the budget and make the difficult choices themselves, then those people are already on the path to accepting the budgets when they are finalized. They understand the hard decisions that were made about what work does, or doesn’t, get done because they’ve been through those decisions themselves.
Some of the challenges with adopting Participatory Budgeting are discussed here.
The investment is made in Development Value Streams which are themselves realized through Agile Release Trains. We are investing in our capacity to do get stuff done which involves people, knowledge, infrastructure, tooling, licenses. they are all there within the Development Value Stream.
The flow of money, what actually happens to the investment, is discussed here.
For the long-term health of the Portfolio there needs to be some rules around how the investment profile is set up, and how that investment can be consumed as work starts to flow across the development value streams. These rules in SAFe are known as guardrails and the two important guardrails at this stage are Capacity Allocations and Horizons.
Capacity Allocations
- What percentage of the investment is reserved for external work requests from the Business?
- What percentage of the investment is reserved for internal work coming out of the teams and trains?
- What percentage of the investment is reserved for emergent work like defects and support?
Horizons
- Is some of the investment dedicated towards examining ideas for future products or solutions. The current cash-cows will eventually run dry, and we need to ensure that something is there to take over when they do.
- Is some of the investment dedicated towards productizing the ideas that look like they have potential? Can they be made into a viable business proposition?
- Most of the investment though will be into current solution set, ensuring that they continue producing value.
With Capacity in place, and an idea of how that capacity should be utilized, we need to get work done.
The work itself flows through the Portfolio Kanban. I talked about the “Dynamics of Decision Making Within the Portfolio Kanban” at the 2020 Summit.
For now, it’s enough to say that the Epics have a lifecycle. The ideas need to be elaborated into a business case. A decision needs to be made on whether to progress with the Epic and the decision may be based as much on available capacity in the Agile Release Trains as it is on the benefits the Epic might bring. You can’t do something if you don’t have the people available to do it!
The Budgeting and Approvals process are separate.
Deciding to do a piece of work in Participatory Budgeting doesn’t automatically mean that the work is going to get done; it means that investment is made in the relevant Development Value Streams so that they have capacity to do the work in the future.
If the strategy changes, then new work might get approved; instead of the piece we thought we would doing back when the budgets were set up. If the strategy has changed, and the new work is in a Development Value Stream that didn’t receive much investment, then its capacity is going to become a constraint. You’re not going to be able to get as much done as you would like; until you can increase the investment in the Development Value Stream.
Be aware that changing the Investment in a Development Value Stream is the slowest running loop of the lot; moving the investments around is hiring and firing. You all know how long it takes to get someone employed, even if you could get them in the door overnight; getting them up-to-speed on your systems could take weeks. Removing people from the organization can take just as long and all due HR process must be followed. Even if you are retaining the people; re-training them into the new area can take time as well.
Moving the money, the investments is not a quick fix.
Changing the work that is being done is the quickest; cancel or de-prioritise anything that is not relevant to the current strategy.
The work that the Portfolio has approved and prioritised provides intent to the Agile Release Trains. They should be looking towards the set of Epics that have been approved and working with the Epic Owners to create Features in the Agile Release Train’s Backlog.
The approved Epics are what the Portfolio would like Trains to work on, but trains are always empowered to do their own work. It is a necessity for self-improvement.
The Agile Release Trains creating their own Features is the “pull mechanic” at work; pulling the work towards them rather than it being imposed upon them. It balances demand against supply.
Features get planned through PI Planning.
Plans are executed in the iterations
The updates those Features make to the Solutions are delivered, deployed and released.
Releasing the Solution should mean that the Outcomes start to move.
KPI’s may be affected by the release, the business should be continually checking them to ensure they are within allowable limits and reacting accordingly if they stray beyond.
OKR’s can be inspected, outcomes might be achieved, or maybe the numbers tell us otherwise and cause us to pivot Lean-Startup style.
The metrics provide transparency as to what is actually happening.
Those metrics, from the solutions, from trains within the development value stream, are important. The commitments that the trains are making PI by PI give us information on how much they can get done. Combine that information with a roadmap of the work we think we’re going to be doing in the future and we can forecast. We can predict whether the targets, the outcomes that were set out, are achievable. That transparency gives us vital information to adjust the Future Vision, it closes the governance loop and the whole system goes around once more3.
Footnote
You think you are almost done and then someone says something that sets you on a tangent. I was talking to fellow Fellow Ian Spence after presenting this topic at the SAFe Summit 20214 and he mentioned that a business doesn’t care about Working Solutions, it cares about Results, Outcomes. The business doesn’t care how they get those results, they just want the results! I was just about to curse the world and start redrawing this picture once again, when I realised that if I think through the storyline Outcomes are there at the beginning, they provide focus for the Portfolio; the storyline is Results focused.
Next Steps
Next topic for investigation is Roadmaps.
Quick Access
- Purpose Of Lean Portfolio Management
- Purpose Of Lean Portfolio Manageement - Solution Focused
- Portfolio Styles
- Portfolio Weighted Shortest Job First
- Epics
- Managing Investments
- Portfolio Roadmapping
- Portfolio Operations
- Scaling Portfolios
#1 OKRs are “en-vogue” at the moment because Google does OKRs and Google is successful, therefore if we do OKRs we will be successful! It should be pointed out that OKRs do not cause success; but they are useful in generating alignment around what people think success looks like.
#2 Commonly attributed to Spiderman, but occurs in various forms through history
#3 Targets, Forecasts, Commitments is drawn from Implementing Beyond Budgeting - Bjarte Bogsnes
#4 For SAFe Community members the video is accessible as: The Purpose Of Lean Portfolio Management