“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 Flow Of Money
The previous posts around Managing Investments have looked at the entities that can be funded, Projects or the favoured Value Stream, and has looked at the process, Participatory Budgeting, through which investment decisions are made. Over the last few weeks I’ve been trying to explain to a customer how the money flows in a SAFe Portfolio and what the money does; in particular they were confusing spending on internal staff and mistakenly equating it with the capacity reservation for support and operations.
Investment Decisions are separate from Spending Decisions are separate from the capacity Consumption Decisions; but each decision informs the next by becoming it’s input.
The inputs to Participatory Budgeting are Baseline Solution Initiative costs and Proposed Solution Initiatives, candidate future Epics. The Participatory Budgeting process determines which of these will potentially be pursued in the future and then allocates funds to the Solution and it’s associated Development Value Stream.
It’s another bit of mismatch between SAFe “Fund Value Streams” and Participatory Budgeting which continually refers to funding the solutions. The discrepancy arises because businesses care about solutions, they don’t care how that solution is realised they just want the solution. It could be purchased from an external supplier or it could be delivered by an internal Development Value Stream. From a budgeting perspective it is right for us to be considering investing in solutions, that might then purchase the solution from a supplier or it might go into funding a Development Value Stream. If the solutions are small then there is a chance that multiple solutions are owned by a single Development Value Stream, and it’s investment comes from the business wanting to fund those multiple solutions.
If the funding is destined for a Development Value Stream, rather than purchasing a solution from an external supplier, then the funding is used to employ People, either internal or external and to pay for the relevant licenses, infrastructure, tooling and resources that they need to do their jobs. This is the investment being made in the Development Value Stream and the flow of money is through into the monthly wage bill and the monthly payments for services and utilities.
People and tools, once employed, create Capacity, the ability to do things. Tools, the Continuous Delivery Pipeline, acts as a multiplier and improving the pipeline increases the available capacity for the same amount of money invested in the people.
The Development Value Stream needs to be clear about how it’s allocating that capacity, Guardrail #2. At it’s simplest how much is assigned to Business requests (Blue), how much to internally generated requests (Red) and how much reserved for Support, Issues and other emergent issues (Purple).
Next Steps
The above digression into examining why businesses care about solutions is worth exploring in more detail and I did mention back at the very beginning that I should redraw my original diagram to be Solution Focused to represent that.
More Great Topics for Agile Teams
How many Features do you take to PO Planning? PI Planning Tips
On the Nature of Portfolios; WSJF Estimating Portfolio & WSJF
Program Level WSJF & Feature Slicing Program WSJF & Feature Slicing
All about Managing Dispersed Planning; WSJF Estimating Dispersed Planning Series
States of Epics The EPIC lifecycle