“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.
Participatory Budgeting
Previous posts have looked at the entities that can be funded, this could Projects that assign the money to the work or it could be Value Streams that assign the money to a team of people. SAFe favours the later, Value Streams, because it’s more appropriate for long-term systems and solutions than the transient nature of Projects.
This blog series started some months ago by describing the Portfolio as an Investment Vehicle; regardless of what type of entity is being funded, decisions need to be made about what an organisation wants to invest in. The process through which a SAFe Portfolio makes investment decisions is Participatory Budgeting.
I have to admit that when Participatory Budgeting first appeared in the framework some years ago I was sceptical; they’ve found a process with the word “Participatory” in it and thrown it into the framework. Quite literally “thrown”, the process whilst adequately described didn’t fit neatly into the framework; there was, and still is, a mismatch in the language that’s used in Participatory Budgeting compared with the rest of the framework. Furthermore the reasoning behind Participatory Budgeting was never properly explained; SAFe does a very good job of explaining “What you should do” but doesn’t always manage to convey “Why you should do”.
Having researched Participatory Budgeting, and having had the opportunity to question Luke Hohman on it, I am now convinced of its usefulness. This blog post intends to explain some of the back-story behind Participatory Budgeting; to explain the “Why you should do” and to look at some of the challenges.
History
Participatory Budgeting evolved out of two scenarios, Local Government and Disaster Recovery:
| Local Government – Demands on local government inevitably exceed the amount of money available. Rather than the elected officials decide what demands are allowed to consume the available money and then face the wrath of a populous that doesn’t agree with the decisions that were made because their particular demand didn’t get funded, Participatory Budgeting is used to build alignment within the community by getting representatives of the community to make the hard decisions because themselves. Because the community representatives have been through the decision making process themselves they understand the trade-offs and are more likely to accept the final budgets. |
| Disaster Recovery – Aid agencies want to provide relief to those affected by a disaster. Participatory Budgeting is used to help coordinate the aid agencies and minimise overlap and wasted resources allowing them to do as much as they possibly can with their precious resources. Everyone brings their money and they collaborate with each other to fund the relief needs. Money isn’t wasted because once a relief need has been funded then discussions can move to the next relief need. |
SAFe’s implementation is a blend of both, organisations want to make sure that as much value as possible is going to be generated with the investment that they’re making in the Value Streams and they want the people that will have to enact the budgets and be constrained by them to understand and be invested in the decisions that were made; the participatory nature builds that understanding.
Disconnected Terminology
In the introduction to this Blog I stated that SAFe’s implementation of Participatory Budgeting doesn’t fit neatly into the framework. This isn’t to say that the process is a bad process, it’s not it’s a good process, it’s just that there is a disconnect between the words used in the Participatory Budgeting descriptions and the words used in rest of the framework. The instructions have been cut-and-pasted from elsewhere but they haven’t been properly updated to fit with SAFe’s lexicon of terms and SAFe’s approach to a development landscape.
The most obvious of the disconnect can be found in the items that are discussed in the Participatory Budgeting Forum: Baseline Solution Investments and Proposed Solution Initiatives. New terms that don’t obviously connect to the standard pieces of a SAFe implementation.
Baseline Solution Investments (BSI)
The investment needed to keep a Development Value Stream running. Many organisations, notably financial institutions, have historically used the term “Run Costs”. Organisations do need to be explicit and transparent about what comprises their Run costs. At the bare minimum this needs to encompass the costs to keep the System/Solution alive, which might encompass costs for servers, licenses, networking costs, as well as some IT Operational staff to keep all of the aforementioned equipment running. Above that, do the costs cover:
- Upgrades: keeping the OS, Libraries, etc… up-to-date?
- Maintenance: fixing defects found in the system that aren’t part of current Epics or Features?
- Enhancements: small improvement requests that the Value Stream can do locally without the request being part of an Epic.
It’s important to be transparent about how much is available for the different categories of work. Decisions might be made to partially fund the Baseline Solution Investment, not all of the requested money for Upgrades, Maintenance or Enhancements might be given, this will require the Value Stream to accordingly scale back its expectations on what it can achieve in those areas.
Additionally, the different categories might attract different classifications in-terms of accounting. Enhancements is new work and potentially Capital Expenditure, whereas Run, Upgrades and Maintenance are likely to be classed as Operational Expenditure. Many organisations try to capitalise as much work as possible since it attracts a different, more beneficial, treatment in the accounts than Operational work1.
It is also worth pointing out that Baseline costs are not the costs of your internal workforce; they are just the investment needed to keep the System/Solution running. If the decision is made to invest just the minimum when previously more funds were available then the Value Stream is going to need to let people go2. This topic will be revisited later when Separating Funding Decisions from Spending Decisions is discussed.
|
Portfolio Anti-Pattern: Everything has to be an Epic.
Putting some investment for “Enhancements” is very powerful as it gives a Value Stream the ability to make local decisions on smaller pieces of work, i.e. Stories or Features. If they aren’t granted this ability then to get the small things done then everything becomes a Portfolio Epic; which ultimately results in too many Epics at the Portfolio level. More Epics require more effort to build Business Cases, budgeting discussions take longer because there’s more of them, longer Portfolio Syncs, etc… . If it costs more to build and approve the business case than it would to just get on with the work then your organisations economic decision making is broken. SAFe’s Guardrail #3, Approving Significant Initiatives already talks about sending items that are too small straight to a Value Stream but that is reliant on there being some spare investment in the Value Stream to do that work. |
Proposed Solution Initiatives (PSI)
These are the candidate Epics. The challenge lies in Candidate Epics. There needs to be enough information to make an informed decisions but these don’t need full business cases; the Epic Hypothesis Statement and an Initial Estimate should suffice. No point building a business case for something that nobody is interested in investing in.
What are we funding?
The SAFe material talks about funding the work items; which is how it works in local government. You fund the proposed work item, eg. Fix the roads, and the work item gets the money to spend. The wording implies that Epics get the money; which violates the SAFe budgeting principle of “Fund Value Streams not Work (Projects)” there is a layer of indirection that is lost in the budgeting forums. SAFe’s instructions do deal with the indirection in the analysis step that occurs after the forums have taken place. If there is agreement that a PSI should be done then the money to do that PSI is invested in the Development Value Streams that need to contribute to the PSI.
The challenge is that because all of the discussions in the Participatory Budgeting Forums are talking about work items it can feel like the work items is being funded and approved; neither of which are true. This is problematic when moving an organisation from Project funding to Product funding because all the funding discussions are around work items that in their minds can equate to Projects because they’re being funded. It takes a huge amount of facilitation skill to remind the participants that; they are looking at the work that might potentially be done in the future in order to set up investments in Value Streams so that their capacities are aligned with the sort of work the organisation thought it wanted to do at the point in time where the Participatory Budgeting exercise was conducted.
I’m always very careful in my discussions and explanations. If the organisation decides that an Epic is something they are interested in doing in the next budgeting period then they need to make an appropriate investment in the Development Value Streams so that they have available capacity to work on that Epic later in the year.
Separate the Investment Cycle from the Approval Cycle
At one point there was an erroneous slide in the SAFe Training Material3 that implied that after an Epic has been Approved it moves into the Portfolio Backlog where it waits to go into Participatory Budgeting.
A cursory bit of Systems Thinking (SAFe Principle #2) would quickly highlight this as a bottleneck since Approval takes place at least once per PI whereas the suggested interval for Participatory Budgeting is every 6 months. It makes no sense!
The Budgeting process that sets up the investments in the Value Streams can, and should, be as loosely coupled to the Epics as possible. Investment decisions are being made infrequently and will need to be made using Epics that have the barest minimum of information attached to them. Ideas about what the organisation would like to do in the future.
From the perspective of the Portfolio Kanban; Epics that have completed Review, and therefore have an Epic Hypothesis Statement and initial estimates, should have enough information to be considered in a Participatory Budgeting forum. It is not necessary to have a full Lean Business Case to conduct the Participatory Budgeting forums. There is no point creating the Lean Business Case of an Epic for the purposes of Participatory Budgeting, because that effort quickly becomes waste if the Value Streams don’t receive enough investment to be able to consider implementing the Epic within the current budgeting period.
This poses challenges with SAFe’s suggested Portfolio Kanban because the Review column either needs a significantly higher WIP limit or needs splitting into Doing / Done so that the Doing can have a sensible (small) WIP limit and the Done column allows visibility of the batch building up ready for Participatory Budgeting.
Figure 1: Separate Funding from Approval
Just because investment was made in a Development Value Stream on the basis of an proposed Epic it doesn’t mean that that Epic will be approved. There is always a possibility that when it comes to approve the Epic that the world has moved on, strategy has changed and the Epic is no longer relevant, or something else is more important. If it isn’t approved the investment remains with the Development Value Stream and can be utilised for other more important or relevant work.
The separation between budgeting and approvals allows the Development Values Streams to remain agile by giving it the ability to react even though the investment has been fixed and committed for the budgeting period.
The budget, once fixed, becomes a constraint to the work that the organisation wants to do, this was discussed in the previous blog post. An organisation always has the ability to break its own rules and move the investment around at will, but it needs to remember that whilst the money can be moved instantaneously, changing how the money is spent is a lot slower.
Epic that have been approved and are In-Progress provide Intent to the Development Value Streams, these are the “big ticket” items that the Portfolio want’s the Development Value Streams to work on.
Separate Investment Decisions from Spending Decisions
Deciding on “what you want to do” so that the investments are made in the relevant Value Streams can be separated out from how that investment is spent.
Figure 2: Separate Investment from Expenditure
It is the Business that should be deciding on the Investment that is going to be made; they know what they want to do, which informs which Value Streams need to be invested in.
It is the Value Streams that should decide how the Investment is spent; how much goes to Staff, how much to the licenses, infrastructure, etc… that support those staff.
There can be a split between Internal and External staff. Organisations typically have more freedom to increase and decrease the capacity of External staff, whereas changing the Internal Staff is bound by HR policies and local employment laws. If the amount invested in a value stream drops below the amount needed for the Internal Staff then due process will need to be followed to reduce the number of Internal Staff4; this scenario will occur if the systems/solutions being developed by a Development Value Stream are being decommissioned and are not being replaced5; it’s investment will eventually be reduced to nothing.
What if people are bringing real money to the table?
The local government scenario works because the taxes raise a central pot of funding that can then be dispersed, to give every participant equal voice they are all given an equal portion of the total available funds. This breaks down when the participants bring money themselves; they expect to have the same amount of money to spend as they are contributing into the process; this is the Disaster Recovery scenario.
Participatory Budgeting can still be used, each forum must contain a representative of each entity that has contributed funds and that person is given an amount equal to the amount their entity contributed. The game plays as normal beyond this point, but the entities that contributed more have a greater ability to fund the work that they want.
The concern is that individuals will be selfish and misbehave; that they’ll fund just the changes that they want but won’t contribute to the underlying Baseline Solution Initiative. Some guidelines around “A requested change PSI will only be accepted if the underlying BSI has been sufficiently funded” can be used to guide the participants towards a sensible budget setup.
Production Portfolios – What’s the point of Participatory Budgeting?
Portfolio Styles was discussed in one of the earliest blog posts; one of the styles mentioned was a Production Portfolio which has work imposed upon it rather than having choice over which work they want to do. What’s the point in running a Participatory Budgeting session if you’ve got to do all the work?
It is still necessary to check that the work fits within the available budget. If it doesn’t then something has to be done; management shouting “Make it fit!” is wishful thinking and a denial of reality that will only hurt more later. Ideally the Participatory Budgeting session should involve the people imposing, or who have accepted the imposition on behalf of the organisation, the work upon the Portfolio so that they understand the constraints.
The rules of the Iron triangle of money, scope and time apply. If money is fixed then the negotiation points are scope and time. Can the scope of the work be reduced? Does the work need to be done in this budgeting period?
Next Steps
This has been the first pass through Participatory Budgeting; there’s more in there. I feel that a discussion on how to practically facilitate the session and how to deal with individual personalities and agendas within the discussions is worth exploring. Another discussion that’s worth having is around the challenges of adopting Participatory Budgeting as part of the transition to Agile ways of working; rethinking the budgeting processes is a seismic shift for many organisations that dismantles years of ingrained process and associated behaviours.
Those proposed topics are for the future; next is a quick little look at The Flow Of Money.
#1 Always check with your accounts department for your local financial rules.
#2 If this is a zero-sum game, a loss in investment in one Value Stream is made up by a gain in investment in another Value Stream, then it might be possible to transfer staff. If the overall budget is decreasing then that implies that savings need to be made which might translate to a reduction in headcount. If the overall budget is increasing then start recruiting.
#3 SAFe 5.1, LPM Module 5 Slide 12 – hopefully fixed in later version.
#4 Retraining and reassigning to a Value Stream that has gained investment is generally preferable to firing and hiring; it is more socially responsible.
#5 If Systems are being replaced then the Value Stream should ideally own both the old and replacement systems and manage the transition between them; including transferring staff from the old system to develop and support the replacement system. Keeping both old and replacement within the same Value Stream means the Development Value stream can self-organise.