Epic Failures and a couple of successes too

This page provides a summary and recap of the Webinar: ‘Epic Failures and a couple of successes too, Patterns and anti-patterns in Lean Portfolio Management’, that took place on the 12th March 2025. It contains a video replay for anyone who missed it plus a transcription of the voice-over for detailed study. We hope you find it useful.

• View the 1st Webinar in the series: ‘Practical Lean Portfolio Operations’ Webinar Replay Video here!

Webinar Synopsis

Epic Failures and a couple of successes too, Patterns and anti-patterns in Lean Portfolio Management.

Many organisations now understand they must change how they plan and fund strategic work – if they wish to make the most of the agility of their software & hardware development teams. But there are many traps and challenges which must be avoided by the Lean Portfolio Management team as they embark on this journey. Over the years, IJI has helped many companies establish and run successful Lean Portfolios. Join us in this webinar where we will describe some common patterns to adopt, and anti-patterns to avoid, on your journey towards a lean portfolio management.

Webinar Replay

Epic Failures and a couple of successes too, Patterns and anti-patterns in Lean Portfolio Management held on the 12th March 2025.

We hope you find the content useful and please do not hesitate to contact us if you need any help with your SAFe implementation.

Video Transcript

(best read whilst reviewing the webinar slides… download them using the form below)

Introduction

The terminology that I’m using today is aligned with the Scaled Agile Framework, but, as always with Lean Portfolio, the insight in today’s presentation, is delivery methodology agnostic, the Portfolio doesn’t care how delivery gets done, just that it does get done and done in an efficient way.

Please join me for an irreverent and mildly humorous look at how Lean Portfolio Management can go wrong.

Wheel: Supertanker

Roll-up, roll-up, let’s spin the wheel and see how our Lean Portfolio is going to fail today! What’s it going to be, bag-of-bits, two-for-one, it’s SUPERTANKER!

Supertanker it is then…

Right, straight into the next game, choose how you fail…

Failure is inevitable, the question is how do you want to fail? Do you fail fast? Do you fail slow? Do you fail by spending all the money? Do you fail by not spending all the money?

So many choices… what is it to be?

• Burn all the money slowly, it’s a long agonising death that everyone can see coming, but nobody can do anything about. You fail, painfully.
• Burn all the money fast, that much money being burnt so quickly, it makes the evening news, they’ll be using you as case studies on MBA course for years to come. You fail, spectacularly.
• Burn some of the money slowly. There is money left but it’s too late do anything with it. You fail, with lingering regrets of missed opportunities.
• Burn some of the money quickly. There is money left and there is still time to do something with it. You’ve failed, but you get another chance to pursue another opportunity…

Those are your options, which are going to pick? Fast or slow, all or some? What would you choose?

What’s it going to be? It’s burn it all and burn it slow!

Your personal choice of failure never had a chance because it’s being dictated by the processes and culture of your organisation, and you probably don’t have the right processes or culture!

Supertanker - Crashing

Because, once your organisation sets something in motion it’s moving and it won’t stop.

Perhaps now would be a wise time to pivot?

No!

Even when the facts state that this course is wrong, we’re carrying on regardless…

…to our doom.

Supertanker – Symptoms

Observable symptoms? Every Epic is approved. No Epic ever stops early. No Epic is ever cancelled. The scope of an Epic never changes; there is no adjustment based upon customer feedback; everything that was agreed at the start must be completed by the end.

Supertanker – Possible Causes

Is this because your organization is still treating Epics as stage-gate projects, perhaps to satisfy other stakeholders? Is Lean Portfolio Management, the executives, the decision makers, are they not embracing or encouraging the lean-agile principles within their organisation? Have the Business Outcomes of the Epic not been identified? Can progress only be measured against features delivered – not their outcome or impact?

All of this points to the Epic feedback cycle being missing or can never be utilised because the necessary measurements aren’t present. This results in the organisation doing work that isn’t the most valuable thing they could be doing. Thus, they don’t generate as much value, in many instances value eventually translates to money. They didn’t make as much money as they could have done.

Supertanker - Remedy

How you turn your Supertanker into a highly responsive speedboat?

Think Lean Startup and apply the Minimum Viable Product concept, MVPs, so that the results affect the progress and scope of the Epic.

Now, MVP is an acronym that is thrown around with wilful abandon and very few people understand what it actually means. What’s the minimum you can do to prove the viability of the hypothesis, the idea for the product. It’s not the minimum set of functionality that you want to release, that’s a Minimum Marketable Release, an MMR another three letter acronym to throw around will wilful abandon.

Everything in business is an experiment. The management don’t like hearing that but deep down they know it’s true; they just want to believe that things are simpler than they are. You don’t know whether an idea, a hypothesis, is going to work until you try. The early experiments, give insight into whether to continue. If the answer is no, cut your losses. Don’t see cancelling an Epic early as failure, see it as saving the organisation from wasting money on an idea that wouldn’t have worked, celebrate that. Whereas if you cancel late, once you’ve done development, you will have wasted money and there is every likelihood that you’ll fall into the sunk-costs trap which can see you carrying on regardless and just incurring more loss and more waste.

Don’t throw good money after a bad idea.

Review your epic lifecycle process to ensure that the feedback cycle is working properly:

Decisions to commit to the epic should happen as part of the epic lifecycle, not before it starts. All ideas should be welcome into the Epic Approval process, but expect to turn some away if their hypothesis doesn’t align with the organisational vision.

MVP is an experiment to confirm if you should persevere and deliver a product later on… MVP is not a product. The Leading Indicators in the hypothesis are the measurements, the early experiments that the Epic needs to perform to understand whether the hypothesis is valid.

Ensure that stakeholders understand that epics can “stop early” – & fall off the portfolio kanban system. The portfolio kanban is not a queue, it is a ruthless system that is trying to kill anything that isn’t valuable, remember the goal of Lean is Value in the shortest sustainable lead time. If the leading indicators say no, kill it. If the business outcomes aren’t progressing as expected; kill it. Stop wasting your money and find something more valuable to pursue.

Then apply the process! Use the process, every timebox, every Planning Interval, to inspect the metrics for every Epic in play and decide whether to continue. This is the point of engagement for the Lean Portfolio Management, the decision makers, this is how they can influence what’s happening, the Epics that are in play.

For more insight into how decisions affect the progress of an Epic, follow the QR code to previous webinars and blog posts on Decision Making within the Portfolio Kanban.

If you Fail fast, with money to spare, you can pursue the next opportunity.

Wheel: Hidden Hand

Next opportunity, next chance to fail, so let’s spin the wheel!

What’s it going to be? Where’s it going to land? Oooh - It’s Hidden hand…

Oh great Portfolio Management, we need a decision, tell us what we should be doing?

Um, yes, one moment, I’ll just need to check…

When shall we three meet again?
In thunder, lightning, or in rain?
When the PI plannings done,
When the commitments lost and won.
That will be ere the set of sun.
Where the place?
The exec board room.
‘Ere portfolio come to genuflect.

We observe a portfolio unable to make immediate decisions, usually because they are not empowered to make decisions; a hidden hand somewhere behind the portfolio is really in control.

Hidden Hand - Symptoms

How does this manifest, not three crones talking in iambic pentameter, but the Lean Portfolio processes whilst apparently running, aren’t making any decisions, the decisions are being made elsewhere.

One observable symptom is decisions being made but changing shortly afterwards when the hidden hand decides what the right thing to do is. This can result in wasteful work, work towards the original decision that has been done, but is then invalidated when the decision that was made was not what the hidden hand wanted. Wasteful work has consumed effort that could have been used elsewhere, so it’s delaying the delivery of useful value. Doing work that is subsequently discarded damages morale and causes people to question whether the processes are really working, which in turn has a long term impact on the sustainability of the processes.

Another observable symptom is that decisions cannot be made immediately, they need to be taken away and responses are communicated later. All of this results in delays, which can also impact commitments if you need to make a commitment before the response is received. Commitments being broken will show up in the predictability scores.

• Delays to gaining clarity.
• Delays to resolving impediments.

Any delays in the decision making in the Portfolio will result in delays to delivery, delays to realisation of value and ultimately delays to earning cold hard cash!

Hidden Hand - Possible Causes

There are a number of possible causes as to why this might be happening. If the Lean Portfolio cannot make decisions itself then you have to start asking why?

Does the Lean Portfolio include the senior stakeholders who commit to new strategic work, and can stop work? If not, why not?

Are these Senior stakeholders unaware of, or not wanting to participate, in Lean Portfolio Management? Do legacy processes still exist for controlling strategic work, so the Lean Portfolio processes are now running in parallel with legacy processes and therefore the Lean Portfolio is ineffective as a result?

Has the old PMO established itself as the decision makers within the Lean Portfolio? Do they have the authority to make decisions? Are they acting as middlemen and slowing everything down? Should they really be the facilitators, the VMO?

Hidden Hand - Remedy

Clearly - this problem can only be solved by encouraging the true decision-makers to embrace the new way of working. If they decided not to be part of the Lean Portfolio Management process, then why they decided not to be part of the Lean Portfolio Management process needs to be understood. Then remedies applied to that - to convince them to change their original decision.

Perhaps they perceive Lean Portfolio Management as too much overhead, which it can be if the events are improperly instantiated. For more insight into the events that operate a Portfolio follow the QR code.

What are the explicit touch points for those decision makers? Deciding on the vision and then deciding on the Epics that should realise that vision, both of which happen just once per Planning Interval.

Could they be involved elsewhere? Should they be involved elsewhere? Yes, and they’ll need to be, but the Vision and the set of active Epics, those are the decisions that they have to make, and only they can make.

Do not let Legacy Processes and Lean Portfolio Management try to control the same piece of work. There will be work that organisations have to undertake where the legacy processes are the right fit so an organisation needs to be capable of running both the Legacy processes and the Lean processes in parallel, at the same time, but the processes are separate and work uses one process or the other. Do not let one process try to control the other process because that is duplicating effort and that is where the conflicts and delays lie. Avoid the processes fighting at all costs, because the incumbent process, the legacy process has the advantage and when it wins the agility of the teams and trains below will be irrevocably compromised.

Wheel: Two-for-one

Back to the wheel, what lucky means of failure will we experience next.

And it’s slowing, it’s slowing… It’s two-for-one!

One of my favourites. Common misunderstandings can have grave consequences within the Portfolio because the Portfolio is different from the delivery Teams and Trains.

So the business has decided that it wants to do an Epic and engineering comes back and says, “great, but we’re going to have to do this first…and sticks an enabler Epic in.

The business comes back and says they’d like this instead; and engineering says sure and sticks an enabler in.

Every single Business Epic has an Enabler Epic preceding it. This is wrong but it’s a subtle wrongness that many people don’t understand because Enablers themselves are misunderstood.

What is the business case for the Enabler? The business case for the enabler is that it allows us to do the business Epic? The Business Outcomes for the enabler are actually the same as the Business Epic, it’s enabling you to reach the same Business Outcomes, the business case is going to be the same.

So why does it need to be split out? It’s not like Epics are bound by the time-box, they can spread across multiple Planning Intervals, there is no pressure to slice the Epic to fit within time-boxes. If preparatory work is needed then it can be done as part of the Business Epic, if you need to make it explicitly visible then preparatory work can appear and be measured as a Leading Indicator.

Two-for-one - Symptoms

If every business epic is preceded by an associated enabler Epic, then there will be a high volume of epics passing through Lean Portfolio Management causing an administrative burden. This will manifest as observable stress around preparation of Epics.

Look at the Epics being prepared, do multiple Epics share the same business case? Are there dependencies between Epics? Problems can arise managing dependencies between paired-epics, in that if the Enabler gets done but the paired Business Epic does get done is there any value? Has it just become waste?

Is the Business complaining that delivery takes too long? This can happen when there is a focus on getting the Enabler completed before starting the Business Epic, an implicit queue has been created, rather than focusing on getting to Business Value as rapidly as possible and doing just enough to make that happen.

Two-for-one - Possible Causes

How does this arise?

I’ve seen organisations imposes a maximum size for an Epic, in a mistaken attempt to get things done quicker. The ruling is arbitrary and doesn’t consider the scope of the Epic, nor that often the external changes are outside of the Epics hands, the customers change in their own time. This can also arise from a mis-reading of SAFe’s Business Agility Value Stream diagram that says “Two to six months to Minimum Viable Product” : it means proving the Epic hypothesis within 6months, not completing the whole Epic in 6months.

Epic owners or Lean Portfolio management might not understand that an Epic can include exploratory and preparatory work as part of the Epic. If the Epic owner, the business, wants to do any of this they just negotiate a blue, business Feature into the backlog, the purpose of the Feature is entirely up to them, if they want it to be an experiment or preparation, then it can be an experiment or preparation. Try to reserve enablers for the team and trains internal capacity to do the things that they want to do, the self-improvements that are often identified through the Inspect & Adapt activities. It can also be a lack of confidence or acknowledgement that IT understands how to solve business problems, or understands the technology required for implementation, therefore they want the Enabler to help understand the scope of the challenge. But, all of this can still be dealt with by the Business Epic, the Epic should not be an imposition on the teams and trains but a negotiation and through that negotiation the teams and trains may identify that they need to learn, or up-skill on a new technology, and this should be factored into the Epic and become features flowing through the backlogs. There is no point an Epic Owner trying to fight this, If the teams don’t know then they will have to learn, so make it visible, honour that core value of transparency, factor it all in and just deal with it.

Another case could be an attempt to camouflage the bigger issue: that delivery is too slow to satisfy the business, so everything is chopped into 2 or more pieces to make it look like we’re doing more. But you’re not! At the team level improvement only comes from investing in team skills so that they can solve the challenges quicker and investing in their environment so that the continuous delivery pipeline is doing more of the menial work leaving the teams with more time to focus on solving the challenges quicker. Epic Slicing

Final potential cause is chasing metrics. I’ve seen people become obsessed with flow, and fast flow. They want every ticket to race across their Kanban boards, not realising that the speed you want is irrelevant, it’s the rate at which your customers want to take the product that’s dictating how fast the change happens. Carving things up into ever smaller pieces to make it look like things are going quicker doesn’t actually mean the change is happening any faster. If you want the change to happen faster, chase value, build valuable things that customers desire and want quickly and then the change will happen quickly.

Two-for-one - Remedy

How do we fix this, well…

Be disciplined and consistent in what categories of strategic work are treated as Enabler Epics vs Business Epics. I would suggest that Business Epics represent external change, typically resulting in increased revenue. Enabler Epics represent internal change, typically resulting in savings or that we can do more for the same cost.

Describe business outcomes for all Epics as true business results. For enablers this would be cost savings in real money, or a quantifiable improvement for the same money.

Grow skills and confidence to run and measure the results of experiments during a Business Epic to help identify ‘unknowns’ and deal with risks quickly and early. There are parallels here with the Supertanker anti-pattern and its associated remedies which relate to experimentation.

Investigate and resolve delivery issues to satisfy the businesses demand for shorter lead times. These are the internal work, these are the true enablers, the self-improvement identified from within. This is what the capacity allocation should be defending, the team and train’s ability to have time to self-improve, be it how they want to improve the product or how they want to improve the development systems and processes.

Preparation for a business request is still a business request; it shouldn’t be an enabler. Enablers are the requests from within, the self-improvement and that time needs to be defended. For more insight into Enabler Epics follow the QR code.

Wheel: Fractured

Time to spin the wheel.…and it’s settling on…

…Fractured.

A fractured Portfolio. You have a Portfolio, you are in complete control of your own destiny, you set your own vision, you forge your own path.

Except for that bit over there that, is owned by someone else.

You need that bit, and it’s not just a “we use it like we use Excel or Word” you need to steer its evolution. Except you can’t because you don’t own it. Your success, your job, your pay at the month end, all dependent upon a group of people that quick frankly “don’t give a damn about you” because they have their own priorities. And those priorities do not align with yours, no sir-ee, not in the slightest.

Your chances of success are low, you’re going down. Time to start polishing that linked-in resume, you’ll be needing it real soon.

Fractured - Symptoms

The observable symptoms are that a Portfolio needs to negotiate with other Portfolios in order to complete their work. Lots of negotiation, lots of arguing, lots of politics between senior figures.

End result, the portfolio is regularly failing to achieve its vision, and the excuse will always be “it wasn’t us, it was them!” Ah, the good old blame game, your grandmother probably taught you that one, alongside how to cheat at cards!

Fractured - Possible Causes

If the portfolio has been instigated too low within the hierarchy, perhaps because it’s been based upon historic interpretations of Portfolio which are based around collecting work together, then there is a significant likelihood that the Portfolio doesn’t own enough to fulfil its own destiny.

The rules for Portfolio differ from Teams and Trains. With teams the rule is “don’t scale”, try to do whatever you need to do with the smallest group of people possible. With a Portfolio, within reason, the rule is “bigger is better”, because being bigger gives more ability to self-organise, more ability to balance money and work across the set of people, more ability to spread the risk, failure of individual pieces of the portfolio doesn’t matter as long as enough of the portfolio is successful. The smaller the portfolio, the more that you are just the one thing, the more brittle the situation, one problem and everything can come tumbling down.

Another possible cause arises from contracting suppliers, and getting the wrong contract or relationship set up. You need whatever they supply but the contract hasn’t been set up so that you’re working towards a common cause.

Contracting is a very deep topic, SAFe’s “align everything with Planning Intervals” isn’t wrong, but it is just the tip of a very large iceberg. I’ve not written about the topic of contracting as part of the series of portfolio blogs that I’ve been writing. What I have done for clients is run a one-day training course on Agile Contracting, specifically targeting legal and procurement who need to know about Agile to write it into the contracts, without having to “do agile” in the sense that engineering teams “do agile”. Follow the QR code for a course synopsis and contact us if you’re interested.

Final potential cause is that the vision for the Portfolio is completely unrealistic. Now this can go two ways; the vision is perfectly rational for the organisation as a whole, but the Portfolio has been badly set up.

Or

The Portfolio is the best it could be, and the vision has been created without thought for the Portfolios abilities.

Bad setup we’ve just discussed, probably a result of the Portfolio being instigated too low.

Inconsiderate vision, likely to be caused by un-engaged senior management who are operating in isolation from the Portfolio that will deliver the vision; it’s the Hidden Hand scenario from earlier.

Fractured - Remedy

What are the remedies:

For a bad setup, re-assess the scope of the Portfolio. For more insight into Multiple Portfolios and why you probably don’t need them unless you really are a giant multinational with disparate businesses, follow the QR code.

The question to ask is: Why was the Portfolio instigated so small without all the required pieces? I suspect that it won’t be long before you hit politics. There is no shortcut here, you’ve got to sit everyone down together, understand everyone’s point of view, try to come up with a solution that satisfies everyone, preserves their dignity and prestige, even if they’re losing apparent control of people.

Those unengaged senior leadership? Assembling a bigger portfolio might actually get them more involved because it’s now operating at and encapsulating their level rather than being a small piece of the bigger thing that they care about. You might still need a charm offensive of training, coaching and support to get them to understand and engage in the right manner, but at least it hopefully makes more sense structurally.

Wheel: Square Peg

Spin the wheel, round it goes, where it stop nobody knows. …and… …Square Peg.

Square peg. What do you do when you have a square peg and a round hole?

Hit it. It will fit.

Especially if you hit it harder!

For many that embark upon an agile transformation Agile is the right way to do things, it is the one true way to do things it is only way to do things and all other ways of working must be cast down as the foul, blasphemous abominations that they are!

Err, yeah…. Calm. Please. Calm.

Square Peg – Symptoms

This mentality, the one size fits all mindset, can be problematic at the Portfolio level, because the Portfolio has to deal with a broad spectrum of work. Other ways of working might be more appropriate.

The observable symptoms are likely to be complaints that ways-of-working have been imposed, and they don’t fit the nature of the work being done and extra activities are needed to convert metrics and artefacts from one way-of-working to another.

At one level of abstraction, Agility, is just problem solving, that is happening regardless of any form of methodology, it’s what teams and individuals need to do. It is when methodologies are applied inconsiderately, and forced upon teams where the methodology isn’t appropriate, that problems start to arise.

Square Peg – Possible Causes

Agile evangelism does tend to emphasise a small, restrictive set of new processes, rather than matching the right process for the right type of work.

Some years ago, I was working with a middle eastern Airline and the question came up of what is the right way of working? answering that question resulted in this little quadrant diagram.

The horizontal dimension is the nature of the change. Is it discrete? A one-off change and there will be no further changes to the thing delivered. Or is it continuous change? This change is just one of an ongoing process of changing the thing delivered.

The vertical dimension is around the nature of the change. Has the problem of making the change been solved or not?

How did this apply to the context of the airline?

At the time I was working with them, they were expanding their airport, building a new terminal. The terminal once built is expected to provide sufficient capacity for the next twenty to thirty years. They are not planning to make significant changes to the terminal for the foreseeable future, effectively it is a one-off.

Designing the new terminal is problem solving, problem solving is best done in an agile fashion. I don’t think the architects and structural engineers would necessarily recognise or follow the agile processes that we are familiar with, but if you look at it in the abstract sense of solving problems, testing ideas, soliciting feedback, then agility is exactly what they are doing.

As a one-off it makes sense to manage it as a discrete endeavour. The airline doesn’t have architects and structural engineers on its payroll, and there is no point setting up long-term contracts for them, there is no work for them once the terminal is built. So, fund the change and get the change to employ them, i.e. run it as an Agile Project.

Designing the new terminal is one challenge, constructing it is another, and it’s a slightly different challenge. Here the problems have been solved, the architects and structural engineers have provided all the designs and the instructions for how it fits together. Just need to follow the instructions. Don’t deviate from the plan because deviation here is costly, the roof arriving before the supporting structure, is going to problematic.

As a one-off it makes sense to manage it as a discrete endeavour. The airline doesn’t have construction staff on its payroll, and won’t need them after the change has been made, so fund the change and get the change to employ construction staff, i.e. run it as phase gated project. Pro tip: don’t move to the roof phase until you’ve completed the supporting structure phase. Yeah!

Just because its a phase gated, legacy style, project doesn’t mean that there isn’t agility within it. Those builders will be problem solving at their level, how to get things done locally. It’s the macro level, the grand plan, that is more fixed, but even that will evolve as the reality of the situation emerges. The focus is on stability, change happens if the change is the most economically viable option.

As an airline they fly thousands of passengers around the world on a daily basis, the planes that they are flying need to be properly maintained, they need to be restocked with meals, baggage needs to be loaded, tickets need to be issued. Continuously. But the problems here have been solved, at least at the macro level, they know how to restock and refuel aircraft, they know how to issue tickets. If there are problems, there is usually a process to follow to fix them. Actually, that’s quite important when you’re fixing aircraft, you follow the maintenance procedures to the letter.

The people doing all of this are either directly employed by the airline or contracted-in on long-term contracts. The systems, i.e. aircraft maintenance, flight operations, ticketing, are all long lived; they’ve been in existence since the airline was first establish and they’ll be there until the end. Therefore, it doesn’t make sense to fund the individual changes, you fund the system and the people running it and then get them to run the system. This is operations, doing the same thing repeatedly without change. An operational value stream.

Finally, over time they need to change how they operate by changing the systems that support the operation of the airline. That change is continuous because the industry is never standing still, they are making changes to keep pace with the competition, they’re making changes to get ahead of the competition. Each change is a problem that needs to be solved, the answers need to be discovered.

This is systems development; it’s Development Value Streams maintaining and improving a system. Because it is continual change fund the people, pose them the challenge of what needs to be changed and let them do the rest. At the airline most of the software engineers were contracted in on long term contracts from the companies that supply the underlying systems, the product management, technical governance as in architects and facilitation staff were direct employees of the airline.

The Agile processes that we promote and encourage are just one part of a wide landscape, they are the right way to approach one particular challenge, system development, but the organisation may have other challenges where other ways of working are more appropriate.

The Portfolio needs to understand all ways-of-working, to extent that it can choose the most appropriate, the majority of the detail of each way of working can be decentralised to the experts tasked with running that way-of-working.

Square Peg – Remedy

The Portfolio should use the most appropriate process for the work being undertaken, therefore the Portfolio has to have the skill to handle every process, be it legacy or lean. The previous slide provides insight into which might be most appropriate.

The challenge for Portfolio is that managing the different processes can be hard, the remedy here is not to manage the different processes, but to decentralise the management of the processes into the processes. All the Portfolio needs is the ability to set the vision for the piece of work and receive metrics back out to demonstrate progress towards that vision. How the vision is achieved is up to the process and the people doing the process. Decentralise!

For more on practice independent measurement to allow decentralisation, follow the QR code to a webinar I did for Scaled Agile a few years back on this very topic.

Wheel: Bag Of Bits

Time to spin the wheel one more time…

What’s it going to be… Supertanker… yeah, erm, could some just give the screen a shove…

Splendid, much better.

I mean, we wouldn’t have got away with that in Vegas, but that little nudge gets us to…

…Bag of bits.

So we need to deal with this:

• One of these…
• Some of these…
• And this as well…

What do all of these things have in common?

Absolutely nothing. Nothing at all.

It’s just a bag of bits. Clue was in the title.

Why is the Portfolio asking the teams and trains to process a disparate collection of things?

Bag Of Bits – Symptoms

If an Epic is a collection of unrelated features, then the Lean Portfolio will struggle to articulate or measure a single set of Business Outcomes for the Epic. If you can’t measure then the Lean Portfolio will struggle to decide if an Epic has been successfully completed, or when it should stop.

Lean Portfolio Management discussions will tend to become very detailed when discussing Epics, they need to examine the detail because there are no higher-level measurements that can be relied upon.

Those discussions are likely to regress to discussing the cost of the Epic or the resources used to complete it, rather than its value because, again, value cannot be measured.

Bag Of Bits – Possible Causes

Why does this happen?

Business wants to micro-manage detailed work, i.e. features. For some reason it can’t or won’t decentralise decision-making about that work to Product Managers.

Epics represent cost centre “resources” owned & tracked by certain stakeholders, instead of strategic work which will change the business. i.e. they are still trying to “move people to the work.”

Lean Portfolio is struggling to describe the strategic work it needs to complete, or the strategic roadmap is not well defined, or there is insufficient stakeholder commitment to that roadmap. The roadmap is reactive, not proactive. This could be a Hidden Hand scenario.

Bag Of Bits – Remedy

Epics should focus on helping the business and its customers solve their strategic problems. Separate the tracking of work from the definition of strategic change and the outcomes of that change.

Both problems need to be solved don’t let the tracking of work overtake your focus on exactly what value an Epic will deliver. Value beats work.

Only the Portfolio can set the vision, the strategic change to the organisation; it is the centralised decision, everything else can be decentralised.

Use the guardrails to provide the teams and trains with local capacity to do what they need to do, the “bits” should belong to them. Empower the Product Managers to make local decisions about their product and reserve Epics for the organisational changes that need significant cross-organisational collaboration that would benefit from having a central point, the epic, for coordination.

Ensure you gain agreement about those guardrails amongst your stakeholders, communicate them to the delivery organisation and then track adherence regularly. Train, support and expect key roles in the teams and team-of-teams to be accountable for choosing and delivering features whilst adhering to the guardrails. For more insight into empowering the Product Managers follow the QR code to a webinar from last year.

There is a little homily that we regularly use to describe SAFe Principle #9 : Decentralise Decision Making, and that homily is “Centralise strategy, localise execution”. The strategic work is strategy, the guardrails are strategy to empower local decision making, they need to be defined centrally but the execution of the work and utilisation of the guardrails is decentralised out.

But…, every time you decentralise you must close the accountability loop, the portfolio needs to check that the decentralised decisions that the teams and trains have made are upholding the strategy; the feedback loops can correct any mistakes, but if the strategy is clear to begin with those mistakes will be insignificant in the grand scheme.

How do you close that loop? The vision must be measurable, measure progress towards the vision. If they’re not making progress towards the vision, then the Portfolio has to start asking why.

Conclusions

In Conclusion…

We have seen, through the anti-patterns, that it is very easy to compromise Lean Portfolio Management, and at this level mistakes can cost you the company.

A Lean Portfolio doesn’t behave like the Teams and Trains, it’s not a simple fractal scaling.

It doesn’t behave like historic Portfolios; it’s obsessive focus on value is not the same as just grouping work together.

Unlike the Team and Train levels, there just isn’t the body of knowledge to draw upon and some of the advice out there is distinctly suspect, even from “official” sources. If you’re receiving advice make sure that whoever is providing that advice explains the logic about what they are suggesting and then hold that logic up to the Lean-Agile principles. Never trust things blindly. Don’t copy what others have done unless you can prove through the principles that it is best-practice.

If you do want a good guide, we are available at very reasonable rates for the knowledge you’re drawing upon.

I need to thank my colleagues Keith and Ian for their insight and opinions over the years, and do remember that these are just observations and opinions, you might see other challenges, indeed whilst putting this presentation together I found three more that I could sensibly codify but “Forgot the Change”, “Give Me Everything!” and “Dark Work” will all have to wait for another webinar or blog post.

You might find other solutions to the challenges just highlighted. Spotting the problems is the first step, every solution will be unique we’ve provided some hints, you’ll need to adjust that for your particular scenario if you do find yourself in any of these situations.

---

Back to top>>