“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 Use of Weighted Shortest Job First
The standard advice within SAFe is that when it comes to prioritisation use Weighted Shortest Job First (WSJF). It is a useful simplification to stop Cost-Of-Delay discussions getting unnecessarily complex, but there is more depth to the mechanic than people would assume from reading the SAFe webpage; depth that I’ve previously explored in a blog on The Subtleties of Weighted Shortest Job First.
Weighted Shortest Job First works at the Release Train level because the timeboxes, the Program Increments, exist. The challenge is that at the Portfolio level, where Epics can last for long periods of time, then I suspect that the “Shortest Job First” part of “Weighted Shortest Job First” is going to cause some problems. By its very nature going it’s to make it difficult to balance Short Term wins against Long Term investment, with the long term investment losing. Part of the reason for writing this blog series On The Nature Of Portfolios was to explore this very issue.
What follows over the next few postings are a series of “experiments” to explore the topic and look at the issues that arise. We’ll look at:
- WSJF using Total Epic Effort
- WSJF using Predicted Duration
- WSJF using Experimental Effort
- WSJF; what would Don do?
- WSJF considering Risk factors
- WSJF within the Investment Horizons
WSJF using Experimental Effort
Previous experiments looked at what happens when WSJF uses Total Epic Effort and when WSJF uses Predicted Duration to factor in swarming. The challenge still remains that important long term investments aren’t prioritised by an algorithm that favours short.
A third experiment; harnessing Lean-Startup thinking. Within this timebox (Program Increment) what experiments or new functionality does this Epic want to run to provide the metrics to justify the Epic’s continuation?
| Epic | BV | TC | RR|OE | CoD | Effort | WSJF |
|---|---|---|---|---|---|---|
| Product S Customer Survey |
1 | 1 | 8 | 10 | 0.2 | 50 |
| Product S Protoype |
1 | 1 | 3 | 5 | 0.8 | 6.25 |
| Product L Feature 1 |
3 |
1 | 1 | 5 | 1 | 5 |
| Product L Feature 2 |
2 |
1 | 1 | 4 | 1 | 4 |
| Regulatory (Swarm) |
21 | 1 | 1 | 23 | 2 | 11.5 |
| Enabler Analysis |
1 | 1 | 5 | 7 | 1 |
7 |
| Enabler Setup |
1 | 1 | 2 | 4 | 1 |
4 |
| Enabler Dev |
1 | 1 | 1 | 3 | 1 |
3 |
The WSJF is being calculated across the pieces of work that the Epic would like considered in this Program Increment. It is worth noting that we are not breaking the Epic apart, just considering which experiments or feature increments within the Epic should be prioritised. Product S has put forward two small experiments that it wants to pursue, the remainder of the work that contains the true realisation of the Business Value remains in the Epic and might be put forward in a later Program Increment, assuming the two experiments prove true and give the Portfolio confidence to continue with the Epic.
When would you slice an Epic up rather than just propose an piece within it? When the Business Change within the Epic can be accomplished in independent pieces and success is independent. Example: Regulatory compliance to a new reporting standard, each Product or Development Value Stream could independently ensure that it is complaint but unless everyone is complaint the Business isn’t compliant. This wants to remain as a single endeavour rather than be split.
A topics to consider in another post if there are any rules or patterns for choosing how To pick the next experiment?
Observation: As below, so above1
The timebox that makes WSJF work within the Agile Release Trains has been reinstated; so it is starting to behave in a similar manner to the WSJF down in the Agile Release Trains.
The trap the unwary might fall into would be that if the Epics are suggesting all the Features that they desire within this timebox, then what differentiates it from the Train level WSJF? The slices being suggested do need to be at a higher level of abstraction. Furthermore, the Portfolio is an aggregate of all the trains and the Portfolio could, foolishly, be trying to run WSJF over hundreds of Features which quickly becomes unworkable.
The careless might also start elaborating the detail in the features before they have been prioritised and thereby revert to upfront design rather than just-enough, just-in-time. Upfront design leads to delays and waste; Delays whilst the elaboration is done and Waste when you’ve elaborated detail into an item that doesn’t get prioritised.
To avoid falling into bad behaviours I would describe the process as “Prioritising Outcomes”. How important is the Knowledge, the outcome of an experiment, how important is the value, the outcome of new functionality. Outcomes should be more aggregate than the set of Features and Enablers that contribtue to the Outcome and they are also what the Portfolio desires, how those Outcomes are achieved is something to delegate to the trains and teams. Carefully chosen words won’t always stop people doing the wrong thing, but they can steer people in the right direction.
Observation: Don’t loose focus
? One potential further problem is scatter; without appropriate WIP limits at the Portfolio there could be a large number of Epics in play. Each Epic puts forward the bit that they’d like to get done and all those pieces are duly prioritised and therefore the Epic moves forward a little bit. The problem is that instead of the effort being focused to make one or two Epic successful quickly, the effort is being scattered across all the Epics resulting in parallel development. Working on lots of items in parallel delays their completion. WIP limits would need to be rigorously enforced and monitored from outside the WSJF process.
Next Steps
It’s an interesting experiment, it has potential but there are numerous problems that can occur as described in the Observations.
Has anyone else considered this already? Don Reinertsen and Joe Valone proposed a more accurate version of Cost-Of-Delay for Portfolio use at the 2109 SAFe Summit; in the next post we’ll look at “What would Don do?”
#1 An inversion of Hermes Trismegistus’ quote “As Above, So Below”.