Article: The Love and Lives of an Epic Owner (#2)
The Epic Owner role (SAFe) is often wrongly misinterpreted as a project manager job function.
It is the least described and most misinterpreted of all agile roles!
This can be crucial for Epic Owners. How come?
The Epic Owner uses different tools than the project manager.
So, how do you know you’re in deep shit
If you feel like this dog (quite unhappy), that may be your first hint. Or…
You are in deep shit when…
- You were a project manager and is now called Epic Owner. You are asked to create a Gannt chart with a Feature Roadmap that you guarantee to deliver on time via your company’s Agile Release Trains – within the given timeframe (wuuuuuuhu!). Or…
- You are running a project which is called an Epic. Or…
- If a Steering Committee ask you to deliver frequent status as activity reports with detailed data that you cannot get from the ART’s agile teams (because they work agile and are measured on delivered working software!). Or…
- Your organization tell you that SAFe’s Portfolio Layer is taken in use, but with no Lean Portfolio Management – and all projects work with same (high) priority scope
I think you get my point, but read on for a quick recap (or just skip this):
- Epic Owners belong at SAFe’s Portfolio Layer.
- Epic Owners deliver value through ARTs by enabling fast flow and deliver frequent customer value due to lean processes, fast decision making and high empowerment with trusted and motivated colleagues.
- The Epic’s Lean Business Case includes the expected high level features, and provides enough data for LPM to give a Go/No-Go for moving the Epic to one or more ART’s Program Kanban for execution when the teams have enough capacity.
Let’s be crystal clear:
In SAFe we don’t have Steering Committees for Epics (why would we?).
- Gannt charts are not needed: The highly visible Program Board for the next 3 months (app.) and the agile teams’ Sprint Boards clearly show what is in progress. You even have them digitalized 🙂
- The value of Products to be delivered is described in the Features. THAT goes into your progress reports.
- At the end of each iteration, value is (probable to be) delivered, given we have sliced the Stories appropriately.
- The rest of the ‘plan’ – i.e. the Feature Roadmap – is still a hypothesis, not a guaranteed plan promised to be adhered to by the Epic Owner (at least that is not my invitation to you).
You should therefore be on red alert and take care of yourself in your role as Epic Owner when…
… someone wish the company to get the same agile benefits of your Epics executed in a waterfall’ish plan-driven environment, and instead of funding the ARTs they keep funding projects.
…this authority also keep steering Epics as if they were projects.
There are good reasons why SAFe does not include a project set-up
Projects in a SAFe set-up slow down time to delivery. Projects in SAFe hurt people and steering committees, since there are no built in processes in SAFe for delivering projects.
Everyone are hurt by projects in SAFe: The Epic Owner, the Release Train Engineer, the Product Manager, the whole agile team including the Product Owner.
In fact agile projects executed in SAFe slows down everything – including the healthy processes used in (healthy) SAFe implementations.
Projects are simply not part of the Framework and they ruin the assumed flow in SAFe.
Use SAFe for what it is designed for! THEN harvest the profits.
Should we abandon agile *projects*? (Nooooo!)
Agile *projects* (run outside the SAFe context) are just fine. They need to have well designed milestones (otherwise there is probably no rational for running the initiative as a project), and agile projects can easily be set up to deliver value and Products at frequent intervals. E.g. GoAgile can teach you how.
There are no problems with healthy set-up agile projects
But there is a huge problem with running a project in SAFe and then believe it automatically becomes an agile project!
Recall that the closest we get to the term ‘program’ in SAFe is the “ART” (which we all know is not the same as a traditional Program).
Stay tuned until next week…
Next weeks we will elaborate more on the Epic Owner dilemmas and ask questions such as:
How do I overcome all these dilemmas that are burning me out as Epic Owner?
How should I react as Epic Owner If I am asked to run projects in a SAFe organizational set-up?
Can I nudge decision makers into moving towards a more healthy Epic execution set-up?
Where do my Features come from?
When should I hand over Features to the ARTs?
When will the agile teams deliver my Features – and how will I know?