When Is An Epic done?
“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.
Please also see the free upcoming webinar based on this blog content!
Epics : When is it done?
The previous post looked at How Epic Get Things Done, this post will cover When is an Epic done? Which is interesting because there is no Definition-Of-Done for an Epic.
It’s either successful in meeting its Business Outcomes or it is abandoned.
Fig 1: Epic either achieve Success or are Abandoned
One of my biggest complaints about the SAFe Portfolio Kanban is it’s use of the word Done rather than Success. It is a minor complaint in the grand scheme of things, it’s not like it’s a structural deficiency in the process, it’s just a word. But words are important, words have meaning, and the meaning of Done is different from Success. Done implies work has been completed, but has the work that has been completed achieved the bigger aims? Maybe, maybe not. Use of the phrase Done can lead people to thinking about just the doing of the work rather than has the work been valuable?
I would argue that the one thing that differentiates a Lean Portfolio from styles of Portfolio that have gone before is its explicit aim of chasing value, that is the goal of Lean after all “Value in the sustainably shortest lead time”.1 Any Portfolio instantiation that isn’t chasing value can’t claim to be a Lean Portfolio. The old world was often about checking that progress has been made, that work was being done, and whilst changing one word to be “Success” isn’t going to change the behaviour of a whole company, it is one step of many in the right direction, it sets the correct tone to help the Lean Portfolio focus on achieving Value.
Definitions-Of-Done
Most Agile practitioners think in terms of Definitions-Of-Done for the work items in the backlogs, Stories and Features, with another for Releases. A useful simplification, but not entirely correct.
The Definitions-Of-Done in SAFe aren’t attached to the work items at all but instead described as Team Increment, System Increment, Solution Increment and Release; which is still a mess of different dimensions as Team is an organisational structure, System and Solution are things a Development Value Stream produces and Release is collection of changes to a System or Solution.
The Definitions-of-done all belong to the System or Solution and represent Deployment, Internal Release and External Release. Stories get deployed, Features get released internally and sets of Features get released externally. In some environments the set of Features being released externally might be a set of one, in which case the internal and external release Definitions-of-Done collapse down to become the same thing. They need to be kept separate within these generic descriptions because there are still situations, typically regulated, life-critical systems, where external release is different from internal releases because it contains additional checks that can only be done on a Final Release Candidate. Those final checks are often monetarily expensive because they involve external parties which means it isn’t economically viable to release individual Features. Also, regulatory bodies typically aren’t set up to process release requests at the rate of individual Features and are likely to react badly if you tried to attempt such frequent releases; this forces organisations in batching Features into a Release. It’s important to understand that this is occurring dure to external influences rather than internal deficiencies, internally the product is always kept in a releasable state. If you consider the regulatory body to be a “customer”, which they are in a lean sense because they are the recipient of the teams outputs, then they “pull” the work at a rate that they can handle.2
The cheat that regularly occurs with small scale Scrum is that the team is said to own the Definition- of-Done, in truth the Scrum Guide says the Definition-Of-Done describes the quality for an increment and the increment is a change to something, typically a System. The cheat occurs because in small scale Scrum the team owns the System and therefore everything owned by the System is owned by the team, giving them free will to change the Definition-Of-Done as they see fit. As the number of teams working on a System is scaled up, that cheat ceases to work.
All teams working on a System need to be following the same consistent Definition-Of-Done that applies to that System and therefore it should be owned by the System. The teams can’t make individual changes to the Definition-Of-Done, as that would mean that the changes that the different teams are making changes to the shared System that have different levels of quality, when that quality should to be consistent across the set of Teams. If the Definition-Of-Done does need to be changed, then it has to be done as a collective; within a SAFe context this would normally be organised by the senior technical representative on the Agile Release Train, the System Architect. Quality is a technical concern, therefore it falls under the System Architect’s sphere of responsibility.
Whilst the System Architect may be accountable for ensuring that the Definitions-Of-Done exist, the development of them can be a collaborative effort involving representation from the teams and elsewhere in the organisation. Security, Compliance, Regulatory concerns, these also fall within the Architectural sphere, although the detail is often delegated to individuals with the required specialist knowledge and their input can be fed into the Definitions-Of-Done.
That the Definitions-Of-Done are being followed is a procedural issue, this becomes the accountability of the facilitators, the Scrum Masters and the Release Train Engineer. That the Definition-Of-Done is being followed correctly is back to being a technical concern, therefore the engineering team have to be accountable.
|
Why the Definitions-Of-Done should be aligned with Systems, Solutions or their component parts Consider a properly Stream Aligned, Cross-Functional team working on a large solution, made up of a number of components. One story within a Feature has them working on the back-end database, the checks and balances within the database’s Definition-Of-Done would be focused on “is the database being used correctly?” The next story that the team works on is the front-end smartphone app, the checks and balances within the app’s Definition-Of-Done would be focused on using the correct style guidelines for the controls and “does the coding conform to the Smartphone’s App-Store policies?” As the team moves across the component landscape within the solution the team needs to honour the individual component’s own Definition-Of-Done. |
Epics Are Business Change
Epics are Business Change, not work. In order to enact the business change they generate work, by negotiating Features into Agile Release Train backlogs which eventually become Stories in Team backlogs through PI Planning which triggers the team to do some work, but Epics are not work themselves.
Business Change, true business change as measured by the bottom line of the accountancy spreadsheet , doesn’t occur when the work is done often it lags behind the doing of the work.
There will be a stage where the Epic is no longer negotiating work directly into ART backlogs and any future requests need to be handled either as defects if it’s broken or small change requests coming from the ARTs own personal capacity reservation. Can the Portfolio stop looking at the metrics? Can it walk away from understanding whether the change that it has instigated has been successful? I would argue that it can’t, therefore the notion of the Epic no longer needing Portfolio Visibility is also incorrect. Visibility stops at with the declaration of success or abandonment. What the Portfolio is no longer doing is negotiating work explicitly into the backlogs.
Epics don’t do releases, they trigger Systems/Solutions to create releases by requesting changes to the System/Solution through Features; hence the checklists DoD’s, live with the System and Solutions. There is no Epic DoD.
Even if the Epic is abandoned, the System/Solution still exists and may persist. Any subsequent changes, whether they relate to changes made by the abandoned Epic or not, need to conform to the relevant Definitions-of-done for whatever is being manipulated. This is just another argument as to why the Definition-of-done belong not to the backlog items but to the artefacts being manipulated at the request of those work-items.
Success is not Done, despite what the official Kanban says. It’s business change.
Don’t think of an Epic as done when the work is done; success lags. Might need to adjust the Kanban so have a stage between Implementation and Success, where Implementation is over but Success is still building.
Business Outcomes Are Everything
The metrics behind the Epic, the Business Outcomes and Leading Indicators, are therefore key. The Business Outcomes provide measurements that the change has happened, and the Leading Indicators provide measurement that the change looks feasible.
Whilst many people focus on the words of the Epic, the real focus should be on the metrics because they are used repeatedly, every Planning Interval, to prove that the Epic has made progress and should be allowed to continue consuming resources.
As described in the blog on Portfolio Events, those metrics are used every PI to decide whether an Epic remains active. Anything that isn’t achieving the expected value should be stopped quickly to minimise the losses.
Conclusions
Business change is either successful, or it fails. Whilst the work can be “done” that’s not what the Portfolio should be tracking, it needs to focus on the Business Outcomes that define whether the
Next Steps
May organisations that are adopting SAFe for the first time will be in a position where they need to take old-world project structures and convert them to the new Agile artefacts; the next post will look at practical tips for how to Transition from Projects to Epics
#1 The goal was more explicitly stated in versions of SAFe prior to 6.0, the goal is still present in 6.0 but is implied through Diagram 3 on the Lean Agile Mindset page.
#2 In truth, the organisation will need to prompt the regulator to “pull” the work, they won’t do it naturally but it’s being driven by the pace of the regulator not the pace of the organisation.
I hope that illustrates How Epics Get Done; watch out for the further blogs on Features and User Stories!