“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.
Enabler Epics
There are two types of epics, each of which may occur at different levels of the Framework. Business epics directly deliver business value, while enabler epics are used to advance the Architectural Runway to support upcoming business or technical needs.
Which sounds delightfully simple; just a repetition of the existing rules for Stories and Features. Blue ones (Business) generate business value, Red ones (Enablers) support future stuff. Except that Epics don’t work like Features and Stories…
There isn’t a level of work abstraction above Epics that can act as the grouping mechanism; therefore Epics have to be independent. The challenges with trying to break Epics up has already been discussed in Slicing Epics. Splitting them apart only makes sense if the split results in an independent increment of value, otherwise value can be lost. Preparatory work isn’t independently valuable, it needs something built on top of it for that value to be realised.
The slicing that occurs at the Team and Train level is being done to get to units of deliverable value that fit within the time boxes operating at those levels, Stories in Iterations, Features in Program Increments; Epics aren’t constrained by the time boxes. If preparatory work needs to be done it should be done as part of the Epic itself.
If you did split the preparatory work into it’s own Epic what would be the business case for it? It would be the same as the business case for the Epic that is the actual value; so why break it out? The one thing that separating it out could do is de-risk the future delivery, but that requires that the preparatory work be experiments to reduce risks rather than just a block of work to be done. Those experiments could be realised as Leading Indicators in the actual Epic.
What about preparing our business for the future?
I always explain Epics as Business Change and with Business Change you’re either doing it, or you’re not. There is no preparing for Business Change, that “preparation” is actually part of the change it’s just that the value of the preparative work won’t be realised until you build something on top of it.
| If you’re being pedantic then the Analysis that develops the Business Case for the Epic is the preparation; if the business case is approved then from that point on it’s all just change being executed. |
What do Enabler Epics represent?
Part of the problem lies with Enablers in general, they are not a “clean” concept, they’re a combination of several things.
An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, architecture, infrastructure, and compliance. Enablers are captured in the various backlogs and occur throughout the Framework.
That all sounds nice and simple, just a categorisation for work that is preparing for the future; it helps the Architectural Runway by encouraging the evolution of the architecture incrementally. To ensure that some of the Architectural Runway is always done there is Horizons Guardrail #3 : Capacity Allocation.
What’s wrong with that?
Well Capacity is Effort, Effort is Time, Time is Money, and when Money gets involved people start behaving differently.
| “That’s not my budget, that’s part of the Architectural capacity!” |
A quick thought experiment by way of illustration. The Business has created a Feature that’s in an Agile Release Train’s backlog; since the Business created the Feature it consumes the Business portion of the Capacity Guardrail for the train. In order to deliver the Feature the team responsible realise that they need to do some Architectural work, so they create an Enabler story. Who’s capacity does the Enabler story come from? “Not mine,” cries the Business “that’s Architectural work”, and yet it’s architectural work on their behalf, for their functionality.
The Capacity Guardrail is presented as a simplistic Business/Architecture split whereas in reality there are two separate and distinct dimensions in play: the Source Of the Work requests be it External (Business) or Internal (Team/Train) and Value Realisation which can be either Direct or Indirect.
Source Of the Work
Where has the work originated from.
From the perspective of an Agile Release Train I’ve always phrased this a External vs Internal. Is the work External to the train, i.e. Customer or Business requests, or is it Internal to the ART, i.e. self-Improvement, technical debt and preparation for the future. That phrasing doesn’t work so well at the Portfolio level because the Portfolio encompasses everything; substitute Strategic for External and Local for Internal. Strategic work derived from the Portfolio vision and strategy, Local work coming up from the Agile Release Trains.
This is the dimension that the Business/Architecture Capacity Allocation is trying to address, it is there to ensure that the Locally generated work from the ARTe always gets a chance against the Strategic work from the Portfolio, otherwise the health of the systems, both the system being developed and the system developing the system, will suffer through neglect and lack of maintenance.
Value Realisation
Direct value delivery realises value immediately as soon as the work is done. With indirect value you only start to properly realise the value created when you build something with direct value on top, i.e. building some business functionality (Direct) on top of architectural work (Indirect)2.
One of the reasons indirect work is created in the first place is that it helps with the scheduling and forecasting, particularly where some indirect value contributes to multiple pieces of direct value.
| The challenge with overlapping work is that the overlap will be repeatedly included in each of the estimates of the work that needs it; since the estimates have to assume Independence of the work because at the point of estimation nobody knows which piece of work is going to go first. If those estimates are used in forecasts, then it will look like the work is going to be done repeatedly and the forecast will be distorted with the end date for the set of work being further into the future than it should be. The fix is for the Architect(s) to spot the overlaps and break out an Enabler that can be done in a preceding Program Increment and once it’s done the estimates for the remaining work get smaller because the common, overlapping work has been dealt with. This is why roadmaps are so important, so that the technical staff can look ahead at what might potentially be happening in the future and add Enablers to the Architectural Runway to prepare for that future. |
Another source of work with indirect value is improvements to the Continuous Delivery Pipeline. This could be procedural improvements to the processes or technical improvements to the tooling. There is no direct value, the value comes indirectly from that fact that future work can be accomplished more efficiently.
Taking the two dimensions of Source which the categorisation of Local or Strategic and Value Realisation which is Direct or Indirect; what do the quadrants look like?
Figure 2: Internal/External vs Business/Architecture
| Strategic, Direct : Strategic new functionality. Derived from the Portfolio Vision activities; generally contributing to Strategic Themes. New business, new income, reduction of losses or penalties. Expected return-on-investment could put it in any of the Horizons. |
| Strategic, Indirect : Operational Efficiencies. Improvements to the organisation that don’t result in new money, but allow it to use the existing investment more efficiently and effectively. Expected return-on-investment could put it in any of the Horizons. |
| Local, Direct : Improvements to the existing functionality that are originating from within the Development Value Stream and the interactions that the Development Value Stream’s Product Management team are having with their customers. This is typically about “Retaining and supporting existing business”, the work should generate immediate value, expected return-on-investment is quick, less than a year, putting it in the Horizon 1 space. |
| Local, Indirect : Improvements to tooling, processes, infrastructure or existing architecture that are originating from within the Development Value Stream, often as a result of retrospective processes. The work has immediate internal value in that it allows the Development Value Stream to be more efficient, effective, less risky, etc…, expected return-on-investment putting it in the Horizon 1 space. |
Which quadrants are represented by Enabler Epics?
Why do you want to create Enabler Epics?
Epics are Epics, regardless of whether they are categorised as Business (Blue) or Enabler (Red); why do you need to categorise them? What is that categorisation trying to manage?
What are the unique properties of an Enabler Epic?
| They can be given a capacity allocation; which allows a certain amount to always be considered in the prioritisation discussions. This is necessary because the indirect value of Self-Improvement work can often be overlooked in favour of the direct value of Business/Customer requests. |
Whilst the above assertion is true at the Team and Train level, it’s not so clear cut within the Portfolio. All Epics have a Lean Business Case, including Enablers Epics. Even the internal work, the operational efficiencies should have a quantifiable impact on the business, Cindy VanEpps did a presentation at the SAFe Summit 2019 : Economics Of Value Delivery that describes the cost, real dollars being lost from the bottom line of the accounts, of not doing the Agile processes. If Enablers are approached in this manner, traced back to their impact on the corporate accounts, then their Business Cases are easily able to compete against the new work. There is almost no need for the distinction of Business and Enabler Epics, the Business Cases stand or fall on their own merit; being an Enabler doesn’t confer any advantage in discussions about the Business Case.
However, not every Business is as adept at Principle #1 Taking an Economic Approach as they should be, hence the need for Enabler Epics in order to defend the indirect value of Self-Improvement work arising from the Development Value Streams against being continually ignored in favour of direct value. The reason why this needs to be defended is that if you don’t maintain the machinery by which value is generated then eventually that machinery will fail; the machinery here being the teams, tools and processes in a Development Value Stream.
There is also a human aspect to this; what is driving the organisation, or individuals, to want to create Enabler Epics?
- What are they trying to manage?
- What are they trying to compensate for?
Because Enabler Epics are combination of things it’s necessary to ask this to understand each implementation’s own particular reasons. Context is king, what are the reasons within your own environment?
Why would you want to create an Enabler Epic?
- Visibility to provide focus on the work in its own right.
- Gaming the algorithms because the current Epic is too big to make it through WSJF.
From the above, the former might be a sensible reason for creating Enabler Epics, the later probably isn’t.
If you’re trying to game the prioritisation algorithms then you have to ask yourself why? Is the algorithm broken, or is your piece of work just not valuable enough? It’s hard to admit the latter, but sometimes it’s necessary to kill you darlings3. The challenges of the algorithm have been discussed extensively in Portfolio Weighted Shortest Job First (WSJF) and the difficulties of balancing Short Term wins against Long Term investment.
If you want visibility it’s not the Enabler part of an Epic that provides that visibility, it’s the Epic part of the Enabler Epic. Epics have actionable Business Outcome that can be tracked, that the Portfolio should be tracking those Business Outcomes and assessing them on a PI by PI basis to understand whether then Epic should be allowed to continue. The continual assessment has been described as part of the discussion around Portfolio Events.
Why do you want to create an Epic?
Didn’t we just answer that?
No, reread the titles carefully!
Why do you need to create an Epic for work that is generated by a Development Value Stream and will be delivered by the same Development Value Stream? Couldn’t this just be a collection of Features within the Development Value Stream itself? Value Streams should always have some discretionary spend to do with as they see fit?
Does this work really require the portfolio scrutiny of an Epic? Or is it the mechanism by which the set of Features is collected together; to give them common purpose and trackable metrics through the Business Outcomes and Leading Indicators? Is an Epic being created for convenience?
There’s possibly another human element at work here as well; trust and control. The Portfolio wants everything as Epics because they don’t trust the Development Value Streams to make sensible decisions, Epics become the Portfolios means of exterting control. Everything ends up as an Epic, but the time and effort involved in building and approving the business cases slows everything down, hampers agility, inhibits decentralised decision making and reduces speed of response. The fix is not for the Portfolio to impose more process on the work items, the Epics, but for the Portfolio to engage with people in the Development Value Streams in order to build their confidence that the people in the Development Value Streams are making sensible decentralised decisions. Close the accountability loop by seeing the demonstrations and tracking the metrics to validate that the decisions being made are moving the organisation towards the vision defined by the Portfolio..
Why do we need Enabler Epics?
We need them to give Indirect value a chance to compete against Direct value.
Strategic work, part of The Portfolio Vision, doesn’t need to defend itself because it is part of The Portfolio Vision. If the strategic work is preparing for the future then it’s likely to be work in Horizon 3 (Evaluating new ideas) or Horizon 2 (Emerging new and next generation solutions) and the guardrails supporting the Horizons will provide some capacity to enable Epics in those Horizons to make progress.
The categorisation becomes important for Horizon 1 (Defending and extending the existing business) where the deferred or indirect value of Enabler Epics can struggle to compete against the immediate, direct value of the Business Epics.
Examples Of Enabler Epics
Local, Indirect Value: Work the Teams/Trains have spotted that is beneficial to them rather than the end-customer but requires Portfolio level coordination.
- Upgrades to operating systems or underlying software libraries and applications where the upgrade has to happen across the organisation.
- Changes to interfaces between systems or solutions that will require coordination to ensure that connected systems change at the same time.
Conclusions
Peering under the covers reveals that Enabler Epics aren’t as simple as they may at first present themselves.
In summary:
| Enabler Epics are not preparation in the same way that Enabler Features and Stories are.
The Enabler classification is really only necessary if a capacity allocation is being used to allow the Enablers with their indirect value compete against the direct value of the Business requests; and this is really only necessary for Horizon 1 suggestions coming up from the Development Value Streams because anything strategic is already part of the strategy. |
I’ll fully admit that it’s taken me 15months on-and-off to try and turn that messiness into a coherent storyline that explains why it’s a mess and I do need to acknowledge my colleagues Keith DeMendonca and Ian Spence for the many, many discussions over the last few years that have contributed insight to this article.
Where Next?
There’s a handful of topics still to discuss: Epic Ownership would be the logical next step, but the topic of Multiple Portfolios is also raising its head again!
#1 SAFe also has Capabilities but I would suggest that they are more of a grouping mechanism rather than a work item; as discussed in the article on Slicing Epics
#2 Don’t fall into the trap of thinking that everything is deferred value because you have a bad process that is incapable of getting the value of the item into the hands of the customer quickly. That’s a bad process, invoke SAFe Principle #2 : Apply Systems Thinking and fix it!
#3 https://idioms.thefreedictionary.com/Kill+Your+Darlings