3 Things That Are Destroying Your Ability To Deliver On Time, Even When You're Already Agile
Picture this: A valiant software team, armed with the finest methodologies of the age (Agile, DevOps, Lean) sets forth on a noble quest: to deliver working software on time. They have battle-tested rituals (daily stand-ups), enchanted scrolls of wisdom (JIRA tickets), and even a mystical high priest known as the Scrum Master.
And yet, despite their best efforts, they fail. Again. And again. And again.
But why? Were they simply bad at Agile? Did they not follow the sacred rites correctly? Should they have sacrificed more story points to the Product Owner gods?
No, dear reader. The problem is far more sinister.
Our true adversary is not Agile or even Waterfall, but the very foundation of how we think about software development and knowledge work.
The entire intellectual framework that governs our field is riddled with hidden assumptions, outdated metaphors, and half-baked theories that refuse to die. We’ve inherited a deeply flawed belief system; one that has been leading well-meaning software teams astray for decades, much like like Victorians putting arsenic in wallpaper because green was a nice color. Aesthetic over survival, bold move!
This article is not here to tweak your Agile process. This article is here to challenge the very bedrock of how we think about building software (Agile or not). Using the wisdom of the ancients (because, let’s face it, most historical figures would have made hilarious project managers), we will uncover three invisible forces that are actively sabotaging your ability to deliver software on time.
Because if we can’t rethink the theory of software development, we’re doomed to keep repeating history, and to stumble forward with the same misguided principles, hoping that this time, maybe things will turn out differently.
So, buckle up. We’re about to unearth the root causes of delayed software, and we’re doing it with history, philosophy, and a touch of irreverent humor. Yes, because if we’re going to burn down some bad ideas, we might as well have fun doing it.
⭐️⭐️⭐️⭐️ This post is sponsored by The Global Agile Summit, where you can find the most advanced ideas on Software, Product Development and Agile! Join The Global Agile Summit, the most forward looking Agile event of 2025
The Illusion of Control, or How we Try to Outlaw Reality
Let me start this list of 3 things that are destroying our ability to delivery on time with a real-life example. It’s a fun one (for us, not for them), that I hope helps uncover an underlying dynamic that affects all software deliveries, whether we like it or not.
In the year 301 AD, the Roman Emperor Diocletian looked out at his empire and saw a problem: prices were spiraling out of control. Inflation was eating away at the economy, soldiers were demanding higher pay, and merchants (those pesky, self-interested capitalists) were jacking up their prices to match.
So Diocletian, in his imperial wisdom, issued the Edict on Maximum Prices(7). This was a decree that froze the price of goods and wages across the entire Roman Empire. From olive oil to tunics to a day’s labor, everything now had a fixed, government-mandated price.
Problem solved, right?
Not quite.
Instead of stabilizing the economy, markets collapsed overnight. Merchants, rather than selling at a loss, simply stopped selling altogether. Goods disappeared. Black markets flourished. The emperor’s edict didn’t stop inflation! It just made things worse.
But Rome wasn’t the only civilization to try brute-force control over a complex system…
The Software Industry’s Own Attempt to Outlaw Reality
You might be smiling at Diocletian’s illusion of control, or frankly hubris. But his error is one that has not only been repeated, but amplified by the belief that, in the XX century, we (with the help of scientific thinking) are really able to control reality.
Think about it…
The old-school approaches to software development, which we keep trying to bring back, assume that software delivery (often as projects) can be centrally planned, and:
That requirements can be locked down.
That timelines can be predictedm and fixed.
That dependencies can be fully mapped out.
That complexity can be neatly managed with a Gantt chart.
The reality?
This never works. Just like Diocletian in Rome tried to control the economy, the more we try to control software development, the worse it gets.
Fixing the scope doesn’t prevent chaos, it ensures that when change does come, it’s catastrophic.
More (or “better”) estimates don’t prevent delays, they create systemic fragility.
Fixed roadmaps don’t ensure predictability, they guarantee wasted effort.
Software development is not a factory. It is not an assembly line.
It is a complex, adaptive system (CAS). Just like the Roman economy was, but the emperor and his advisers failed to acknowledge.
And the more we try to control software delivery, the worse the consequences when reality inevitably deviates from the plan.
Let’s face it: our entire theory of software development is somewhere between mildly delusional and utterly disconnected from reality.
The Big Reveal: We’re Fighting the Wrong Battle
The problem isn’t that we’re “not estimating well enough” or “not being disciplined enough.” The problem is our existing and prevailing mental models has been proven inadequate for managing software delivery.
We treat software development like it’s a centrally planned economy. But it behaves more like a complex ecosystem (1).
You don’t command an ecosystem.
You don’t dictate to a rainforest how it should grow.
You don’t tell an ant colony to hit its quarterly KPIs.
Instead of trying to control software, we need to learn to work with its natural dynamics, to design for adaptation, not rigidity. Exactly what The Agile Manifesto asked us to do: Respond to Change Over Following a Plan!
So, let’s take a leisurely stroll through three spectacularly flawed mental models in software development, examine how they fail us in the most predictable (but unexpected😉) ways possible, and figure out what we can do to stop sabotaging ourselves.
3 Ways We Accidentally Make Things Worse, And What to Do Insted
Error 1: “We locked the scope. It’s final.”
In every software project we will hear this bold (and deeply naive) declaration.
We sit in meeting rooms, fill out documents, and create beautifully structured requirements. And we do this, even inside Scrum Sprints, but that’s another point altogether. Back to the project dynamics: when defining software projects, we typically approach it like this:
Business analysts or Product Managers draft the Perfect Requirements Document (PRD - pun intended), as if it were the Ten Commandments.
Engineers look at it and nod because, sure, we can build that.
Project managers slap deadlines on it, convinced that “fixed scope” also means “fixed timeline.” (Sure, there are buffers, but let’s tackle that economic catastrophe in another newsletter.)
Then we start.
And, without exception, new information arrives.
The business learns something new.
Users behave in unexpected ways.
Technical realities make certain assumptions obsolete.
Suddenly, what seemed like a finalized scope turns into a slow-motion train wreck, or even worse: a deathmarch! Ah yes, another scenic stroll through the valley of burnout.
“We need this extra feature to make it usable.”
“We just realized this entire flow doesn’t work in the real world.”
“Oh, you didn’t account for [insert regulatory, compliance, or security nightmare here]?”
The result? Panic.
The PRD is now outdated. But no one was really paying any attention to the PRD by this stage anyway, right?
The deadline is now unrealistic. To the surprise of almost no one.
Teams are scrambling to fit new requirements into a schedule that was never designed to accommodate change.
And instead of questioning the entire premise of big up front planning and locking scope in the first place, we blame ourselves for “bad planning”, and “bad estimation.” Because if history has taught us anything, it's that rigid plans always work flawlessly.
But wait! We’ve Tried This Approach Before, Haven’t We?
Humans have spent centuries trying to control rivers. Stay with me here, there’s a point to this metaphor.
The logic seems sound:
Floods are bad.
Big river walls stop floods. (Like “better” planning solves project delays or even disasters, we’re told)
Problem solved.
Except… that’s not what happens.
Instead of preventing floods, rigid barriers make flooding worse.
When small floods no longer happen, silt builds up, making the riverbed higher and more unstable over time. And that’s only one of the several dynamics that cause catastrophic river flooding.
When rain eventually overwhelms the barriers, the flood is massive—because the water has nowhere to go.
Instead of managing gradual, natural adaptation, we create catastrophic failure events.
This is exactly what happens with up-front, linear plans with fixed scope.
Instead of small, natural requirement adjustments, teams are forced to hold everything back until the change becomes too big to ignore.
Then, when the change finally happens, it’s a disaster: delaying timelines, wrecking morale, and causing teams to burn out trying to "catch up."
👉 When change is suppressed, it doesn’t disappear. It just resurfaces later in a more destructive form.
The Alternative: Stop Blocking Scope Change and Learn to Design for It
Instead of trying to contain or manage change (like river beds), we need to design our processes for embracing change.
💡 Use Impact Maps instead of PRDs.
Instead of specifying exact features upfront, Impact Maps focus on outcomes and user behavior.
This allows teams to adjust scope dynamically by working from a goal, instead of a list of requirements created up-front, when we know the least about what we are trying to deliver.
💡 Use Story Maps instead of static backlogs.
Story Maps visualize the journey of the user, making it easier to rearrange, add, or remove features as the project evolves.
Instead of thinking of scope as a rigid list of tasks, it becomes a fluid, evolving system.
💡 Set directional goals, not feature commitments.
“We must improve onboarding conversion by 20%” is adaptable to new information being discovered during the delivery.
“We must build Feature X, Y, and Z” is a rigid trap, that will likely lead to completely predictable, but unexpected delays. Get it?
Just as:
👉 You don’t stop a river from flooding by building bigger walls.
👉 You stop flooding by designing natural ways for water to flow.
Software cannot be contained with fixed structures, software delivery happens in an ever-evolving ecosystem, which includes people, technology, interactions (2).
The teams that thrive aren’t the ones that try to control requirements.
They’re the ones that learn to ride the changing current.
Because change isn’t the enemy. It’s the only constant.
Error 2: Unrealistic Deadlines & Estimation Errors
“We’ve mapped it all out. This project will take exactly 9 months.”
This statement is sometimes followed by:
A fancy Gantt chart with dependencies so fragile they might as well be made of glass.
An engineer’s reluctant nod, because arguing is futile.
A CEO’s confident smile, because “this time, we got the estimates right.”
We convince ourselves that if we just estimate better, we’ll finally master software timelines.
Yet, without exception:
At Month 3, we realize we misunderstood half the requirements.
At Month 6, we uncover a technical problem no one saw coming.
At Month 9, we’re nowhere near done, and leadership is asking “What went wrong?”
And the answer?
Nothing went wrong.
This always happens. Because the entire premise is flawed.
We estimate as if knowledge is fixed; but knowledge changes and increases over time.
The Cathedral That is 14x Late vs. Estimates
In 1882, Barcelona set out to build the Sagrada Família, a breathtakingly ambitious cathedral designed by architect Antoni Gaudí (one of my favourite archiects!) (3)
The original estimate? 10 years.
Reality? It’s still under construction. 140 years later.
Why? Because every step of the process revealed new challenges.
New materials required rethinking old designs.
New engineering techniques enabled more ambitious structures.
Political and economic changes affected funding and labor.
At no point did the builders fully understand everything upfront. Instead, each phase of construction informed the next phase, and required a constantly evolving plan.
Sound familiar?
It should. Because software works the same way.
The more we build, the more we learn about what we actually need.
The problem is, our planning systems don’t accommodate this reality.
Instead, we treat estimation like prophecy. And when the prophecy fails, we blame the engineers. (Have you noticed how rarely the leaders take the blame for the bad estimates? 🤔)
The Real Problem: We Discover More Work, But Don’t Replan
Here’s what actually happens in every software project:
We start with an estimate based on what we know at the time.
As we build, we discover missing pieces, things we didn’t know we needed.
Instead of replanning, we just add the new work on top of the old plan.
The deadline stays the same. Because? I don’t know… Seriously, I don’t know. It’s a mystery!
We add work, often without adjusting scope.
We add complexity, often without adjusting deadlines until it is too late and obvious we need more time.
We add knowledge but don’t act on it, including changing scope, changing the plan, etc.
This has led me to coin the phrase: “The natural state of a software project is “late”, and most strategies we use to recover actually end up making the project be even more late.”
The Alternative: Plan for Learning, Not Prediction
💡 Use Rolling Forecasts + Continuous Delivery, Instead of Fixed Deadlines.
Instead of setting a fixed date and pretending it’s real, we can use rolling forecasts that evolve as new information emerges. We change scope, dates, assignments; whatever is necessary given the information we uncover.
We organize processes so that we can release software regularly to a production, or production-like environment, and are (or attempt to be) ready to release at any time.
💡 Invest in Software, Don’t Estimates Software
Each software delivery, or feature must be seen as an investment, instead of a static piece of work to be estimated and delivered.
I explain this “software delivery as investment” metaphor in this podcast episode. Check it out if you are interested in that perspective.
A key benefit of looking at software as investment is that we design the decision making processes around risk elimination, risk mitigation, and stopping bets (that’s the technical term) that are not proving their value anymore.
Let the Cathedral Evolve
👉 The problem isn’t that we estimate poorly. It’s that we estimate as if knowledge is static.
👉 We don’t need better estimates. We (still) need better adaptation.
Software projects are like the Sagrada Familia in Barcelona, they evolve as they are built.
The best teams don’t fight this reality, they design their processes to take advantage of that evolution.
Because learning isn’t failure. Learning is the point.
Error 3: Portfolio Waterfall, The Organizational-Level Disaster
Agile is everywhere, we’re told:
Teams run daily stand-ups.
Engineers pair-program and ship iteratively.
Product owners prioritize backlogs dynamically.
Yet, at the portfolio level, Agile barely exists.
When you zoom out, what do you see?
Annual budget cycles deciding what will be built 12-18 months in advance.
Executive roadmaps that look suspiciously like waterfall plans (did you notice the horizontal bars in many roadmapping tools?)
Quarterly reports demanding that projects stay “on track” even when reality has changed.
It’s like an orchestra where every musician is improvising beautifully, only to be forced into a rigid, pre-written symphony when the conductor shows up.
At the individual team level, Agile might be the “standard”.
But, at the organizational level, it’s a façade.
We have Agile teams trapped inside a Waterfall machine.
And that’s why we’re still late.
The Soviet Five-Year Plans
The Soviet Union didn’t just plan factories with their famous 5-year plans.
They planned entire industries with rigid five-year plans.
Every tractor factory, steel mill, and textile plant had production quotas.
It didn’t matter if the world changed—the plan had to be followed.
The result?
Factories hit quotas by producing massive, unusable objects (because weight-based targets encouraged size, not usefulness).
Textile plants produced a millions of square meters of fabric, but no one could buy a decent pair of shoes.
Farmers grew tons of wheat, but since distribution was centrally planned, food rotted in warehouses while people starved.
It wasn’t just inefficient.
It was structurally incapable of adapting to reality.
Sound familiar?
It should. Because this is how many companies plan software portfolios today!
The Corporate Version of Soviet Planning: The Annual Budget Cycle
💰 Every year, the CFO demands a plan.
📊 Leadership draws up a massive roadmap of commitments.
🗓️ Timelines are set. Funding is allocated. The plan is locked in.
And then?
Reality happens.
A critical customer needs a feature that wasn’t in the plan.
The market shifts.
A competitor launches something unexpected.
But guess what? The roadmap is already set.
There’s no mechanism to adjust course without a political battle.
Executives start asking:
“Why are projects behind schedule?”
“Why are teams changing priorities?”
“Why isn’t the roadmap being followed?”
Because the roadmap was an illusion from the start.
We act like software development behaves like a factory outputting predictable widgets (and this belief is even stronger at the portfolio level).
But software initiatives behave more like an investment portfolio, sometimes going up (delivering value, being on time), and other times going down (bad surprises, delays, tech debt, etc.)
The Alternative: Software as an Investment Portfolio
💡 Stop treating software development as if it was a factory. Start treating it like an investment process.
When investing:
You follow economic cycles, get updates on company performance and change investments accordingly.
You place multiple bets, then adjust as you see what works.
You don’t keep your funds in a stock because you planned to, you double down on what’s working and cut what isn’t (“cut your losses”).
📌 How can we apply these ideas to software delivery portfolios:
✅ Fund teams, not projects.
Instead of funding a fixed roadmap, fund teams (or teams of teams) with a mission.
Give these teams goals instead of flat list of requirements (even if as a backlog).
Let the teams discover the best way to achieve the goal.
✅ Use rolling investment cycles.
Instead of locking budgets yearly, re-evaluate funding regularly (at least quarterly) based on what you learn, and how the deliveries are performing.
✅ Measure success by outcomes, not adherence to plan.
Instead of “Did we build Feature X by Q3?” ask “Did we move the metric we care about?”
The Myth of the Predictable Portfolio
👉 We keep trying to manage software portfolios like we used to manage projects.
👉 But software delivery is much more like investing: it requires constant adjustment.
We don’t need better portfolio planning tools.
We need a better philosophy of software investment.
Because organizations aren’t late because teams are bad at Agile.
They’re late because they’re still running the factory while pretending to be a startup.
And until that changes, we’ll always be late.
The Path to Mastery—Be Water, My Friend
So here we are.
We’ve tried to control scope, and it backfired.
We’ve tried to set realistic deadlines, and they became disastrous fiction.
We’ve tried to centrally plan entire portfolios, and we ended up running a Soviet tractor factory instead.
At this point, you may be asking:
“Okay, so what the hell do I do?”
Because let’s be real: you probably can’t just walk into the CEO’s office tomorrow and say,
"Hey, I read this cool article about how our entire philosophy of software planning is broken. Let's burn it down and start over."
That would be fun, but also, you like your job.
So let’s talk actionable survival tactics.
Because even if you can’t change your company overnight, you can still change how you work inside it.
Lesson #1: Stop Resisting Reality, Start Riding It
🔴 What not to do: Pretend reality will bend to your plan.
🟢 What to do instead: Accept that change is constant, and make it work for you and your software teams.
💡 Tactic: Replace rigid planning with adaptive planning.
Instead of saying “This must be done by Q3”, say “What can we deliver next?” or “What’s preventing us to release today to a production or production-like environment?” (BONUS: fix everything that comes up when you answer this last question.)
Instead of arguing about whether a change is “allowed”, ask “What’s the smallest adjustment we can make right now? And what can we do later instead?”
Instead of fighting for a perfect long-term plan, fight for enough flexibility to respond to reality.
🚀 Immediate win: Shift conversations away from predicting the future and toward talking about how to respond to new information.
Lesson #2: Shrink the Scope, Deliver Sooner, Learn Faster
🔴 What not to do: Assume you can plan everything before you start.
🟢 What to do instead: Deliver something real as soon as possible and learn from it.
💡 Tactic: Break things down until they’re uncomfortable. (4)
If you think something needs three months, ask:
“What could we ship in three weeks?”
“What’s the smallest useful version?”
“What’s the fastest way to get real feedback?”
🚀 Immediate win: Stop building castles in the sky and optimize for faster feedback
Lesson #3: Work in the Shadows, Influence Instead of Asking for Permission
🔴 What not to do: Wait for permission to fix broken processes.
🟢 What to do instead: Quietly start working in a better way, and let the results speak for themselves.
💡 Tactic: Become an “Agile smuggler.”
If leadership demands a rigid roadmap, you can still run iterative experiments inside each “milestone.” This was the reality for many of us before Agile took off.
If planning is locked, you can design flexible decision points.
If estimation is a mess, start tracking cycle time data and use it to make future conversations more grounded in data. (5)
🚀 Immediate win: Start with small changes you can apply to your own work first. Then, when you have data, show “friendlies”, gather momentum through building a group of people committed to improving how things work in practice.
Lesson #4: Build Resilience, Not Dependency
🔴 What not to do: Build brittle systems that depend on everything going right.
🟢 What to do instead: Build adaptive systems that can handle surprises.
💡 Tactic: Design for recovery from failure, not perfectly planned success.
Assume things will change: how can you design in a way that absorbs that change without breaking?
Assume deadlines will move: how can you deliver value in small, independent pieces?
Assume people will misunderstand requirements: how can you build in fast feedback loops? (6)
🚀 Immediate win: Instead of being surprised by change, expect it and use it to your advantage, by building in steps where change is welcomed, or even expected. For example: work with the Product Owner to reduce the size of the backlog, focusing on details only for short term stories, and keeping the future items as larger/fuzzier statements.
Lesson #5: Be Water, My Friend
🔴 What not to do: Try to impose structure on something that resists structure.
🟢 What to do instead: Flow with the constraints, not against them.
💡 Tactic: Bruce Lee your way through software development.
If leadership demands certainty, give them options and trade-offs instead. Optionality (a topic for another newsletter) is a powerful tool to absorb or even benefit from change!
If your company is addicted to massive estimation-driven plans, use data to validate those plans early enough so that changes are still possible: a #NoEstimates principle (5).
If your funding process requires absolute certainty of scope and timelines, work with the PO to be ready to start changing the scope right after the funding happens. Stakeholders will thank the team for their flexibility when asking for changes to include “new” ideas, and your team gets permission to remove other items as a “trade-off”.
🚀 Immediate win: Take every change as an opportunity, and slowly change how you work to make sure you take advantage of every change.
The Shift from Control to Mastery
At every level—scope, estimation, portfolio planning—we’ve seen the same problem.
We try to control software like it’s overflowing river or a “planned” economy.
But software behaves more like an ecosystem.
👉 You don’t impose structure on a river. You prepare for the innevitable flood events through specific floodplain, requiring buildings to be flood proofed or raised, etc.
👉 You don’t dictate what happens in an ecosystem. You learn how to adapt to the ecosystem around you through the study of systems and complex adaptive systems especially.
💡 That’s the shift.
From control → to flow.
From rigidity → to flexibility.
From planning for certainty → to designing for being resilient or even anti-fragile to change.
And you don’t have to wait for permission to do this.
You can start right now, inside your own work, with tactics that you can apply right away.
Because the future of software development isn’t about better processes.
It’s about better ways of thinking.
And that change starts with me, and you.
At the Global Agile Summit we create the space for you to meet likeminded individuals, and form a community of pragmatic innovators! Get inspired, take action!
Join us in Tallinn, and help define a better way to develop and deliver software
References
(1) Jim Highsmith made this point in his book Agile Software Development Ecosystems: Problems, Practices, and Principles, published in 2002
(2) A big thank you to Esko Kilpi, who gave us the metaphor of “interactive value creation”. A must read for anyone interested in knowledge work in general, and software in particular.
(3) https://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia
(4) The Slicing Heuristic by Neil Killick is a great place to start learning this: https://neilkillick.medium.com/my-slicing-heuristic-concept-explained-810ee70b311e
(5) You can start by doing what Carmen does in the #NoEstimates book.
(6) “Communication always fails, except by accident” and requirements as documented are one form of communication. Korpela’s commentary on Wiio’s laws.
(7) https://en.wikipedia.org/wiki/Edict_on_Maximum_Prices
Deep insights, powerful article, especially the metaphors ( river, cathedral ) 🙏