“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.
Managing Investment
The previous post looked at the topic of Projects; they are not as evil as most of the agile practitioners make out, they are a funding mechanism that is occasionally useful. The big mistake is to confuse the funding mechanism with the delivery mechanism. Projects can be as Agile or as Sequenced as the managers want them to be. The big observation is that funding Projects, the work, the transient thing that ends, makes no sense when dealing with long running systems and solutions; instead SAFe proposes funding Development Value Streams which is the topic of this post.
Value Streams
Value Streams make good entities for investment decisions; it’s easy to ask a group of executives “How much of your budget do you want to invest in keeping this value flowing?”, “How much extra do you want to invest in order to be able to improve that flow of value?” Run and capacity for Change respectively.
SAFe’s Portfolio Management deliberately confines itself to Development Value Streams, Value Streams that are concerned with the development of Solutions as opposed to the Operational Value streams that are concerned with the running of a process.
| Development Value Streams |
|---|
|
Funding Value Streams also gives much greater control on expenditure; Value Streams are given a budget and that is how much they can spend. This is all very transparent because most of the expenditure on a Value Stream tends to be fixed, recurring costs, such as Wages, Licenses, Infrastructure Rental, etc… all of the result in a monthly bill and that bill tends to be fairly predictable1. The Value Stream must adjust its expenditure to fit within the budget it have been given; spend a penny over and it’s time to walk the management down to HR and read them the rules!
The conversation is switches from “Where is the money being spent?” to “What is the most valuable work that should consume the investment made?”; the conversation is much more powerful than before because it’s chasing value rather than chasing money. The fallacy of chasing money in the old world was that the money was going to be spent anyway, the wage bill is going to be paid at the end of the month regardless2.
Money is the slowest feedback loop running
The decision makers3 within the Portfolio do have the ability to adjust the budgets; it in necessary in order to allow for the focus of the business changing, to allow for the overall budget of the Portfolio as a whole to grow or to shrink. However, it is important to remind the Portfolio decision makers that moving the money between the Value Streams in the Portfolio is the slowest feedback loop.
Whilst the moving the money is instantaneous, “Value Stream #2 we’ve doubled you budget!”, it’s the spending of the money that is hard. Most of the money is spent on people and changing people is slow.
If the budget for a value stream is increased it can employ more people, it needs to recruit. Recruiting doesn’t happen overnight; it’s not uncommon for it to take months to fill a vacancy. Even if you could employ someone overnight4, how long is it going to take to get them up to speed on your systems, processes and designs?
Reducing money is equally hard, people will need to be made redundant. Due HR process needs to be followed, potentially engagement with unions or workers councils. It could be several months before the reduction in costs starts appearing on the balance sheets. Outsourcing staff might allow more rapid reduction in costs but there are often clauses in the contracts requiring due warning of such changes. Even if more money is allocated it’s not always possible to spend the money; there may be limits imposed that are outside of IT, e.g. constraints from desk-space or management capacity and availability.
Budgets become a constraint
Due to the fact that moving money is slow; once budgets have been set it makes sense to treat them as a constraint. The money a value stream has been given creates capacity because it is used to employ people; therefore you can only do as much as you have available budget/capacity until the investment budgets are changed5. Although the redistribution of the money is instantaneous, the employing of or retraining staff to consume that money takes time.
For the purposes of all lower level conversations that capacity should be treated as fixed; therefore the question becomes which pieces of work should be allow to utilise that capacity in order to return the maximum benefits to the organisation. The prioritisation mechanics kick-in.
If the company priorities change and it wants to do something different, then the budgets are a constraint. As discussed, moving the money is slow, if you need to change things quickly change the work. In order to prioritise the new work the quick fix is to defer or remove from the system any existing work that isn’t relevant, ruthless prioritisation.
Work can be cleared from, and introduced into, backlogs quickly. The next PI boundary is at worst 10-12 weeks away, most likely less than that. If it can’t wait until the PI boundary then the next sprint/iteration boundary is at worst 2 weeks away, most likely less. If it can’t wait for the next sprint/iteration boundary then the next Daily Stand-Up is at worst 24hrs away, most likely less. If it can’t wait until tomorrow then stop the line and get the teams working on it now; although, wherever possible, such disruption should be reserved for true emergencies rather than strategic changes.
What Next?
Next stop is Participatory Budgeting; SAFe provides a lot of information about “What you need to do!” in terms of process to follow; but the “Why are we doing this?” is often missed out. Therefore an exploration of where Participatory Budgeting came from and why it evolved is worth covering and then a dive into some of the subtleties of the process that are easy to lose sight of when trying to stage a Participatory Budgeting event.
#1 I’ve heard some horror stories of organisations on a “Pay-per-use” cloud contract that tried to run some stress test on the cloud. The cloud expanded to cope with the “stressful situation” and duly logged all of it’s activity against the account. That month’s bill had a few extra zero’s on the total!
#2 You could try “not paying”; let me know how it goes? My guess is the employees will be stealing the pot-plants from the lobby to sell on eBay in an attempt to recoup some of their losses.
#3 I tend to refer to these as “Lean Portfolio Management” but as of the SAFe 5.1 material there is a lack of consistency within the LPM material and different diagrams use different terms for the decision makers.
#4 If you’ve contracted out the engineering to an outsourcing company then they may be able to provide more people rapidly.
#5 Although there is a direct relationship between budget and capacity that relationship will change over time. If the team embody a Learning Culture to improve their skills, build out their Continuous Integration, Continuous Deployment development pipelines and are (re) Architecting for Releasability then the expectation is that the capacity available for a given amount of budget will increase.
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