“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.
Portfolio Topologies
Portfolio Topologies started out as a conversation with colleague and SAFe Fellow Ian Spence about 15months ago as a result of observations of patterns that he was seeing emerge in a large multi-national organisation that he was working in. Writing up my thoughts on Multiple Portfolios, Nested Portfolios and Combined Portfolios reignited the thought about Portfolio Topologies which was further reinforced when chatting to Andy Sales, Chief Methodologist at Scaled Agile, who mentioned that they were looking at Portfolio Topologies as well. Everything seemed to be conspiring to make Portfolio Topologies the next topic.
Scaled Agile will publish their “official” opinions in due course and it will be presented in their standard factual style of “these are the patterns that we have observed,” which is what most people want, the results of the analysis. However, I feel that that doesn’t quite do the topic justice. Missing out on the journey, the logic, that results in those patterns means that many people won’t fully understand them and most likely mis-apply them. The advantage that this blog format presents is that it provides a stage on which to explore the logic and act-out the progress of the journey to reach the results.
Mapping The Portfolio Topologies Landscape
Trying to establish what Portfolio Topologies might exist requires taking real world examples, abstracting away all the local decisions and implementation details and then spotting patterns in the raw abstract forms.
The patterns that emerge will be very abstract, perhaps too abstract form most people. What those people probably want is not the abstract pattern, but the logic about how that pattern can be applied in an organisation, worked scenarios.
Interfaces
Just like the Teams described in Team Topologies1, Portfolios have a cognitive limit, a topic discussed in Multiple Portfolios. That cognitive load needs to be managed by ensuring that Portfolios have clear responsibilities and boundaries, this becomes the interface to a Portfolio.
Figure 1: Portfolio Interfaces
At the level of abstraction we’re working at, Portfolios only deal with 3 principle artefacts: Vision, Change and People as discussed in Portfolio Events, Exploring The Decisions Being Made, all the detail should be decentralised. In the above diagram the Vision is the Vision, People are represented by the Value Streams and Development Value Streams can make Changes that the Portfolio wishes to enact in order to reach its Vision.
The vision is intrinsic, every Portfolio has to have a vision to give it purpose, otherwise it’s just a group of people. The choice is in the combination of Operational and Development Value Streams within a Portfolio, that choice informs the degree of inputs and outputs that the Portfolio provides.
Inputs
Knowledge informs the Vision, what the Portfolio should be trying to achieve. The vision in turn informs the set of Operational Value Streams and/or Development Value Streams that the Portfolio should contain and the changes that the Development Value Streams should pursue in order to support the Operational Value Stream operating more effectively.
Where does the Knowledge come from? It could come from within the Portfolio, knowledge generated by running the Portfolio feeding back into itself. Knowledge could come from other Portfolios within the larger organisation. Finally the Portfolio could invest in gaining knowledge from external sources such as survey companies or bodies conducting industry trade studies.
The Money invested funds the Portfolio to achieve the Vision. The money can be spent on running an Operational Value Streams to generate more money or it could be invested in Development Value Streams to support Operational Value Streams either in this Portfolio or in other Portfolios. The money could also be invested externally in order to generate either knowledge to inform this Portfolio’s vision, solutions for this Portfolio to utilize or just more money.
The money being invested might come with constraints on how that investment is utilised by the Portfolio but the Portfolio is empowered to determine how it will meet those constraints. The money being invested in the Portfolio might come from the Portfolio itself forming a closed loop system.
The solutions allow the Value Streams to run. The solutions could come from this Portfolio if it contains Development Value Streams, self developed solution. The solutions could come from other Portfolios elsewhere with the organisation or could be purchased in from external sources.
Outputs
Running the Portfolio generates Knowledge; Knowledge that the Portfolio can feed back into itself as Self Improvement, or can inform other Portfolios within the Organisation. Knowledge can also be an asset that the Portfolio sells to generate money to invest.
Running an Operational Value Stream should generate some form of value, typically money that can then be invested. The Portfolio can also choose to take some of the money invested in it and use it as an output for investing without it being used to fund an Operational or Development Value Stream internally.
The Portfolio can choose to invest back into itself to become a self-sustaining closed loop system, it can choose to invest in other Portfolios particularly if it needs Solutions from those Portfolios. It can also invest externally to obtain the solutions necessary for it’s continued running.
Development Value Streams generate solutions. The Portfolio can use any solutions that it has developed itself to help run any Operational Value Streams it has, Self Developed Solutions. The Portfolio can provide solutions for other Portfolios to use, possibly in return for investment from them into this Portfolio. Operational Value Streams, either in this Portfolio or in other Portfolios, take the Solutions and use them to generate value, typically money, for investment elsewhere.
Single Portfolios
Before jumping straight to Multiple Portfolios and the myriad patterns that can spring from that, let’s consider Single Portfolios first as that allows us to categorise the single portfolios which are the building blocks of the multiple portfolio scenarios.
Given the Portfolio description above there are two dimensions to the structure of a Portfolio whether it contains Development Value Streams and whether it contains Operational Value Streams.
Figure 2: Single Portfolio Styles
Investment
The Portfolio contains neither Development Value Streams nor Operational Value Streams, it simply uses the money invested in it to invest in other things outside of the Portfolio. Think Hedge Funds, Venture Capitalists, pure monetary dispersal.
Arguably this scenario doesn’t exist because there will be a sequence of steps in order to distribute the investment which could be classed as an Operational Value Stream, thereby making this an instance of the Operational Portfolio described later. However, it’s useful to distinguish between the pure money dispersal of an Investment Portfolio from an Operational Portfolio that is doing some form of activity in order to generate money to invest.
Development
This is the standard SAFe Portfolio, as defined in SAFe 6.0, comprised entirely of Development Value Streams. The value that a Development Portfolio provides is the Solutions that Operational Value Streams utilise to keep running.
A Development Portfolio needs Money invested into it in order to run it’s Development Value Streams. The Development Value Streams can use the money internally or they can spend it externally on 3rd party solutions and suppliers, or even invest it in other Portfolios that can contribute to achieving the Portfolio’s Vision.
Operational
Comprised entirely of Operational Value Streams.
It doesn’t own any Delivery capabilities therefore it can’t provide Solutions, but as it has Operational Value Streams it raises Money that it can then Invest.
It will need to invest some of the generated money into itself to keep the Operational Value Streams running, the remainder can be invested elsewhere. Therefore, it can be self-sustaining, because it raises it’s own money, but it will always need to invest elsewhere to get the solutions it needs to keep running.
Combined
Composed of both Operational Value Streams and Development Value Streams, the Operational Value Streams provide Money to Invest, the Development Value Streams provides Solutions. Because it consists of both revenue generating operation capabilities and solution providing delivery capabilities a Combined Portfolio can close the loop and be responsible for it’s own destiny without having to invest elsewhere; although it may choose to invest elsewhere if it wants to.
Multiple Portfolios
Having looked at the types of Single Portfolios the next step is to consider Multiple Portfolios and at it’s most abstract it becomes a choice of Independent or Nested.
Figure 3: Multiple Portfolio Options
What determines this is the Portfolio’s Vision. Independent Portfolios have complete freedom for their own Vision, whereas with nested portfolios the Visions of the child portfolios inherit from the Vision of the parent, and they would be expected to contribute to the success of the parent.
Independent Portfolios can still have common Strategic Themes running through their Visions, but those themes have been a negotiation to align on the Strategic Themes rather than being an imposition from a parent portfolios.
Regardless of pattern, the pieces of a multiple portfolio can choose from any of the single portfolio structures previously described, i.e. investment, development, operational or combined.
Scenarios
Independent and Nested describe the structure of the Portfolios but that pure abstraction doesn’t explain the choices that lead to multiple portfolios, for that we need to explore some scenarios to make the abstractions more concrete.
Innovation Portfolio
A separate Portfolio is created for exploring the Horizon 32 ideas about potential future Products and Solutions that may provide a return on investment in a few years time. The long time to achieving a return on the investment often derives from the fact that new Operational Value Streams will need to be set up that don’t currently exist, new markets or new routes to market.
The defining characteristic for this scenario is that the two Portfolios need different visions.
The advantage of separating out the Innovation Analysis is that the Innovation Portfolio can optimise itself differently from the Portfolio(s) dealing with existing Products and Solutions. With Existing Products and Solutions the emphasis is often on efficiency, getting things done for less expense, making the available money go further. Value is in the Solution produced, knowledge gained is still important but secondary. For Innovation Analysis the emphasis needs to be on Scientific Method, getting to an answer. The value is in the knowledge, the thing produced is secondary and may well have been a disposable prototype just to acquire the knowledge.
In the real world I’ve seen major automotive manufacturers spin off their autonomous driving activities into a wholly owned subsidiary to free it from the pressure the parent organisation puts on all of its staff to ensure that all work done makes the manufacturing lines more profitable. The autonomous driving research isn’t going to filter onto the production lines for a few years and needs the space and freedom to innovate and experiment and there will be some experiments that don’t produce the expected answer and the parent organisations mentality and processes aren’t capable of dealing with such high uncertainty. To truly free the autonomous driving staff from the pressure they are even housed in their own building well away from the main corporate site. The innovation portfolio will operate as a Development Portfolio producing either Solutions and/or Knowledge. Its nature means that it won’t have any Operational Value Streams and it will need explicit investment to keep it running.
I’m not happy with the name Innovation Portfolio because that could be mis-interpreted as “the Innovation Portfolio is the one and only place where innovation happens” and that is definitely not the intent, Innovation can, and should, be happening everywhere. However, I don’t have any better suggestions for a name at the moment.
Regulatory Separation Of Concerns
There are instances where there is a legal requirement to have two groups of people completely separate; e.g. large accountancy firms must keep the people in their audit business separate from the people in their consultancy business, to the extent that they will often provide separate buildings and people from one side the of the business will need to be escorted should they need to enter a building belonging to the other side of the business.
The defining characteristic here is that the People must be kept separate from the People in another Portfolio. At the Portfolio level People are represented by the Value Streams. Separation of concerns could happen at any level of the framework, individuals may need to be kept separate, teams may need separation, trains may need separation. Always try to achieve this at the lowest level possible if it is needed at all. Typically it is an external constraint that is demanding the separation of concerns.
Central Platform, Local Implementation
This scenario has already been described in the Combined Portfolios blog; the defining characteristic here is Solution reuse. A Central Platform Portfolio, perhaps several, has the responsibility of providing common platforms and tools that other parts of the bigger organisation can take and customise to their own needs. It follows the Development Portfolio pattern since it’s comprised of Development Value Streams that provide Solutions. It doesn’t generate money for investment directly but gets it’s investment through others investing in it.
Local Implementation Portfolios take the solutions provided by the Central Platform Portfolio and sell them to generate money for investment. Some of the money generated needs to be invested in the Central Platform Portfolio to allow it to continue providing the Solutions the Local Implementation Portfolios are using. The Local Implementation portfolios would follow either the Operational or Combined patterns. An Operational Portfolio just has the Operational Value Streams to generate money and would provide the Central Platform Solutions in as-supplied condition, whereas a Combined pattern has it’s own local Development Value Streams that can customise the common solutions to their customers needs.
Thought needs to be given towards whether a customer request is honoured within the Local context as a customisation or within the Platform context for the benefit of all. The Solutions provided by the Centralised Platform Portfolio need to be architected as platforms, the external APIs need to remain consistent across time so that local implementations built using those APIs don’t need updating for every new release of the solution as that would become an overwhelming burden for the local teams.
Cross-train investments are harder to manage. There is always the possibility for the investments to come with oppressive constraints that limit the Central Platform Portfolio’s ability to choose its own destiny. Is the relationship and transfer of money an investment free of constrains, or a purchase for a specific thing? If it’s a purchase then the purchase price needs to incorporate all of the costs involved in running and supporting the product not just the cost to make the requested change.
This pattern doesn’t need to be applied at the Portfolio level, it could be applied to Agile Release Trains within an Portfolio, or even Teams with an Agile Release Train.
Conclusions
The differences always manifest themselves in the Portfolios having different Visions.
Which makes sense; one of the insights that the Vision needs to convey is “Why this Portfolio is unique and different from the other Portfolios?” If there is no difference then it should be part of those Portfolios.
There are patterns, topologies describing the structure, albeit very abstract. That abstraction can be brought to life when consider the scenarios and decisions being made to chose how an organisation can instantiate one of the abstract structures.
- Single Portfolio the Value Streams can be combined in a number of different ways that define the interfaces they present to the outside world.
- Single Portfolios can be arranged into Multiple Portfolios interacting through those interfaces, but it’s the decisions that instantiate the individual Portfolios that are more relatable that the abstract structure itself.
What the analysis does reinforce is that this is all about investment decisions, if the Portfolio doesn’t have the right to choose how to invest the money that it has, then it’s likely that the Portfolio has been instantiated too low in the organisation.
Next Steps
The cross-Portfolio investment is interesting and leads to the topic of Funding constraints which I’ve been discussing with Niko who was working on a guidance article on the topic. The guidance article is likely to present solutions, whereas I’m more interested in cutting everything back to find the underlying fundamental rules and then build them up to reach the desired solutions.
Otherwise there is still Project->Epic transition or perhaps Epic Ownership to explore.
#1 Team Topologies, Matthew Skelton and Manuel Pais, ISBN-13 : 978-1942788812
#2 Guardrail 1 : Guiding Investments by Horizon from Lean Budget Guardrails, the Horizons are also discussed in more detail in Portfolio WSJF, Within the Investment Horizons