Hey Agile Folks, We Need to Talk About Planning
I've been in and around software teams long enough to watch Agile go from a genuinely good idea to something that gets used as a hall pass for not thinking things through. And I think it's worth having an honest conversation about it, because I've seen it from both sides of the fence.
The Problem Nobody Wants to Say Out Loud
Here's what I keep running into. A team says they're "doing Agile," and what they really mean is they skipped the part where you sit down and figure out what you're actually building and why. No requirements. No discovery. No real conversation with the people who'll use the thing. Just, "Let's start sprinting and we'll figure it out."
A 2024 study by Engprax and J.L. Partners surveyed 600 software engineers in the US and UK and found that projects with documented requirements before development began were 50% more likely to succeed. Projects with clear requirements were 97% more likely to succeed. That's not a rounding error. That's a wake-up call.
The Agile Manifesto says to value "responding to change over following a plan." But folks, read that again. It says over, not instead of. You still need a plan. You just hold it loosely. Somewhere along the way, a whole lot of teams heard "don't plan" and ran with it, and honestly, it shows.
I've watched teams burn months of budget building the wrong thing because nobody stopped to ask a few basic questions up front. As one practitioner put it, if you skip upfront planning, you might not learn enough about what you're taking on until you're mid-stream and expectations are already set. By then you're in trouble and everybody knows it.
But Hold On, It's Not That Simple
Now, before the Agile coaches come for me, let me be fair. There's good reason the industry moved this direction.
The Standish Group has studied over 50,000 IT projects across 25 years. Their 2020 CHAOS report found that Agile projects are roughly three times more likely to succeed than traditional Waterfall projects, and Waterfall projects are twice as likely to fail outright. That's a mountain of data, and you can't just wave it away.
A meta-analysis of 25 peer-reviewed studies found that iterative approaches deliver 25 to 28 percent faster time-to-market than linear processes. The key insight was that iterative methods don't skip planning. They distribute it throughout the work instead of front-loading it all into a phase that's outdated by the time you finish writing it up.
And that's the real point. The original Agile thinkers were obsessed with design quality. Robert Martin's foundational Agile book was mostly about SOLID principles, design patterns, and test-driven development. Martin Fowler is synonymous with thoughtful software architecture. These folks weren't saying "don't think." They were saying "don't pretend you can think of everything before you start."
Where I Come Down
The research and my own experience both point to the same place. You need "just enough" upfront work to establish a shared understanding of what you're building, who it's for, and what the big risks are. Domain modeling, architecture decisions, basic user research. Then you iterate from there.
The problem isn't Agile. The problem is lazy Agile. It's using the framework as cover for skipping the hard work of understanding your problem space. "We don't need a test team because we're Agile" isn't a principle. It's a budget cut wearing a hoodie.
Good Agile teams plan. They just plan differently. They plan enough to set a direction, then they learn and adjust as they go. Bad Agile teams don't plan at all and call it a methodology.
If your team can't answer "what problem are we solving and for whom" before the first sprint starts, you're not being Agile. You're just winging it.
Note: The Engprax study was conducted to promote a competing methodology and should be read with that context in mind.
Sources:
- Engprax/J.L. Partners survey (2024)
- Standish Group CHAOS Reports (1994-2020)
- meta-analysis of 25 peer-reviewed studies on iterative vs. linear change management (Rietze et al., 2022)
- Digital.ai State of Agile Reports
Top comments (0)