The Costly (Side) Effects of Agile

People come to Agile with all sorts of expectations. It’s easy and efficient iteration, right? The classic drawing says it all. Start with a skateboard, then add a few bits to make a scooter, scale up the wheels to fit a bike, then add an engine for a motorcycle, and finally put two extra wheels and four doors…BOOM: you got a car.

Have you ever seen the popular sketch originating with Henrik Kniberg?

Famous agile drawing of a skateboard to car through iterations.

It’s the perfect approach for fast delivery, reduced risk, and efficacy, right? Maybe not. Here’s the truth: that journey is expensive. Incredibly expensive. At every stage, materials and work are discarded, time is spent trying to figure out how to iterate (cheaply), and resources are burned on transitional versions that aren’t going to last.

For designers, design teams, and product managers, this cost is particularly sharp. Agile’s fast pace forces them to adapt quickly, reworking ideas just enough to build and discard valuable efforts at each iteration. While Agile avoids overcommitting early, it shifts compounding costs to the future. This usually means design and product teams transmute five different modes of transportation to deliver one car.

So, what are Agile’s trade-offs for design and product teams: its benefits, the waste it generates, and the challenges of navigating its increasing difficulty over time?

The Promise of Agile

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” — Agile Manifesto

Agile feels like the perfect answer. You gain speed and reduce risk. Instead of spending months designing and building the perfect car only to realize nobody wants it, build a small version (a “skateboard”), ship it quickly, and learn what works. Then just iterate, by adding functionality and value, adapting to user feedback and changing needs along the way. What’s not to love? This flexibility makes Agile appealing, especially to the business side of the house where speed, adaptability, and risk management are high priorities.

For design and product teams, this means less pressure to solve the long-term vision upfront. Instead, you can solve and mature ideas just in time, responding to real-world data rather than assumptions.

In theory, it’s great: early wins, reduced risk, reduced cost to ship, and consistent value delivery.

Start with low-cost releases to avoid the risk of high-cost.

But what seems to be overlooked is the cost of way of working. It isn’t free. Each iteration costs time and money to ship. Yes, you’re learning at every step, but you’re also building multiple versions of a product that (if you’re successful) won’t last. When a new feature is prioritized for creation, it has to fit into the existing product, and sometimes that means retrofitting (or renovating) what exists so it makes sense and works with the existing experiences. It’s not a big deal with smaller products, but once you reach a significantly complex product, this becomes increasingly difficult at every step.

This shifts the focus from delivering a single polished solution to constantly iterating and adapting, which can be costly for teams as the complexity of an experience grows and there’s more to integrate with.

The promise of agility is real. And it works. It works really well. But it’s not without the trade-off of increasing cost (mainly due to rework) down the line. That’s okay, as long as you know that’s the trade-off you’re making.

The Hidden Costs of the Iterative Journey

Let’s revisit that famous sketch by Kniberg. Agile’s flexibility is its greatest strength. It’s also where the hidden costs start to pile up. For design and product teams, time and energy at each iteration shift from building something new to reworking what came before. That skateboard you rushed out the door? Now it needs to become a scooter. That means modifying the deck, removing the trucks, adding more wheels, and building a sturdy mount for the handle. It’s not a simple upgrade; it’s a lot of rework and retrofitting, all while trying to maintain the functionality of what’s already there. And in the digital world, you’re still trying to let the user ride the skateboard/scooter.

The next iteration, the leap from scooter to bicycle, is even more dramatic. Almost none of the parts carry over. The engineering, mechanics, and capabilities are radically different. A scooter’s simple frame and limited motion need to alter to a bicycle’s need for gears, pedals, a chain, and more substantial handlebars. This highlights a critical challenge: is this still an iteration? The time and resources required for this leap grow astronomically.

“Simplicity — the art of maximizing the amount of work not done — is essential.” — Agile Manifesto

In practice, this iterative process creates waste through discarded work, rushed decisions, and required rework along the way. Each new stage, whether it’s a scooter or a bike, demands time, effort, and resources, much of which is replaced as the product evolves.

Iterative growth means lots of extra work moving between iterations.

This waste compounds as complexity increases. Not just a little, but by orders of magnitude. The more features you add, the harder it becomes to integrate new ideas without rebuilding existing experiences. Every new iteration introduces additional connections, dependencies, and constraints, making future changes more expensive and time-consuming. Over time, adding new features to the system becomes harder to manage, and the cost of evolving skyrockets.

And then there’s the impossible task of always “shipping value.” Not every iteration will deliver meaningful value to users, and sometimes the pressure to produce something functional outweighs the need to ensure it’s truly valuable. The idea of “shipping value” is misinterpreted as “shipping something that adds immediate revenue”.

But this famous sketch is just a picture, right? A metaphor. Or is it? When you think about an MVP (minimum viable product), it typically grows into something exponentially more complex. That initial product with just enough functionality eventually needs far more power, more capable infrastructure, and an entirely different architecture to scale. In many ways, Agile’s metaphor isn’t just a picture; it’s an accurate reflection of how products evolve, often at the expense of those trying to keep up with the pace of change.

The High Cost of Committing to the Agile Journey

Agile feels efficient at the start. Build a skateboard, get it out the door, and start collecting feedback. But here’s the catch: Agile isn’t just about building a skateboard — it’s about committing to the entire journey. And we don’t always recognize that the journey gets increasingly more expensive.

At every stage, you’re not just building; you’re also tearing down, reworking, and retrofitting. The scooter had to reuse parts from the skateboard. The bike? It needed an entirely new concept: a frame. And by the time you’re building the motorcycle, you’re revisiting decisions made at every previous stage. It’s not just iteration; it’s renovation, and renovation is rarely cheap. (Just watch HGTV.)

It’s the “save-now, pay-later” reality of Agile. You avoid over-investing upfront, but you shift that cost to the future. Every shortcut taken in the skateboard stage shows up as rework in the scooter stage. Every overlooked detail in the scooter becomes a constraint when building the bike.

For teams creating the product, this means a growing pile of complexity. It’s debt. Each layer adds dependencies, constraints, and challenges. The more you iterate, the more time and energy that needs to be spent managing past decisions while trying to move forward.

Agile works. And it works really well. But it works best when teams understand and accept the trade-off of up-front risk management that demands a heavy payback later. It’s not just about speed, it’s about consciously making that trade-off.

Another Analogy: Architecture Building with Intention

We can look at it another way. I love watching home remodeling shows. My favorite is the moment when demo day is done. You get to see everything unnecessary ripped out and the house laid bare, ready for rebuilding. A lot of times these houses have a history of add-ons over time, extending the foundation, boarding up windows, and more. In the moment they made sense, but with the next vision of what’s needed (the next iteration) a complete gut job is required. And, it’s expensive. Very, very expensive.

Spaces in a house evolve strangely with additions over time.

Imagine constructing building a simple one-room cabin. It’s quick, functional, and serves the purpose you need. But then you add rooms, plumbing, wiring, and now you want to add a second floor. Eventually, you realize the foundation wasn’t built for this. You’re not just adding anymore, you’re demolishing and rebuilding.

Agile follows the same pattern. Speed works in the short term to cut up-front cost and manage the risk of over-investing. But every stage of iteration has downstream consequences. The best teams start with a blueprint, a clear vision of where they want to go, even if they don’t know every detail yet.

Final Reflection: The Price of Agile

Agile isn’t broken. It does exactly what it’s meant to do. But it isn’t free. The teams that thrive are the ones who understand the cost, anticipate complexity, and build with intention. They ruthlessly stick to their product strategy, focusing on core market needs. Each iteration goes through a ridiculous evaluation before being added to the product.

As complexity increases over time, so does the cost of iteration.

The journey works, but only if you go in with eyes open and have the right expectations.

I hope you enjoyed this look at Agile (from a designer’s perspective). What do you think? Are there ways of managing the compounding costs of iteration over time?

Want exclusive early access to more content like this?

👉 Subscribe to my Substack. (Plus, you’ll have the chance to shape future content!)