Question & Answers
Questions & Answers from the webinar on Writing Better Epics In SAFe
Sign up for the remaining webinars
Who can play the role of Epic Owner, as it is not a standard role?
Anyone can play the role of Epic Owner but they do need the time available to devote to owning the Epic and the skills and connections to own the Epic.
To own the Epic the individual assuming the role needs to: build a business case, negotiate Features into ARTs, gather the Business Outcomes and Leading Indicators. To achieve that they need to be well connected within the organisation. Building the business case requires connections to Sales, Marketing and Finance for estimating the Return-On-Investment, calculating the costs will require connections to Architecture and Engineering, Procurement and Purchasing. Negotiating Features into ARTs requires connections to the ARTs and the central roles of Product Manager, System Architect and Release Train Engineer within the ART. Gathering the Business Outcomes and Leading Indicators is going to require connections to ARTs, Sales and Finance.
All of the above takes time, so the Epic Owner needs time. For an Epic seeking approval it is the time required to elaborate the Business Case. For an approved Epic then they need to be present at the ART Events of PI Planning, System Demo and I&A. They also need to work with the Product Manager - Product Owner group to create Features for the next Planning Interval. Gathering the Business Outcomes and Leading Indicators to provide proof that this Epic has made progress and should be allowed to continue will take time as well. Being an Epic Owner is not something that can be done as an afterthought, the individual needs substantial time available to undertake the activities necessary for successful Epic Ownership.
For Epics that are changing the organisation to create new or extend existing business it makes sense for the Epic Owner to understand the Business change being enacted, this may mean that they come from the Business. For Enabler Epics that are changing the organisation to allow it to do what it does more efficiently, it make sense for the Epic Owner to understand the process of how the Business operates. Contextual knowledge about the change the Epic is enacting is always going to helpful to an Epic Owner. If they don’t have that Contextual Knowledge then that is something they will need to learn as they develop and progress the Epic.
Look to the skills of the individual to determine whether they are the right person to
For more insight into what an Epic Owner has to do day-to-day, there’s a blog posting on Epic Owners.
Are the Epic Owner and the Epic Writer the same or a different role?
I’m going to assume that by Epic Writer we’re talking about the person that suggested the idea for the Epic.
Are they the same person? They could be, but more often than not they won’t be. Many Epics will come from activities to understand the Future Vision for the organisation, given a Future and an understanding of where you are now then Epics are created to change the organisation so that it becomes the vision of the Future. The activities to generate the Future Vision are likely to be done as a collaborative event with a group of people so the originator of the Epics are the group rather than an individual.
A good epic owner must also be able to manage more than one epic at a time?
Perhaps, but this is going to be very context specific and dependent upon the size of the organisation and the Epic’s that are changing the organisation.
If your Epics are small then one Epic Owner could potentially own more than one.
If your Epics are big then the Epic Owner might not be able to own the Epic alone and may need to assemble a small team to cover ownership of the Epic.
The real question is How much is the Epic changing the organisation? If it’s just adding new functionality to an existing product then Epic ownership should be relatively easy. If the Epic is creating a new line of business, or is transitioning the Operational Value Streams to a new product, or system, then relative to aforementioned additional functionality Epic ownership is likely to be harder. The complexity is likely to be driven by the outwards interactions with the Operational Value Streams rather than inwards to the Development Value Streams, inwards the Development Value Streams are there to support the change, and to support the Epic Owner making the change; outwards is trying to enact the change and persuade all of the people in the Operational Value Streams to change.
What is a ratio of Epics that reach Extract and ultimately Success in you experience?
This all depends where you start measuring from. If you start measuring from the point of ideation, then the majority will never reach success because the bad ideas are weeded out by the process early, so that those ideas that get through to Implementation have a much higher chance of reaching Success. Even those ideas that are Approved and go into Implementation might not be successful, the ratio is dependent upon how much the organisation is leveraging the Lean-Startup mentality. If you trying lots of ideas then lots will fail, if they’re failing early then that isn’t a problem, minimal time, effort and money have been wasted on them.
Be wary of removing ideas from the system before they’ve had to seek approval, you want to be presenting lots of opportunities to the Lean Portfolio Management to give them choice. Once ideas have been improved then rather than looking at a single dimension, the ratio of success to failure, you need to consider how quickly the failures were identified. Plot that on a graph and I’d expect to see lots of things failing early, very few things failing late. If your failures are following that pattern then you’re probably in a good place, if the curve is shifted towards the right, lots of things failing late, then that is indicative of late, lack of, decision making and will result in wasteful work being done before the idea is stopped.
Not reaching success doesn’t mean that the work hasn’t been valuable. It might have generated real income, possibly even been profitable, it’s just that it didn’t hit the desired targets. There needs to be a sensible conversation about what happened and why. Maybe the aspirations were unachievable in the first place, rather than it being a problem with the work. Step back, assess the broader picture, rather than being reliant on a single data point.
What if there’s only one ART?
Epics can still be useful within an ART. An Epic can provide the context, and arguably more importantly the metrics, for a collection of Features within a single ART that are all contributing to the same over-arching change.
Friend, occasional co-trainer and SAFe Fellow, Ian Spence has written a short blog on How To Benefit From LPM Even When You Are Not A True Portfolio.
In the spirit of “just get started” how far can a transformation really go before Finance is forced to adopt LPM OR the transformation stalls?
Do you really mean Finance, or do you mean the internal processes your management use to distribute the money across the organisation?
Your finance department don’t need to change at all, they still account for the money coming in, by selling products or services, and the money going out, by paying wages and contractual payments for buildings, infrastructure and services. True budgeting, not the messing around that IT managers do, is about making sure that the income and outgoings match up and that you’ve got enough cash available at the right time to pay those outgoings. My partner is a Management Accountant for a small-ish FinTech startup and her constant worry is having enough cash in the bank at the right time to pay the outgoings, that’s real budgeting.
The challenge is usually the processes used by the IT managers, where they pretend to move money around and that affects the structure of the organisation and what it’s working on. It’s an inherited behaviour, probably from physical construction where if you needed a wall you employed a gang of bricklayers for the day, if you needed a frame you employed a gang of steel-workers for the day. It doesn’t make sense when you have a standing workforce, particularly a workforce under European employment contracts where staff cannot be made redundant on a whim. The wage bill is going to be paid by the Finance department regardless of how the management have pretended to distribute it internally. You could try to “not pay the wage bill”, let me know where to send the flowers! Do you need to “move the money” to restructure the teams, no. Changing the teams isn’t going to change the wage bill going out at the end of the month. Do you need to “move the money” to change what work is being done? Changing the work isn’t going to stop the wage bill going out at the end of the month.
All of the above is just explanation as to why your budgeting processes don’t make sense, it doesn’t really answer the question of how do we get around them…
If your projects are “big”, they are funding for 50 or more people for a year or more, then with that funding secured you could run the set of people the project is employing as an Agile Release Train. Make sure that the people are dedicated to this project and not doing work elsewhere. If they do need to do work from elsewhere bring it through the backlogs to make it visible. I’ve worked in big investment banks, the bank will always think in terms of projects and my little 100person ART is the tail that can’t wag the dog that is the 100,000person bank. Thankfully, whilst the bank may think in projects, they’re sufficiently big to employ a large set of people and they’re sufficiently long lived, the bank also provides plenty of freedom, within the project as long as it’s successful it can be managed however the people see fit, so they run it as an Agile Release Train. The Epics that the ART does provide the metrics to prove back to the bank that the ART/Project is being successful.
If your project are “small”, then you’re more likely to be in a situation where they are “buying” capacity from cost-centers. You could fund the cost-centers directly and “flow” the work through them but they are likely to be arranged around disciplines rather than value. This is where you’d want to start the process of reorganising around value and having teams and ARTs looking after individual solutions or systems. They could still be funded by the projects “buying” capacity from them if the higher level budgeting process are slow to change, but at least the people are now organised so that they can own value delivery in their own right.
You can do a lot without having to change the wider organisation but if the wider organisation doesn’t evolve then there will always be a glass ceiling stopping you from reaching the benefits that the organisation desires. The challenges with evolving the budgeting processes are most often seen in bottom up transformations because the Teams and ARTs have transformed themselves independently but there’s nothing to cause the higher levels to transform. Top down transformations there is usually a central point that can start the process of transforming the Portfolio and budgeting processes alongside the ART transformations.
If an Epic is an Enabler Epic, what sorts of metrics, outcomes can be considered?
Which begs the question what is an Enabler Epic? This is another instance where Portfolio behaves differently from the ARTs and Teams below, because the work artefacts are not constrained by time. If you need to do preparatory work for some business change then that preparatory work should be done as part of the business change, there’s no need to separate it out because there’s no time constraint forcing smaller pieces. Indeed, the Business Outcomes for the preparatory work are going to be the same as the actual business request, but they’ll never be fulfilled, which just reinforces the fact that Epics aren’t work they’re Business Change which is distinct from the work needed to enact the business change. If you need to do preparatory work then that will manifest as Leading Indicators to measure that it has taken place and has been successful. If the preparatory work isn’t successful, you need to pivot or give-up, which is exactly the Leading Indicators and Lean Start-up mentality.
If Enable Epics aren’t preparation for future work, what are they? They are internal change, change where the organisation is the customer, change which makes the organisation better, faster, cheaper, happier. What are the metrics for internal change? I would still look towards the bottom line of the accountancy spreadsheet, the profit and loss, how can you show that the organisation is now capable of generating more value for the same expenditure, or generating the same value for less expenditure. Cindy Van Epps did an interesting presentation at the 2019 SAFe Summit which explains The Economics Of Value Delivery, i.e. illustrating what the cost to the company is of it’s good and bad behaviors.
Ultimately Business Epics are immediate value, whereas Enabler Epics don’t create immediate value but make the creation of future value more efficient. Efficiency metrics rather than profits/value.
Do the Epic’s change when a Government is using Agile?
No, they’re still enacting change upon the organisation.
What will change is the metrics being used to track success. Government organisations typically aren’t for-profit, therefore their metrics won’t be profit and loss. Instead, there will be other metrics used to validate success, typically measurements of the benefit that they have brought to society.
The other change that might occur is that the Epic Owner, instead of negotiating Features in ARTs that are directly owned by the organisation, they are negotiating Features into suppliers and sub-contractors. Agile contracting is a topic in its own right, for organisations that need insight into how to structure contracts to support Agile we run a dedicated 1 day course.
Can I use the rules of writing a SAFe Epic even if my organisation doesnt work within the SAFe Framework?
I don’t see why not. Indeed the Portfolio Level of SAFe is separate and distinct from the mechanisms that get work done, the Portfolio could investing in Development Value Streams and negotiating work into them, or it could be investing in Projects; it should use the right tool for the job. Choosing which is the right tool to use has been discussed in an earlier blog post. The methodology that you use to get work done can be different as well, Scaled Agile would prefer that you use SAFe, but as long as you can get work into teams, you could be using Scrum@Scale, Nexus, it really doesn’t matter, they all have more in common than they do different (it’s just that their advocates tend to highlight the scant differences and amplify those differences to differentiate them from one another!)
Would you limit the size of an Epic (split Epic into smaller Epics) so that it fits into a timebox? Or it seems better to limit the Feature’s size so we can measure progress release by release?
If you are going to split the Epic up, the split has to result in an Epic that is making a viable change to the organisation. Don’t split the Epic up just to have smaller pieces to game the metrics and processes, as the splits aren’t viable in their own right.
Changing an organisation takes time, months, perhaps years, do not expect Epics to move quickly across the Portfolio Kanban. The Portfolio Kanban is their for visibility, particularly seeing the queues building up, rather than tracking progress. Tracking the progress of an Epic is done by repeatedly measuring the Business Outcomes, every Planning Interval, those are the real indicators, not where it is in the process.
Features, which by definition must fit within a single Planning Interval, are the means of getting work done and released since they are releasable changes to the system/solution.
A blog post offering insight into what to be wary of when Slicing Epics.
Wouldn’t using WSJF help with this?
Perhaps, but WSJF at the Portfolio comes with it’s own set of challenges that aren’t necessarily apparent to the unwary, particularly around what measure do you use for “Job Duration”. WSJF works within the timeboxes because the timeboxes constrain the work items to fitting within the timebox so you’re comparing roughly similar sized items, but with Epics the Return-on-investment for a Horizon 3 opportunity could be years away, it will never win at WSJF. Trying to game the WSJF can cause problems as people try to slice up Epics they run the risks of the slices not being a viable change in their own right.
For a deep dive into the challenges of using WSJF, start here.
Do you have tips & tricks for making high level estimations for the cost versus benefits analysis?
All estimation is comparison against things that have been done previously. This is also true of Portfolio estimation, compare against work that has been done previously. Many organisations do the same thing time and time again, the next iteration of a product, another block of regulatory rules to fulfil. Compare that against what has been done previously, use the actuals from those previous endeavours. Even if it was a Project rather than an Epic that will still give insight into what was spent, the effort involved and the results obtained which can inform forwards.
The estimates in the benefits analysis are really only used for the Approval decision, if the Epic is approved then the Business Outcomes take over, these are the measures as to whether the Epic is successful. If the Epic’s features are still being prioritised by the WSJF and it’s moving towards it’s Business Outcomes then the Epic should be allowed to continue. Does it matter whether it’s over or under it’s estimated costs? No. The WSJF is showing that it’s Features are still the most valuable things to do, as long as it’s making progress on it’s Business Outcomes it should be allowed to continue.
I serve in a Fortune 100 financial services company which is not public. We are in a highly regulated industry. There is a cultural issue in our context where our Board of Directors and execs want 3-5 year rolling wave planning where benefits and budget are locked in as commitments. Not very lean. Where can you restart, reframe the convo to create mindset openness? Impermeable mindset seems to rule and reign in my context…
Roadmaps themselves aren’t wrong, they are useful artefacts to help reason about what might be coming up in the future so that we can answer the question “do we need to do anything in the current Planning Interval to support that future?”. They are also necessary for forecasting, you need to know what’s coming up to be able to understand whether you can hit dates and deadlines in the future. They are useful for communicating a vision for where the organisation wants to be going in the future, that vision is vitally important for allowing SAFe Principle #9 : Decentralise Decision Making.
The problematic behaviour is trying to lock the roadmaps down as commitments, especially if the roadmaps contain the detail of what is expected rather than just the milestones and target points. The questions to pose back to the leadership to get them to understand “Can you really predict what’s going to happen in the next 5 years? Do you really believe that locking the roadmap down is going to stop the world imposing upon you?” The next topic to explore would be “What do you feel committing the roadmap does? What benefits does it give you?” There will be a reason why they’re trying to lock it down, if that need can be uncovered then there is a possibility of finding a different means through the Lean/Agile methods to fulfil that need.
I’d guess that they’re worried that things won’t get done, deadlines won’t be achieved. Unfortunately, locking the roadmap down is “false positive feasibility”, instead replace it with repeated forecasting, every PI calculate whether the work that needs to be done to achieve a deadline is achievable by the deadline given the current knowledge, through the roadmap, of everything else that’s going on. If the answer coming back from the forecasts is “no”, or “it’s a little too close for comfort”, then that is a trigger to do something about it now, move irrelevant work out of the way, secure more funding, more capacity to devote to this deadline, do something about it now whilst there’s still time because if you wait until the deadline before realising there’s a problem, it’s too late.
Are there any other reasons why they want to lock things down? Sometimes the process of reaching agreement is so painful that they’re trying to avoid doing it on such a regular basis. The real fix is not to extend the period at which the roadmap is assessed and locked, but to improve the means of constructing the roadmap so that it can be done quickly and easily. Here is a series of blog post on some observations on Portfolio Roadmapping.
We don’t have Lean Portfolio Management nor have adopted SAFe in a good way. We still have projects and funding them on portfolio, and we have some ARTs, but not all projects go through the ARTs. Currently, we say that projects translate to Epics which SAFe specifically explains are not same. Any thoughts about this situation?
Whilst Value Streams should be the preferred method of funding in most IT organisations that look after long-lived solutions, there is always a possibility that a project is actually the right tool. The Portfolio is separate from the means to get work done, as long as it can invest in something, negotiate work into that thing and receive value back, then what the thing is doesn’t matter. It could be a value stream, it could be a project, it could be purchasing from an external party. The only time the Portfolio needs to care about how things get done is when it is setting up the structures for getting things done, if it chooses the wrong structure for doing things then it won’t see optimal results.
The challenge with funding the work, i.e. Projects, is that once the work gets it’s hands on the money it becomes selfish. The work will quite happily build it’s nice-to-have functionality whilst elsewhere valuable work isn’t being done because it’s doesn’t have access to the funds. The portfolio is chasing the money, rather than chasing value. By funding the people you take the subject of money off the table, the question then becomes “what’s the most valuable thing to do, i.e. which Features, with the capacity generated by the investment in the people, the ART?” The organisation is chasing value. This is important because the nice-to-have Features of the high priority Epic might not be as valuable as the must-have of a lower Priority Epic but funding the work itself is liable to put you in a situation where you can’t make that differentiation, you’re forced into doing the less value features because they have the money.
As discussed in the earlier question, projects are not evil despite what the majority of the agile world seems to say, they’re abused. People use projects in the wrong situations and wonder why they’re not working. Don’t fund the work, the project, when you have long lived solutions because the work is transient, it ends, what’s supporting the long lived solution once the work has ended… oh we fund another project to keep it going! Does it not feels like the wrong tool for the job? Projects are all we know! Then let me introduce you to Value Streams…
Done with reading through the Questions & Answers? Go back to Writing Better Epics In SAFe by clicking here.