No-Plan Agile
The Myth and Legend
There's a myth that has been following agile frameworks since their inception. It usually sounds something like this: "We're agile now. The Teams plan it themselves" or "We're being Agile, so we only plan the Sprint and maybe the upcoming Sprint"
You hear it in kickoffs, in transformation pitches, in the excited retelling of teams that just adopted their first framework or have been "doing" agile for a whole while. And the strange thing is, it's not entirely wrong. Agile does challenge traditional planning. It does question the idea of locking everything into a Gantt chart twelve months ahead. But somewhere between the original intent and the meeting room reality, I see something got lost: the part where planning still matters. Not less planning. Different planning.
And that "different" planning is most certainly not equivalent to "no planning" or only planning in chunks. Ok so bear with me:
Level Up
In the 1960s, psychologist Clare Graves proposed a model of how human systems develop. Not in a straight line, but in stages, each one building on the one before it. Don Beck and Christopher Cowan later formalized this as Spiral Dynamics, a framework that maps value systems in individuals, teams, and organizations through distinct levels of complexity. Spiral Dynamics isn't the only lens for this, but it's the most useful one I've found for explaining why organizations keep tripping over the same step.
The short version: organizations grow through stages. So, like a video game, imagine it like simple levels 1, level 2, level 3...
So early stages (Level 0 or 1) are about survival, then power (level 2). And then comes order (Level 3): rules, processes, discipline. Then achievement (Level 4): results, optimization, competition. Then collaboration (Level 5): consensus, inclusion, shared ownership. And eventually, systems thinking: the ability to see the whole picture, hold contradictions, and adapt. If not obvious by now: that's Level 6. Synergy.
Here's what matters for this conversation: you can't skip a stage. Try beating a Level 6 Boss in a game when you are Level 2. You fail miserably, the game does not intend to let you win. Or if video games aren't your thing: you can't run a marathon without building the base first (walking, jogging, etc.) There's also no judgement in being on Level 3 or 4. It's part of the game!
But an organization that never built planning discipline on Level 3 can't jump straight to adaptive delivery which happens in Level 6. The flexibility looks like freedom from the outside. From the inside, it's chaos with a standup (the daily team sync meeting). Also known as Agile Theatre.
You can’t skip a stage.
This isn't a new observation by the way: Dajo Breddels made the connection between Spiral Dynamics and agile adoption explicit at XP Days (a European agile conference) back in 2014. His framing was precise: the difference between "doing agile" and "being agile" is a cultural evolution, not a process change. You "can" adopt Scrum's ceremonies without ever developing the maturity that Scrum requires. And many organizations do exactly that: skip Levels and then blame agile when they are unable to beat the Boss in Level 6.
The Scrum Pre-Requirements
Scrum doesn't say "don't plan." Scrum says: "here's a way to deliver your plan incrementally."
One of the most important reframings I offer teams is this:
The Product Backlog is not a planning tool. It's a delivery mechanism.
It assumes (and requires) that somewhere upstream, somewhere higher up, or somewhere in the tools available, someone has already answered the big questions: What are we building? For whom? What does the product look like as a whole? What's the MSP (Minimal Shippable Product), the Must Haves, the Nice to Haves? The backlog takes that understanding and breaks it into deliverable pieces. The sprint (a fixed timebox, usually two weeks, in which the team builds) delivers them. The increment (the working result at the end of each sprint) validates them.
Tools like User Story Mapping* exist precisely for this reason. Jeff Patton didn't invent Story Mapping because teams had too much planning. He invented it because they had none. Teams were writing user stories in isolation, building features that technically worked but never formed a coherent product. Story Mapping forces you to see the product as a continuous narrative from the user's perspective before you slice it into increments.
(*User Story Mapping is an agile planning tool that organizes effort into a visual narrative of the user's journey through the product, giving teams a shared overview before breaking work into deliverable pieces. I often describe it as an "Agile Backlog Building Tool with a different Interface Design".)
That's the planning agile actually requires. Not effort estimation. Not sprint capacity. Not story points (abstract units teams use to estimate effort) on sticky notes. The question isn't "how long will this take?" The question is "what does this person need, and what happens when they use it?" (and also "who are the people interacting differently with the same product?")
Planning For Effort vs. Planning For People
This is where most teams unfortunately get stuck. And it's the gap that Spiral Dynamics helps explain.
Organizations at the order stage have planning discipline. They can create timelines, assign resources, track budgets. What they often can't do is plan from the user's perspective. Their planning answers "what do we need to do to build it?" not "why does someone need it and how do they handle the product's system? How should/could they interact with it?"
Organizations at the achievement stage optimize. They track velocity (how much work a team completes per sprint), measure throughput, chase efficiency. Their planning answers "how fast can we ship value to the user/customer?" but rarely "what happens after someone receives it?" and "What's the best way or the shortest way to achieve value?"
Both stages produce planning. Often very thorough planning. But it's planning that circles around the effort of building, not the experience of using. Costs, resources, timelines, dependencies. All important. All incomplete.
The step that agile actually represents, in Spiral Dynamics terms, is the shift toward systems thinking. Not just planning what to build, but understanding the system the product lives in. The user. The context. The moment when something goes wrong and someone needs help. The moment when something works and someone needs guidance on what's next. What happens before my work and what after? What are the dependencies? And responsibilities? Or who's responsibility is it?
That's not a planning upgrade. It's a planning transformation. And you can't get there by skipping the stages before it. You need the discipline of structured planning and the shift to user-centered thinking. One without the other gives you either rigid Gantt charts or reactive backlogs that go nowhere.
None of this is new thinking, by the way. Graves described these stages in the 1960s. Patton published his mapping approach in 2014. The Scrum Guide has always listed a clear, ordered Product Backlog as a prerequisite, not an output. The pieces are all there. They just rarely seem to get connected in the rooms where the actual planning conversations happen.
The Feature That Forgot Its User
I saw this play out with a team I worked with. They'd been building their product for three years. Smart people, complex domain, real progress. We'd just introduced User Story Mapping and it had been a huge step forward for how they planned their work. They were cutting their increments well, aligning on priorities, delivering consistently.
In this particular session, they were planning a feature where the product would test itself for errors. When a fault was detected, a technician would physically go to the customer's home to fix it, if it was an error the customer wouldn't be able to fix themselves (turning it on and off basically). The team was deep in the technical conversation: detection logic, fault categories, response triggers. Effort estimates, competency alignment, dependencies. All the right planning artifacts were on the table.
While they were talking implementation, I was reading through the initiative's narrative, which was a bit more rough than final (but better than nothing.) I asked a team member who wasn't involved in the ongoing discussion: "How does the technician actually know what the error is?"
The team paused and looked at me, almost laughing:
"Well, the thing stops working. Obviously."
"Right, but if the system identifies the error itself and then a technician shows up... how does the technician know what specific error the system found?"
"The system gives them a code."
"Ok, and how does the technician get that code?"
Silence. Then, slowly, the kind of quiet where you can watch a realization land.
"How does the device communicate the identified fault to the person standing in front of it?"
Three years. The system was nearly complete. The self-testing logic was sophisticated and the hardware parts already in production. But nobody had ever discussed how the error information would actually reach the human who needed it. There was no display. No output. No communication layer between the machine's diagnosis and the person who was supposed to act on it.
They had to pause production and redesign the hardware to include a display.
This team had planned everything from an effort perspective. Timelines, dependencies, technical feasibility, resource allocation. What they never planned was the user's experience in the moment that mattered most. The technician standing in front of a broken machine, needing one piece of information, with no way to get it.
That's not a planning failure. That's a planning gap. The discipline was there. The perspective wasn't. And pausing production to redesign hardware costs more than a year of user story mapping sessions ever would. That's where the agile conversation in planning focuses: the customer, the users. You need both to really have a good understanding what your product should and shouldn't do. The execution of this plan could be done in an agile way. (But that's another subject).
No Motherlode Cheats
The pattern I keep running into is this: teams adopt an agile framework and believe they've solved the planning question. They have a backlog, they have sprints, they have velocity charts. But underneath, the planning hasn't changed. If it even exists, then it's still effort-first, build-first, technology-first. The framework may support in delivering the pieces "faster", but the pieces still don't form a coherent picture for the person who actually uses the product.
Agile frameworks don't replace planning. They expect it as a precondition! They assume you've already thought about your product as a whole, from the user's perspective, before you start slicing it into sprints. The Product Backlog is the execution layer, not the thinking layer. And when the thinking layer is missing, no amount of sprint planning will compensate. This is why the Scrum Guide has little information about "how to create a backlog".
The myth of "no-plan agile" isn't just wrong. It's backwards. Agile demands more planning maturity than traditional approaches, not less. It demands a different kind: planning that starts with the person using the product, not the person building it. Level 3. You need to beat that Level Boss (and no cheating allowed).
There is unfortunately no real-life cheat code. You can't deliver incrementally without knowing what the whole looks like. And you can't plan a product without asking what happens when a real person stands in front of it.
And the final question isn't whether you can: it's whether you can afford not to.
Are you and your team stuck on Level 2? Book a free consultation call: