I can’t build software the old way anymore

When I first heard about Agile, I thought it sounded irresponsible.

You’re telling me we start building without knowing what we’re building? That the requirements can change halfway through? That the plan isn’t fixed? Every instinct I had as a developer pushed back. Planning felt professional. Certainty felt safe. Changing course mid-project felt like failure.

The comfort of a complete plan

There’s something deeply satisfying about a full specification. Every screen designed, every feature described, every edge case considered. Before a single line of code is written, you know exactly where you’re going.

The problem is that the map is not the territory. Users don’t behave the way you imagined. The feature that seemed essential turns out to be ignored. The one you almost cut becomes the thing everyone loves. You only discover this after you ship — but by then you’ve built everything according to the original plan, and changing course is expensive.

The complete plan wasn’t certainty. It was the illusion of certainty.

What studying for the certifications taught me

When I started preparing for my Scrum certifications, I expected to learn a process. What I found instead was a philosophy.

Agile doesn’t pretend you can predict the future. It assumes you can’t — and builds a system that works anyway. You do a little, you show it to real people, you learn something, you adjust. The change request isn’t a disruption to the plan. It’s information. It means someone looked at what you built and understood something they didn’t understand before. That’s not failure. That’s the process working.

Inspect and adapt. It sounds simple. It changes everything.

The dread I used to feel

I remember dreading change requests. A stakeholder would ask for something different and my first reaction was frustration — we already built that, now you want something else? The effort, the rework, the schedule impact.

What I was really feeling was the cost of a waterfall assumption: that changes are exceptional, that the plan should have been right the first time, that needing to adapt means someone made a mistake.

Agile reframes all of it. Changes aren’t exceptional. They’re expected. The question isn’t how to prevent them — it’s how to make them cheap enough that you can respond to them without panic.

I can’t go back

I can’t build software the old way anymore. Not because I’ve forgotten how, but because I now know what happens when you do.

You build the wrong thing confidently. You discover it late. You pay for it expensively.

Agile doesn’t guarantee you’ll build the right thing. But it gives you feedback loops early enough to correct course before it’s too late. Once you’ve experienced that — once you’ve changed direction in Sprint 4 and shipped something people actually wanted instead of what you thought they wanted — the alternative feels like driving with your eyes closed.

The plan was always going to be wrong. The only question is when you find out.