“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.
The topic of “Can we have multiple Portfolios?” comes up fairly regularly in training courses and even warranted a discussion at a recent SAFe Fellows Retreat to try to put together some official guidance from Scaled Agile. Whilst that guidance is making its way through due process before publication I want to explore some of the underlying reasoning.
Why do you want multiple portfolios?
The subtext behind the question is “Have you got the right reason behind wanting multiple portfolios?” The challenge here lies with history and the colloquial use of the phrase Portfolio where people tend to mean “a collection of things” and indeed it is that usage that other management frameworks use as their definition of Portfolio, notably the PMI definition is:
|“A portfolio is a collection of projects and programs that are managed as a group to achieve strategic objectives. … According to PMI and its PMBOK Guide, a portfolio includes, “Projects, programs, other portfolios, and operations managed as a group to achieve strategic objectives.”|
Many organisations take their existing definition of Portfolio and start trying to apply that to SAFe and typically it doesn’t work.
|I was helping a major UK household insurance company adopt SAFe and when we first started discussing the Portfolio they stated that they had 7. There was a chin stroking moment and an arching of the eyebrows: “Really, seven portfolios? You’ve only got 300 developers!” It turns out that they had 7 sources of work: selling insurance policies, claims on insurance policies, digital transformation, trading insurance, data storage, analytics and reporting. However, in terms of investments, there’s just one portfolio; balancing the investment across what became 7 value streams. When this was put to the management board: “There is one portfolio and you are the decision makers within it.”, their response was “Yes; we make the decisions!” It should be noted that alignment on what constitutes the Portfolio was just the beginning of a long journey; many processes and behaviours needed to change to truly achieve a Lean Portfolio.|
Over the last few years of studying and implementing Lean Portfolios I’ve come to develop a few, completely unofficial, Rules Of Portfolioto act as guides.
Figure 1: Four, Completely Unofficial, Rules Of Portfolio
Often Portfolios are instigated too low in the organisation; SAFe Portfolios are investment vehicles, they need to have the ability to balance those investments to try and maximise their return on that investment. Instigate the portfolio too low violates my first two Rules of Portfolio. A Portfolio that is too low can’t self-organise because it hasn’t got the ability to move money around in any meaningful way; changes require reallocation of funds not within the Portfolio but to the Portfolio. Changes in funding are inevitably slow and painful. Ideally, Portfolios are run as miniature businesses; they are profit and loss reporting entities in their own right, freedom of choice to manage the investments across a set of business lines in order to maximise the profits from that set of business lines. A portfolio that is just a single line of business loses the ability to move investments.
Cognitive limit on the size of the portfolio
At a recent SAFe Fellows retreat Eric Willeke posed the question:
|“Is there a Dunbar’s numbers equivalent for Portfolios?”|
There were various suggestions around the number of people, the amount of money, or the number of products, but I would suggest that the limit is the number of decisions that the portfolio can make.1
- Consider an Aircraft manufacturer: they have only a few products, the aircraft lines, but thousands of people, and therefore lots of money, involved in supporting those few products. I wouldn’t split the portfolio because the ability to move investment between the products would be lost. The detail of spending decisions should be decentralised out into Solution Trains, the volume of money is big but the number of decisions around the products quite low.
- Consider a component manufacturer, by combining and configuring a handful of components they can create hundreds of products. The product space might be huge but the Portfolio’s decisions concern just the handful of components. I wouldn’t split the portfolio because then the components could become split across Portfolios and coordinating the changes to the components becomes much harder when the Portfolios are pursuing independent agendas.
The decisions that a Portfolio must make have been explored in Portfolio Events – Exploring the decisions being made. The Portfolio needs to make decisions about the Vision to set a measurable target for the Portfolio to achieve, to determine the Changes (Epics) that will move the organisation towards the Vision and to invest in the people (Value Streams) that will do the work of moving the organisation towards the Vision. If the Portfolio focuses on just those three aspects and decentralises the rest of the decisions into the Epics and Value Streams then the volume of decisions that it needs to make should be manageable, it shouldn’t hit it’s cognitive limits.
Volume of decisions is one cognitive challenge, the other challenge is the disparity of those decisions. If the decisions are all in one space, one area, then it’s a lot easier to make more of them because no context switching is involved. If the decisions are in different areas that require context switching to move between them then this context switching has an overhead which reduces the number of decisions that can me made, the cognitive limits will be reached much quicker. If a Portfolio is responsible for lots of disparate, unconnected products the question needs to be posed: Should they be together in the same Portfolio? The more that the Portfolio tries to get involved in what should be decentralised decisions, the more likely it is to encounter context switching from one detail to another and thus the less it can handle; which is another argument for the Portfolio to stay up out of the details and focus on just Vision, Changes (through Epic approval) and Investment (in Development Value Streams).
The cognitive limits of a Portfolio are going to be context specific, empirically determined through trying to run the Portfolio, it’s a qualitative rather than quantative metric.
Managing Across Portfolios
The starting point should be that Portfolios are completely independent of each other; there shouldn’t be a need to manage across Portfolios, they do everything they need to do themselves.
From a practical perspective, Managing across Portfolios is no different to managing collaborations anywhere else, negotiate changes into the other Portfolio/ART/Team backlog. The challenge is that other Portfolios, being other businesses, may have other priorities and other targets. The changes that you’d want them to make might not be high on their list of priorities. Think about whether you can do it yourself; remember, Portfolios should be running like independent businesses!
There may be good reasons why some things are shared, so cross-Portfolio collaboration may be an inevitability. Portfolio’s make investment decisions, a Portfolio could choose to invest in another Portfolio in order to secure the right to utilise capacity from the Portfolio being invested in and negotiate what that capacity is used for. The anti-pattern that can emerge is cross-charging between Portfolios for tiny little pieces of work; if the work between Portfolios is numerous and small then it’s another indication that the Portfolios have been badly instantiated.
Epics Across Portfolios
Sure, why not.
Epics span across Agile Release Trains, there is nothing that restricts those Agile Release Trains to being within the same Portfolio. Indeed, the SAFe setup of funding the Agile Release Trains and just flowing the work across the Agile Release Trains is ideally suited to this; there is no need to transfer money between Portfolios, just argue the value of the work and if it is valuable then it should get prioritised.
Epics could appear on the Portfolio Kanban Boards of two, or more, Portfolios. As work is done to progress the Epic then the representations of the Epics, the Post-Its™, on the Kanban Boards are moved forwards to reflect the progress and state of the work. The digital tools probably won’t like one thing being in two places at once but that’s a problem with the digital tools rather than the process.
The challenge is going to be if one Portfolio approves the Epic but another doesn’t, then what happens?
- Abandon the Epic if partial completion is not going to provide the results.
- Could the change be done by a single portfolio?
- Could the scope of the change be altered so that both portfolios are able to approve the Epic?
- Would deferring it help? Will capacity become available later?
- Could the funding of the Portfolio be increase to create capacity to do the Epic?
Ultimately, the wider organisation is going to need to understand the reason why one of the Portfolios did not approve the Epic.
Having explored the topic of Multiple Portfolios existing in a “flat” landscape, the next article will look at Nested Portfolios and what happens if one Portfolio tries to contain another.