The Agile Manifesto, Rethought: Why Doing the Work Is the Best Form of Planning

Have you ever watched a project team spend weeks writing a plan that was outdated before anyone acted on it? Or sat in a meeting where the real problem didn’t surface until someone finally showed the group something that actually worked? That gap — between the plan and the reality — is exactly what the second value of the Agile Manifesto is about.

This is Article 3 of a six-part series that reframes the Agile Manifesto not as a software methodology, but as a decision-making framework for any project involving uncertainty. So far we’ve covered the foundation of value-driven tradeoffs and why people and interaction shape outcomes more than processes do. If you’re joining us for the first time, welcome — this article stands on its own.

In this article, we unpack the second Agile value: Working Solutions Over Comprehensive Documentation. Three concepts drive it — Progress Reveals Truth, Deliver to Learn, and Documentation Follows Work. Each one comes with example story, actionable steps you can use immediately, and a free AI prompt guide to help you put it into practice.

If you manage projects, lead teams, or make decisions when the path isn’t fully clear — this one’s for you. Consider sharing it with a colleague who’s been buried under a planning process that never quite gets to the work. And scroll to the end for a visual infographic that pulls the key ideas together at a glance.

Let’s get into it.

CONCEPT 1: PROGRESS REVEALS TRUTH

You can’t think your way to the truth. You have to work your way there.

There’s a seductive logic to thorough upfront planning. If we just map it out completely, define all the requirements, anticipate every edge case — we’ll avoid surprises later. It feels responsible. It feels professional. It feels safe.

The problem is, it doesn’t work. Not on complex projects. Not when the problem space is fuzzy, the stakeholders aren’t fully aligned, or the environment is moving. And the evidence backs this up: decades of project research, from the Standish Group’s Chaos Reports to work by authors like Marty Cagan and Donald Reinertsen, consistently shows that the *vast majority of project failures aren’t caused by a lack of planning*. They’re caused by building the wrong thing — often with detailed plans and documentation firmly in place.

Why? Because planning is based on assumptions, and assumptions are a stand-in for knowledge we don’t yet have. Every plan is really a theory about how the world will behave. It’s only when you start doing the work — building, testing, releasing, reviewing — that the theory meets reality. And reality always has notes.

Progress Reveals Truth is the recognition that the act of doing work is itself a form of inquiry. The moment you produce something tangible — a rough prototype, a draft report, a working demo — you generate information that no amount of thinking could have surfaced. Problems become visible. Assumptions get tested. Priorities shift in response to what’s real.

This isn’t an argument against planning. It’s an argument about what planning is for. Planning sets direction and allocates resources. Work generates truth. Both matter — but they’re not interchangeable. When teams mistake documentation for progress, they delay the moment of truth indefinitely. When they use early work to interrogate their assumptions, they learn faster and course-correct before mistakes compound.

The practical question isn’t whether to plan. It’s: how quickly can we produce something real enough to tell us what we don’t know?

What It Looks Like:

When Dominique’s team lead shrugged and said “people see problems differently when there’s something real in front of them,” it was the most expensive lesson of the project — and the most useful.

How To Do It:

1. Identify your first “show-able” moment. Before the project starts, ask: what’s the smallest version of this we can put in front of real users or stakeholders? Aim for something visible within the first two weeks, not two months.

2. Treat early work as a question. When you share a draft, prototype, or early version, frame it explicitly as: ‘We’re testing our assumptions here.’ This removes defensiveness and invites honest feedback.

3. Debrief after every real-world exposure. After any working version is reviewed, hold a brief structured debrief: What did we learn? What assumptions were wrong? What do we now know that we didn’t before?

4. Track assumptions explicitly. Keep a simple running list of the assumptions embedded in your plan. As work progresses, mark which ones were confirmed, which were wrong, and which remain untested.

5. Compress the time to first reality-check. When you feel the urge to plan for another week, ask whether you could build something rough enough to test instead. The cost of a prototype is almost always lower than the cost of discovering the problem later.

✨FREE RESOURCE

**AI Prompt Guide: Surfacing Hidden Assumptions Early**

This guide helps project leads and team members use generative AI to identify and test the assumptions buried in their plans before those assumptions become expensive mistakes. It’s beginner-friendly — you don’t need to be an AI expert to use it. Bonus non-AI Tool: Assumption Tracker — Progress Reveals Truth

CONCEPT 2: DELIVER TO LEARN

Delivery isn’t the end of learning. It’s the beginning.

Most project cultures treat delivery as a finish line. You plan. You build. You deliver. You move on. The delivery is the point — the preceding work is justified by the moment when something crosses the threshold from internal to external.

Agile thinking inverts this. Delivery isn’t just the point of completion — it’s a learning mechanism. Every time you put something in front of real users, real stakeholders, or real conditions, you receive information that your internal process cannot generate on its own. The question changes from ‘Did we deliver?’ to ‘What did delivering teach us?’

This matters because complexity means unpredictability. You can model user behavior, simulate workflows, and run internal reviews — but there’s a category of knowledge that only emerges from actual use. Eric Ries, in The Lean Startup, calls this ‘validated learning’ — the discipline of using real-world feedback to update your model of what works. The same principle applies far beyond startups. It applies to any team navigating uncertainty.

Deliver to Learn is a mindset shift about the purpose of delivery. It asks: if every release is an experiment, what hypothesis are we testing? What does success look like, and what evidence would tell us we’re wrong? This isn’t about delivering poor-quality work and calling it learning. It’s about being deliberate — designing deliveries to generate the most useful information, not just the most complete output.

Teams that internalize this shift stop treating early feedback as a sign of failure and start treating it as the whole point. They build in review cadences. They define what learning looks like before they deliver. They create conditions where discovering you were wrong is celebrated rather than hidden.

The irony is that teams who deliver to learn often deliver better final products than teams who plan to deliver perfectly. They make corrections when corrections are cheap. They build confidence through iteration rather than assumption.

What It Looks Like:

Marcus had a boss who said “we can’t have half-measures” — and he agreed with her completely, which is exactly why he asked to start small.

How To Do It:

1. Define the learning goal before you deliver. Before any release — even internal — write down one sentence: ‘By delivering this, we expect to learn ___.’ If you can’t finish that sentence, your delivery criteria may be too output-focused.

2. Design for feedback, not just completion. Every deliverable should have a built-in feedback mechanism. This could be a short review session, a survey, or simply a dedicated conversation. Feedback left to chance is rarely captured well.

3. Start smaller than feels comfortable. The natural instinct is to wait until something is polished. Resist it. A rough-but-real version in front of actual users will tell you more than a polished version reviewed internally.

4. Close the loop explicitly. After each delivery and feedback cycle, hold a brief team session: what did we learn? What stays? What changes? Treat this as part of the work, not an optional debrief.

5. Celebrate corrections, not just completions. When a delivery reveals a problem that changes the course of the work, acknowledge it as a win. You found it when it was fixable. That’s the system working correctly.

✨FREE RESOURCE

**AI Prompt Guide: Designing Deliveries That Generate Useful Feedback**

This guide helps teams structure their deliveries as learning events — not just completion milestones. Use these prompts to design the feedback process before you ship, and to extract maximum insight after you do. No AI experience required. Bonus non-AI Tool: Delivery Learning Log — Deliver to Learn

CONCEPT 3: DOCUMENTATION FOLLOWS WORK

Document what’s true, not what you hope will be.

Documentation has a trust problem. In most organizations, people know that the documentation doesn’t match reality. The process guide is three years old. The requirements document describes a system that was rebuilt last year. The project charter was written to get approval, and the real decisions happened in hallways and Slack threads afterward.

This isn’t a character flaw. It’s a predictable outcome of writing documentation before the work is done. When you document upfront — before you’ve built anything, tested anything, or learned anything — you’re documenting your intentions, not your reality. And intentions are a moving target on complex projects.

The Agile Manifesto doesn’t say documentation is bad. It says working solutions are more valuable than comprehensive documentation — meaning: prioritize getting to a real, functioning result, then document it. This is a sequence shift, not a documentation abolition.

Documentation Follows Work means: write it when it reflects something real. This has a few practical implications. First, it forces honest documentation — because you’re describing what was actually built or decided, not what you hoped would happen. Second, it reduces wasted effort — documentation for features or processes that change before they’re ever used is documentation that costs time and delivers no value. Third, it changes the relationship between documentation and accountability — when you document after doing, the documentation becomes a record of decisions and tradeoffs, not a forecast of them.

Some documentation absolutely must come before the work — legal requirements, safety protocols, security frameworks. Documentation Follows Work is a default, not a law. The discipline is knowing which documents serve the work and which documents substitute for it.

The underlying question is always: who benefits from this document, and when? If the answer is ‘future maintainers, after this is built,’ write it after. If the answer is ‘current decision-makers, before we commit,’ write it now. Let purpose — not habit — drive the timing.

What It Looks Like:

Priya’s operations director had a gift for naming uncomfortable truths, and when he said “we’re documenting what we planned, not what we do,” Priya knew he was right — and that the quarterly manual cycle had to go.

How To Do It:

1. Audit your current documentation habits. Make a list of documents your team produces regularly. For each one, ask: is this written before or after the thing it describes? If before, ask whether it’s guiding decisions or just filling a process requirement.

2. Shift to ‘trigger-based’ documentation. Instead of scheduled documentation cycles, tie documentation to specific events: a decision made, a process finalized, a system changed. The trigger ensures the document reflects reality.

3. Separate guidance documents from record documents. Guidance documents (how to do something) often need to be written before the work begins. Record documents (what was decided and why) should almost always come after. Treat them differently.

4. Write minimal, honest summaries first. A one-page document that accurately describes what exists is more valuable than a 30-page document that describes what was intended. Start with an honest summary, then add detail only where it’s needed.

5. Review documentation against current reality regularly. Build a quarterly or project-end habit of pulling out key documents and asking: does this still describe how we actually work? If not, update it or retire it. Outdated documentation erodes trust faster than no documentation.

✨FREE RESOURCE

**AI Prompt Guide: Creating Honest, Useful Documentation**

This guide helps teams use generative AI to write documentation that reflects reality — quickly and clearly. These prompts are designed for people who find documentation tedious or who suspect their current docs don’t match how things actually work. No AI experience needed. Bonus non-AI Tool: Documentation Audit Worksheet — Documentation Follows Work

TYING IT TOGETHER

Real progress doesn’t come from better plans. It comes from work that teaches you something.

The second value of the Agile Manifesto — working solutions over comprehensive documentation — is easy to misread. It’s not a license to skip rigor or skip writing things down. It’s a reordering of priorities: put real, functioning work in front of the people who need it as early as you reasonably can, then document what you learn, not what you hoped.

Progress Reveals Truth tells us that doing the work is itself a form of inquiry. Deliver to Learn tells us that every delivery is an opportunity to update our understanding, not just cross a milestone off a list. Documentation Follows Work tells us that the most honest, useful documentation is the kind written after you know what’s true.

Together, these three concepts form a feedback loop: do something real, learn from it, capture what you know, adjust, and repeat. That loop — when it runs well — is how complex projects find their way to good outcomes. It’s not about moving fast and breaking things. It’s about moving deliberately, staying honest, and letting reality teach you before mistakes get expensive.

If one of these concepts resonated, try it this week. Pick one decision or deliverable on a current project and ask: what’s the smallest version of this we could put in front of someone real? What would we learn?

If this article was useful, consider liking it or sharing it with someone managing a project where the planning feels bigger than the progress. And scroll down — there’s an infographic waiting that pulls these ideas into a single visual you can keep.

Follow Idea Express for more content like this. We publish at the intersection of thinking frameworks and real-world execution.

REMEMBER

Plans describe what you intend. Work reveals what’s true. The gap between them is where every project actually lives — and learning to close that gap is the whole game.

Next up in the series: Article 4 explores the third Agile value — Customer Collaboration Over Contract Negotiation. If you’ve ever watched a project drift quietly out of alignment with the people it was supposed to serve, even while everyone technically followed the plan, that article is for you.

Resources: