The Sisyphean Tragedy of Planning
Stop Trying To PUSH Rocks Up-Hill Like Sisyphus
Some teams do planning by taking into account team size, planned leave, holidays, training, shared resources or part-time contributors, historical velocity, fudge factors, velocity Monte Carlo simulations.
Dizzy yet?
👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.
Yet all this labor is completely futile and unnecessary.
The fact that you believe this is an effective approach is the very reason you will never reach your goals.
If you want to understand why this approach doesn’t work, all we have to do talk about the fate of our trusty old rock-pushing friend Sisyphus.
Meet Sisyphus.
If the name rings a bell, you probably know the story. In case you don’t, here’s a summary:
“Sisyphus was condemned to an eternity of futile struggle by the gods for outwitting them twice. His punishment was to roll a massive boulder up a steep hill, but just as he nears the summit, the stone’s weight becomes unbearable and it rolls back. This repeats ad infinitum.”
TLDR: Being Sisyphus sucks. You don’t want to end up in a Sisyphean tragedy, yet it’s precisely what most companies do.
The same Sisyphean rock-pushing cycle is precisely what’s going on in most organizations. We’re wasting our time polishing spreadsheets, improving estimates and perfecting fancy capacity calculations, just to PUSH a big boulder up a hill that keeps rolling back.
If you’ve got a fancy spreadsheet for velocity forecasting to plan your work, then you’re just like Sisyphus: you’re PUSHING rocks up-hill and you will never reach the summit.
Pushing Work to Roadmaps
Most companies have a ‘PUSH’ system for their roadmaps. Especially the kind of laggard companies that still use SAFe.
How does a push system work? As follows:
Companies that PUSH work rely on fancy spreadsheet magic to more accurately predict capacity and forecast estimated effort. Because their whole PUSH system hinges on the fact that the two should match: your forecasted capacity should be more than your estimated effort.
The problem with PUSHING work is that it only works if you can accurately forecast your capacity AND your estimated effort. When you’re doing Complex work, you will encounter so many surprises that neither will be ever accurate.
Hence the PUSH system inevitably fails. Like Sisyphus as you’re approaching the summit and exhausted from pushing the big rock, you’ll suddenly realize you won’t make it and the rock rolls back.
Everybody is disappointed and as long we stay in the PUSH paradigm, the end result will always be the same, like with an Sisyphean tragedy: the boulder is too freaking big.
If PUSH works for your team, that’s great! I’m happy for you, as your life is much easier than for teams doing complex work.
You don’t need Agile, you don’t need Scrum, and you don’t need SAFe either. You can travel straight to ‘Go’, collect 200$ and put some fancy hotels on Waterfall street instead.
What should we do if you want to escape this Sisyphean Tragedy? It’s pretty simple: stop PUSHING, start PULLING.
Look how much capacity you’re using and control for that based on the real-world effort the work you’re trying to accomplish seems to take.
What matters isn’t how much capacity you THINK you have, or how accurate your estimate WILL be. What matters is how much capacity you have and how much work it really takes. That’s what a PULL system helps with.
You’re pulling more work as more capacity becomes available based on THE REALITY OF THE CAPACITY and the REALITY OF THE WORK.
Instead of pulling a big boulder, you’re adding tiny rocks to the boulder as you’re pulling based on your experience how much work you are able to pull off.
When you PULL instead of PUSH, you can escape the Sisyphean Tragedy.
Escape the Sisyphean Tragedy: Stop Guessing, Start Pulling
Forecasted capacity and estimates are unreliable narrators. You can’t place your trust in them when you’re doing complex work. That’s why PUSHING never works.
The problem is that all our estimates are guesses we make at a point in time we lack information to predict accurately. We can’t trust our estimates because they suffer from the Fog of Beforehand - what we can know before starting the work.
What we can’t and don’t know before starting the work is what makes our estimates often explode and balloon out of control. And because we’re polishing our estimates and forecasts to perfection, we actually introduce the Fog of Speculation - over-fitting our plans to make them even worse.
In short, PUSH is the road to misery. When you PUSH work, you create tension between two systemic flaws that are not created equal:
Our inaccurate ability to predict our capacity
Our wildly inaccurate ability to estimate work
When you understand this well, this brings us to the heart of our Sisyphean Tragedy: capacity micro-management and obsessing over planning poker is the wrong way of approaching planning and indicates a profound misunderstanding of the real problem you’re facing.
The real problem is that our estimates can’t be trusted. We simply don’t know what we can’t know. That’s where the biggest variance comes from. You can’t control for this by PUSHING work.
The rock of Sisyphus is always bigger than we guess and would like it to be.
Stop guessing. Don’t turn your planning and roadmaps in a paper victory exercise that hinges on your inability to forecast capacity and sculpt perfect estimates.
Let the reality of the work dictate your planning. PULL work instead of PUSH.
PULL keeps your boots on the ground and allows you to get a good feeling for the true size of the boulder you’re facing.
PULLING is the only way you can escape the Sisyphean Tragedy of PUSHING work.
👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.
This all sounds very well but is written entirely from the perspective of efficiently managing the work itself. During the course of the piece you shift the time frame from being forward looking (a forecast) to being retrospective (actual capacity) without acknowledging the magnitude of this transition.
The list of stakeholders you've ignored in doing so is huge:
- Customers waiting on the feature/product you're building
- Sales and marketing efforts attempting to plan GTM and sales processes for it
- HR and team leadership trying to predict organisation-wide capacity deficits and manage hiring processes
From a pure engineering perspective, it's facile to suggest that waterfall is wholly inadequate to solve the *engineering problem* of delivering a product. But you ignore the wider business context in which this effort occurs in the first place. None of the engineers have salaries without an organisation that needs to understand what will be delivered, when, and in what state of quality. There can be flex on all of those qualities, but they cannot be a complete mystery until the product ships. There's no universe in which teams get to drop something like that – not for venture backed startups and certainly not for mature businesses.
All of which is to say, we will never escape the pressure to PUSH, no matter how much PULLing makes more sense for our personal needs as product teams. And nor should we. There needs to be some ownership and accountability for our future intention and how it aligns with eventual reality, otherwise we're all just hobbyist inventors.
This is really intriguing because I’m struggling to forecast estimated effort and it’s hurting my ability to roadmap and give cost estimates to client. I typically have a fixed staff (so assume fixed capacity).
I don’t understand what I change in the PULL system. Maybe it’s because in my agency, clients won’t accept starting work until we give them budget estimates and timelines and so are forced to go back to PUSH?