The Love and Lives of an Epic Owner - project manager % vs. Epic Owner (2024)

Article: The Love and Lives of an Epic Owner

The Epic Owner role is often wrongly misinterpreted as a project manager.

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 both the project manager and product owner.

So, how do you know you’re in deep sh*t

If you feel like this dog (quite unhappily dressed out), that may be your first hint. Or…

You are in deep sh*t when…

• You were a project manager and are 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 Programs or Agile Release Trains – within the given timeframe (wuuuuuuhu!). Or…
• You are running a project which is called an Epic. Or…
• You are appointed Chief Product Owner, and without any education are requested to just Go-Do, and let the agile teams do everything themselves, because they will send you progress reports. Or…
• If a Steering Committee ask you to deliver frequent status as activity reports with detailed data that you cannot get from the Program or ART’s agile teams (because they work agile and are measured on delivered working software!). Or…
• Your organization tell you that a Portfolio Layer (e.g. in SAFe or other frameworks) is taken in use, but with no Lean Portfolio Management or similar – 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 the organisation’s Portfolio Layer/Circle. This is especially important to remember in the SAFe framework.
• Epic Owners deliver value by enabling fast flow and deliver frequent customer value due to lean processes, fast decision making and high empowerment with trusted and motivated colleagues. In SAFe this is done in co-operation with Agile Release Trains. In Agile Lean Leadership this is done using the Scaled-up Circle.
• The Epic’s Lean Business Case includes the expected high level features and provides enough data for Lean Portfolio Management or similar to give a Go/No-Go (if required) for moving the Epic to execution mode – but not until the agile team(s) have enough capacity. In SAFe this is visualized on ART’s Program Kanban, and other frameworks have similar ways to visualize this in order to display full transparancy.

Let’s be crystal clear:

• We don’t need Steering Committees for Epics (why would we?). This goes for all frameworks in any scaled set-up.
• 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 SAFe ARTs or similar set-up they keep funding projects.

…this authority also keep steering Epics as if they were projects.

There are good reasons why e.g. scaling frameworks and Scrum does not include a project set-up!

Projects in a SAFe or Scrum 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. Nor in Scrum.

Everyone are hurt by projects in SAFe or a scaling framework: The Epic Owner, the Release Train Engineer, the Product Manager, the whole agile team including the Product Owner.

In fact agile projects executed in scaled agile set-up’s slow down everything – including the healthy processes used.

Projects are simply not part of agile scaling framework and they ruin the much wanted flow.

Use those frameworks for what it is designed for! THEN harvest the profits.

Should we abandon agile *projects*? (Nooooo!)

Agile *projects* (run outside the scaled context) are sometimes fine.

Agile *projects* using Scrum Teams to deliver the outcome sometimes just cannot be avoided in an organization. If that is the case the Agile Lean Leadership framework (ALL) hints how -> by using a special kind of ‘Scaled Up Circles’ (i.e. small agile network of teams).

Agile Projects need to have well designed milestones or steps (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. At Agilit we teach you how to convert projects into Epics and deliver via small agile networks of teams.

Free Epic Owner Secrets Poster:

.

Download the poster here.

.

.

.

..

But, before you set up an agile project/Epic we recommend to investigate if there could be an alternative way, so that you achieve a higher throughput, faster decisions and more flow.

There is nothing wrong with healthy set-up agile projects

• But there is a huge problem with running a project 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).

BUT on the other hand: Projects add overhead

Traditional organizations manage development as projects or programs—big projects. Projects have clear start and end dates, clear scope. People are allocated to them for a predetermined amount of time. Budgets are decided by the expected value of the predetermined scope. This leaves little room for responding to changes. Myriad and varying projects cause complicated project portfolio management to synchronize the re-allocation of resources to projects. Source: The Less company.

And the founders behind The Less Company continue:

LeSS organizations* manage development as products. Products have a clear purpose but no fixed end or scope. People are allocated to them for an undetermined amount of time. Budgets are decided by potential value without tying it directly to a specific scope. This leaves lots of room for responding to change. A product is continuously developed and therefore a regular rhythm of re-allocating the people to products will suffice. Complicated project portfolio management disappears.

*) i.e. networked organizations

Stay tuned …

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?

Next…

Where do my Features come from?
When should Epic Owner hand over Features to the ARTs?
When will the agile teams deliver my Features – and how will I know?

Download Epic Owner Poster

Get dates for the next Epic Owner training

Read more and sign up for Epic Owner education

Read more about AgiliT’s Services

Share this post. #TheLoveandLivesofanEpicOwner