“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.
Epic Owners
Over the last few years I’ve covered the lifecycle of Epics, Epic prioritisation and the Portfolio Events that keep everything running smoothly, what hasn’t been covered until now is who is actually responsible for making all of this happen. The system doesn’t run itself, it needs human input.
The primary role that cares for and progresses an Epic is known as the Epic Owner. In this posting we’ll go back over the lifecycle of an Epic and play some games with the Epic cards to understand what activities progress the Epic through it’s lifecycle and from them we can understand what an Epic Owner actually has to do.
Responsibility Wheel
SAFe introduced responsibility wheels in SAFe 6.0 to help the various roles visualise what they have to do. By necessity these are at a fairly high level of abstraction; it’s the goals rather than the practicalities of how those goals are achieved.
Figure 1: Epic Owner Responsibility Wheel
Can this high level abstraction be made more concrete?
I think so. Epic owners are primarily concerned with the lifecycle of Epics, so let’s look at that lifecycle.
Epic Lifecycle
The states an Epic progresses through were first developed and described in the Epic Lifecycle post. The cards themselves have evolved since the earliest hand-drawn incarnations, not only have they changed to green which is the colour used to represent opportunities, they’ve acquired more information on the back.
Figure 2: Epic States
Turning the card over (the backs are shown alongside in the images) now provides insight into the activities that can be used to get the Epic into the described state. Those activities start to inform the role of the Epic Owner.
Let’s play a couple of games with cards. The games are summarised on cards and a full description is provided in the facilitators guide that accompanies the cards.
Figure 3: Game Cards
- Lay the state cards out in a line across the top of a table.
- Using the back of the state cards, locate the activity cards that get the item into that state and line them up below the state that they contribute to. Where activities contribute to multiple states Post-Its™ are used to represent them as there is only one instance of an activity in each deck of cards.
- Discuss each activity. Does the Epic Owner role contribute to that activity?
Mark those that the Epic Owner contributes to with a Post-It™.
- Are there any other activities that facilitate the activities involved in moving the item through it’s states?
That’s what an Epic Owner does…
…of course the subtleties were all in the discussions that placed those Post-Its on the various cards, so let’s see explore some of the detail. Working left to right through the activities that move the Epic through it’s lifecycle.
Strategy Formulation
ART Inspect & Adapt
These two activities are both potential sources for Epics, they get the Epic into the first state, Requested, where the idea has been captured by Portfolio ready for further progression in the future.
Figure 4: Epic Requested
The process of Strategy Formulation looks at where the organisation wants to be in the future. Given that the organisation should know where it is now and where it wants to be, then it has a delta, a change, that needs to be enacted. The artefacts for achieving that change at the Portfolio Level are Epics, one or more would be identified to enact the change.
The role of Epic Owner wouldn’t be involved in Strategy Formulation, the role is involved in the enacting of the strategy after it has been formed and is being realised through Epics. The individual playing the role of Epic Owner might be involved in Strategy Formulation but that is arising as a result of the other roles that they play within the organisation and their personal knowledge of what the organisation should be doing.
ART Inspect & Adapt, the retrospective process within the ARTs, can also generate ideas for changes that span across multiple DVS/ARTs or across multiple planning intervals. These internally generated ideas could be both new business ideas or ideas for internal improvements. Because they span across multiple DVS/ARTs and would be drawing significant capacity from those DVS/ARTs they require Portfolio approval. Anything that could be handled within a single DVS/ART with minimal external interactions should be handled locally within the DVS/ART, even long running activities that span multiple Planning Intervals can be handled by breaking the large endeavour down and delivering it incrementally through a series of Features.
The Epic Owner might be involved in the ART Inspect & Adapt if the ART is contributing to their Epic and they’re acting as a stakeholder to the ART and what it’s trying to achieve. Stakeholders should be present at the ART Inspect & Adapt activities because they may have problems that they want the ART to examine, also they have expertise that can contribute to solving some of the problems that the ART is examining.
Form Epic Hypothesis
Estimate Epic
Forming the Epic Hypothesis and creating an initial estimate gets the Epic to a Forecastable state where it can be used for Road-mapping and Budgeting activities1.
Figure 5: Epic Forecastable
Form Epic Hypothesis creates the Elevator Pitch, the Business Outcomes and the Leading Indicators. This turns the Epic from a raw request into something that can be discussed and compared against other Epics because they all follow a common format.
Has an Epic Owner been assigned at this point? I would suggest no, but that is my interpretation of the process and organisations may choose to interpret it differently. The Epic Hypothesis Statement would be filled out by a small central group of people within the Portfolio. Again, the individuals concerned might play the role of Epic Owner elsewhere but this activity is not being performed under the auspices of that role.
The Epic being clearly described and having an initial estimate means that it is in a state where it can be used for Participatory Budgeting and Road-Mapping activities. Both these activities are about reserving money or time for the future and through the wage bill time is money. All that is required to make those reservations is a description of what is making the reservation, which is provided by the Epic Hypothesis Statement and the estimate which detail how much should be reserved. A Business Case isn’t needed at this stage and if the idea doesn’t find room on a roadmap or have money allocated to a DVS on it’s behalf then is it even worth developing a Business Case?
Try to maintain a separation between Budgeting/Road-mapping and Approvals, if the Approvals and Budgeting/Road-mapping get conflated then the road-map becomes a queue, and long queues are bad!2 This is discussed in the Participatory Budgeting article.
Develop Business Case
Estimate Epic
Developing the Business Case and revising the Estimate on the Epic prepares it Ready to be Approved.
Figure 6: Epic Ready
This is the first point in the lifecycle where a significant amount of work needs to be done and that work can’t be done by a single person alone, different inputs to the business case will come from different specialisations around the organisation. In order to coordinate the creation of those inputs there needs to be a named person, which is where the role of Epic Owner starts.
The Epic Owner will need to liaise with Sales, Marketing, Accounts and perhaps others, to estimate the anticipated return from making this change to the business. The return could be profits, new money, or it could be savings and improvements that allow more to be done with the existing money.
The Epic Owner will need to liaise with the technical disciplines of Enterprise Architecture and System Architecture for a technical impact analysis which will inform estimates about the cost of delivering this change. The reason that the Epic Hypothesis Statement asks about NFRs is that the architecturally significant NFRs will have an impact on the technical analysis. Scale and Rigor are the key concerns. Scale will influence the solution, e.g. a system that only needs to support a 100 concurrent users could be a beige box beneath someone’s desk, a system that needs to support a 100 million concurrent users is likely to be a massively distributed cloud based system similar to Netflix. Rigour, e.g. a desktop app where the consequences of it crashing are just a loss of data doesn’t need the same level of rigor to it’s development as flight software where the consequences of it crashing is the aircraft crashing and therefore the process by which it’s developed need to be more rigorous and thorough ensuring that all decisions and the reason behind them are documented, all development and testing is traceable back to those decisions, etc…
The activities to Develop the Business Case and to Estimate Epic would happen on an ad-hoc basis as needed, but the Portfolio needs to check that the Epic Owner is making progress, for that there is the Portfolio Sync (Epic Progress) described in the Portfolio Events article. Keep the recurring, ceremonial, activities small by making them short term planning events which plot-out when the other activities need to happen, be that activities to do the work, or activities to resolve impediments to doing the work.
Strategic Portfolio Review (Epic Cancellation & Approval)
Determining the set of Epics that are in play and therefore authorised to consume effort from the Development Value Streams / Agile Release Trains by negotiating Features in backlogs.
Figure 7: Epic Approved
The Strategic Portfolio Review (Epic Cancellation & Approval) is the activity whereby the set of Epics that are “in-play” is determined. That can involve cancelling Epics that aren’t achieving their stated Business Outcomes and Leading Indicators and approving new Epics to consume the capacity freed up by the cancelled Epics. The Epic Owner would be expected to present the Business Case for the Epic at the Strategic Portfolio Review.
Whilst the decision to approve the Epic isn’t up to the Epic Owner, it lies with Lean Portfolio Management, the nature of the decisions being made has been discussed in Dynamics Of Decision Making In The Portfolio Kanban.
Prepare A Feature
Coordinate Across ARTs
To prove that the Epic is Viable, and for the Epic to reach the point where the work is done and the portfolio is just Extracting value from the Epic, then the Epic Owner will need to negotiate work, Features, into the Development Value Streams / Agile Release Trains to get changes made.
Figure 8: Epic Viable
Figure 9: Epic Extracting
The Epic Owner needs to Prepare A Feature, probably many, and negotiate it into the backlog of the relevant Development Value Stream / Agile Release Train to trigger them to make changes to the Solutions that they own. The Epic Owner will need to work with the Product Manager to prepare the Features going onto the backlog but they have to remember that they are just one of many stakeholders to the backlog. Ultimately the Epic Owner will need to participate in the WSJF to help prioritise the ART backlog, as described in The Subtleties Of Weighted Shortest Job First.
If the negotiated Features aren’t being prioritised because other Features are more valuable, then it might be time to declare the development over and move the Epic into the Extracting state where the Portfolio is watch the value build up, hopefully, but not always, to the epic being Successful.
If the work going into multiple ARTs is connected in some manner, then the Epic Owner is perfectly positioned Coordinate Across ARTs. They can notify the Product Managers responsible for the backlogs that the work is being negotiated into, that they need to be talking to each other to keep the backlogs aligned so that the work goes into planning at the right time and that the teams in their ART will need to talk to teams in other ARTs.
The activities to Prepare A Feature and Coordinate Across ARTs would happen on an ad-hoc basis as needed, but the Portfolio needs to check that the Epic Owner is making progress, for that there is the Portfolio Sync (Epic Progress) described in the Portfolio Events blog post. Keep the repeating, ceremonial, activities small by making them short term planning events which plot-out when the other activities need to happen, be that activities to do the work, or activities to resolve impediments to doing the work.
Measure Leading Indicators
Measure Business Outcomes
Strategic Portfolio Review
Features being negotiated into ART backlogs trigger those ARTs to increment their solution, when the increment is released then it becomes possible to Measure Leading Indicators and Measure Business Outcomes, as described in The Epic Feedback Loop.
Figure 8: Epic Viable
Figure 9: Epic Extracting
Figure 10: Epic Success
Gather the metrics, Measure Leading Indicators, Measure Business Outcomes. These aren’t the neat, easy, metrics that bubble up out of the agile tooling, these are true business metrics and will require effort to measure. It’s trawling the corporate accounts trying to attribute financials to this particular change; it’s surveying the customers to determine whether they like the changes that have been made. Real effort that the Epic Owner needs to either expend themselves or organise others to prepare the information on behalf of their Epic.
The metrics are used in the Strategic Portfolio Review to prove to Lean Portfolio Management that this Epic should be allowed to continue consuming capacity from the ARTs. Every Epic, in every Planning Interval, needs to be assessed as to whether:
- Stop An Epic : If all the known work has been done, or WSJF isn’t prioritising the features, then it might be sensible to stop all further work on the Epic and move it to a state where value is being extracted from the work already done.
- Pivot An Epic : The Leading Indicators describing the Minimum Viable Product have shown that the stated hypothesis is false. The organisation needs to decide whether it wants to try again with a slightly different hypothesis or whether to redirect its efforts to other Epics.
- Declare An Epic A Success : The Business Outcomes have been achieved; the change enacted by the Epic has been Successful. Celebrate!
- Declare An Epic A Failure : The Business Outcomes have stalled and it’s clear that the Epic will never achieve them. Retrospect and learn for the future.
| Psychology of stopping : Turning failures into wins |
|---|
| People don’t like stopping work, it’s often perceived as a failure.
Old world project management practices reinforced this by tracking the work being done, expecting all of the work to be done regardless of whether it was useful or valuable. Agile reinforces this in it’s treatment of the lower level backlogs by stating that there is no value in work that isn’t complete! Which is true for doing work at the lower levels, but Epics aren’t work they’re change, they behave differently. Incomplete isn’t necessarily a bad thing. The goal with change is to maximise the amount of value the change produces for the minimum amount of work. Ideas for changing the business have to be explored, if you don’t explore them you’ll never do anything new and then bad things will happen when the current products, services or solutions run out. The goal is to minimise the amount spent before you realise the idea won’t work, this is the Lean Start-Up mentality at work. Stopping an idea that won’t work should be celebrated, it’s saved the company from wasting huge amounts of money on creating the wrong thing, money that can be diverted to other ideas. Ideas for changing the business that are pursued, that are successful, do you need to do all of the work? Often the majority of value comes from just a small part of the change, everything else is nice to have functionality that people are dreaming of. I hate to stamp on peoples dreams, but is that nice to have functionality really worth the development expense? Stopping the work on the change early once value has been delivered, but before you waste money developing irrelevant functionality, should be celebrated, it’s given the company spare money to pursue other ideas. Innovation accounting states that their is value in knowledge. Failures need to generate knowledge to help steer the organisation in the future, what not to do, how not to do things. This leads to better results in the future, that’s worth celebrating. Failures that don’t generate knowledge to improve the future are true failures, the expenditure wasted because nothing has come of it. Don’t blame the Epic Owner for a failure. It’s not their fault that they were assigned the idea for a change that didn’t work out. If they have discharged their responsibilities in a professional manner and seen the idea for the change through to it’s logical conclusion be that success or failure, then that professionalism should be acknowledged and rewarded. Never, ever, incentivise or reward around the success of an individual idea or change, because then it won’t be allowed to fail even when it is a failure! |
The activities to Measure Leading Indicators and Measure Business Outcomes would happen on an ad-hoc basis as needed, but the Portfolio needs to check that the Epic Owner is gathering the metrics, for that there is the Portfolio Sync (Epic Progress) described in the Portfolio Events blog post. Keep the repeating, ceremonial, activities small by making them short term planning events which plot-out when the other activities need to happen, be that activities to do the work, or activities to resolve impediments to doing the work.
Who makes a good Epic Owner?
Whilst the role of Epic Owner might look a lot like the role of Project Manager from the old-world and there are a lot of similarities, there is one thing missing from Epics that Project had, money. Losing the money means a significant shift in authority, work now has to be negotiated on it’s value to the organization rather than it commanding through virtue of it holding the money. This means that Epic Owners need to be good negotiators as they have to argue for each Feature going into a ART backlog. They’re going to need to be prepared to sacrifice themselves, and the work they represent, if another Epic’s work is more important to the organisation as a whole.
In order to assemble a Business Case an Epic Owner needs to be well connected. Contacts on the business side in Sales, Finance, Marketing to help assemble estimates about the potential return on investment. Contacts on the technical side in Enterprise Architecture and System Architecture to get a technical impact analysis organised and estimates of the effort involved. Contacts on the product side in Product Management to get features negotiated into ART backlogs
Epic Owners need to be people that can get stuff done. Whilst there is oversight through the Strategic Portfolio Review and Portfolio Sync (Epic Progress) an Epic Owner will need to be self-organising as other than the initial “this is your Epic” there is nobody directing them and telling them what to do day-to-day.
Conclusions
Taking the responsibility wheel for an Epic Owner and laying the activities over it, shows that the activities do cover all of the responsibilities and start to provide a more insight into what an Epic Owner actually has to do on a day to day basis and how those activities progress an Epic.
Figure 11: Activities against Epic Owner Responsibility Wheel
Freeform not ceremonial
Most of the activities that the Epic Owner needs to perform are fairly freeform, they can happen when and where it makes most sense to do the activity. The amount regular, recurring, ceremonial style activities is constrained to Portfolio Sync (Epic Progress) to check that they’re making progress, resolve impediments and plan out the freeform activities, and the Strategic Portfolio Review (Epic Cancellation & Approval) which happens every Planning Interval to determine the set of Epics in play.
Freefrom is good, it allows the Epic Owner to line up activities with their stakeholders, when those stakeholders have free time.
Those Cards Look Useful!
Yup.
It’s something we’re working on but isn’t quite ready for release yet. Peer reviews, legal agreements, typesetting. This is no different from the real world where getting something released often involves significantly more than just creating the thing you want to release.
When they become available we’ll link to them. Keep an eye out for announcements.
Next Steps
Many of the activities that an Epic Owner needs to perform have already been described within these blogs, particularly the events that keep everything in the Portfolio running. Two areas that haven’t been explored yet are Coordinate Across ARTs and the process of an Epic coming into being, through the activities Form Epic Hypothesis and Build Business Case.
#1Arguably, budgeting is just a money roadmap.
#2SAFe Principle #6 : Make value flow without interruptions : Flow accelerator #6 : Reduce Queue Lengths