On The Nature Of Portfolios
“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.
Epics are the work item that the Portfolio deals with. Their description within the Scaled Agile Framework is fairly perfunctory; it covers their formating, estimation, simplistic forecasting and an overview of lean-startup. They are a deep topic that is very lightly treated in the current version (5.1) of the framework.
The next few postings intend to explore some of the detail around Epics; topics to explore are:
This list will probably grow as initial explorations open further avenues of investigation.
Epics – Slicing Epics
The previous postings have been exploring how SAFe’s recommended prioritisation mechanic Weighted Shortest Job First can be challenging at the Portfolio level because the Shortest part of the algorithm is dominant and the smaller, shorter items will tend to get prioritised first. Decades of research into Lean manufacturing has shown that dealing with smaller pieces has many benefits, better flow, faster feedback, quicker rework when things go wrong, so if smaller is better, why not make the Epics smaller, split them up.
Epics should always be as small as they possibly can, however this is where the subtleties lie and those subtleties are what this blog post intends to explore.
Splitting Can Lose Value
If you can slice the Epic up into smaller Epics that are independently valuable then do it! This should be the default behaviour. However there are scenarios where slicing the large endeavour up would destroy the value.
The example used for this blog post is GDPR; any business that wanted to trade in the European markets had to ensure that their business complied with a set of data protection and retention rules. Failure to abide by those rules could result in fines up to 4% of an businesses global turnover.
The scenario is a big business with many divisions and sub-divisions that need to be GDPR compliant.
Obviously there are many ways of tackling the GDPR challenge but the two extremes of the spectrum are utilising a single large Epic and subdividing into small divisional Epics.
- Single Large Epic; created to describe “GDPR Compliance”. The Business Outcomes are simple to express , “no penalties are issued against the business.”
- Subdivided Into Smaller Epics; each Epic is the compliance of a single division or sub-division. The Business Outcomes are, “division or sub-division is GDPR compliant.”
The challenge is that value in the GDPR endeavour is only realised when the whole business is GDPR compliant; any one division or sub-division of the business not being GDPR compliant and the business as a whole is liable to a penalty.
Subdividing into smaller Epics loses the overall value, but if the big single Epic is retained it will never be prioritised by a simplistic WSJF . This is a trade-off, there isn’t going to be a “right” answer, all that can be done is to understand the trade-off and treat things on a case-by-case basis.
Retaining a Single Large Epic
The Epic properly captures the value to the business. The business as a whole needs to be compliant for the value to be realised. Leading Indicators could be constructed to track progress across the business, division-by-division.
However, Portfolio WSJF is unlikely to prioritise the Epic because it is large; job-size is always the most significant factor in a WSJF calculation. Assuming that everyone is sticking to the processes then if GDPR is never prioritised it never gets done. Business isn’t GDPR compliant,
- Change the processes so that large Epics have a chance of being prioritised and some potential ideas for adjusting WSJF at the Portfolio level have been discussed in earlier blog posts.
- Change the work so that it’s comprised of smaller pieces and track the overall value separately.
Subdividing into Smaller Epics
Portfolio WSJF should prioritise the smaller GDPR Epics because they’re small, this gives the Epics a chance at getting prioritised and the work being done. However, the link to the real value, everything being compliant, gets broken because in the GDPR example the value is indivisible, either the business is compliant or it isn’t. This is a problem because there is no guarantee that all of the smaller GDPR Epics are going to get prioritised, unless something is holding them together.
There are a number of ways that the smaller Epics could be held together to retain focus on the bigger endeavour of making the whole business GDPR compliant.
Maintaining Alignment through Portfolio Vision & Outcomes
The Portfolio Vision could be used to generate the alignment amongst the stakeholders participating in WSJF that the GDPR endeavour is an important things to focus on. This is reliant on the people performing the WSJF to behave sensibly and prioritise the bits, there is no mechanic that is holding the smaller Epics together and providing containment and progress tracking. Lean Portfolio Management needs to close the accountability loop to ensure that the Epics are being prioritised, road-mapping activities can be used to predict whether all of the Epics are going to be done in time. The GDPR endeavour could be set-up as an objective for the Portfolio, a measurable outcome. Every Portfolio has a set of measures and metrics that are describing at a very high level what it is trying to achieve; in this example “% of business that is GDPR compliant”.
Maintaining Alignment through a Container
Another option is some form of container around the set of Epics that groups them together to track progress. I don’t know what this Epic grouping should be called but for the sake of giving it a name I’ll call it an Initiative.
I am always reluctant to introduce something new to the system of work items, it’s another point for people to get things wrong, misunderstand and misuse. In this case there will be a tendency for people to think of an initiative as another level in the work hierarchy rather than a grouping mechanic.
In my mind the work stack shown on the left-hand side of the diagram is Stories, Features, Epics.
- Stories change the code, mechanical or electrical designs, marketing material, whatever it is that your teams manipulate and change.
- Features change the system or solution. They are the releasable points.
- Epics change the business.
There is nothing above an Epic, because there is nothing above changing the business, that’s the biggest change that could be made.
The grouping constructs are shown on the right:
- Initiative groups together a set of closely aligned Epics. In our GDPR example it becomes the holder of real value and the metrics to track real value when the overall GDPR endeavour is split into the smaller Epics.
- Capabilities group together a set of features that are tightly coupled and need to be planned and delivered within the same PI but the Features must be in different trains. Capabilities are described in the Framework on the Features page and described as super-features but little context is provided as to why you might need capabilities.
Observation: Grouping retains the value when slicing has destroyed the value.
The grouping mechanics, Initiatives and Capabilities, occur because slicing the work up loses the real value but the work item must be broken up to get it done due to other constraints within the system. The grouping now holds the real value.
The grouping mechanics shouldn’t need additional roles; the group is owned the set of people that own the work items within the group and they need to collaborate together to maintain alignment, track progress and resolve issues.
Earlier posts looked at how WSJF could be adjusted to try to handle Long Term investments. This post has examined the problems that can occur when slicing Epics up to beat the algorithm and suggested that a grouping mechanic might be needed to hold things together if the slicing loses the value that was intended. The next post will look at the Epic feedback loop and how the metrics around an Epic drive decision making.