The process with no name

Since LLMs got good, I keep hearing that agile is dead. I think AI is a chance to renew agile, not a reason to bury it. Agile was always an engineering process: you form a hypothesis, run a small experiment, look at the result, and adjust. Ceremonies and certifications grew on top of that, and the core insight got lost under the rules. My team works in the spirit of agile, under no named method. What follows is the shape of how we work, offered as one example and as a concrete answer to “agile is dead.” I’m not recommending it to you.

Agile is dead, say two camps

The claim comes from two directions.

The first camp argues for spec-driven development. If an agent can turn a detailed spec into working code, the argument goes, then the spec is the real work. You write it up front, hand it over, and the iteration loop matters less.

The second camp wants a more streamlined process. Agents write code fast, so you cut the ceremony, cut the review, and push straight to main. Some teams go further and stop reading the code.

Either of these may work for some teams, and I won’t argue that they can’t. But I reach a different conclusion: LLMs give us the power to do better engineering, not less of it. Most of our changes reach staging an hour or two after work starts. So you can run more experiments and learn from each one sooner. That fast loop runs with Product in staging. Production deploys happen weekly at most, so the loop with real customers can take up to a week. That’s what the Agile Manifesto asked for in 2001, when running that many experiments was hard to afford. It’s cheaper now.

Buried under rules

Scrum, SAFe, story points, and the coaching industry around them all have value. Ceremonies can earn their place too, and I’ll show you the one that does for us. But they also added a layer of bureaucracy, and the original insight got harder to see under it. You can follow every rule of a process and still not be agile, because the rules became the goal.

The problem is old. In 536 BCE, Zichan, the chief minister of the Chinese state of Zheng, had the state’s penal code cast on a bronze cauldron. That made the law public, which by the traditional account no state of the period had done before. His friend Shuxiang, a minister in the neighboring state of Jin, wrote him a letter against it. The letter is in the Zuo zhuan, under the sixth year of Duke Zhao:

“Long ago, the former kings consulted about matters to decide them but did not make penal codes, for they feared that the people would become contentious. … When the people know that there is a code, they will not be in awe of their superiors. Together they bicker, appeal to the code, and seek to achieve their goals by trying their luck. They cannot be governed.”

Translation by Stephen Durrant, Wai-yee Li, and David Schaberg, Zuo Tradition / Zuozhuan, University of Washington Press, 2016.

Shuxiang’s fear was that once people had a written code, they’d stop following the spirit of the law and start arguing over the text.

History mostly sided with Zichan, and you can see why: public law protects people from rulers who decide in private. I’m not arguing against writing things down. Still, Shuxiang’s argument was valid, and what he predicted is what we got: rules, then lawyers, then loopholes, then bureaucracy. Process goes the same way. Once it has enough written rules, people argue the rules instead of chasing the outcome. Did we hold the retro? Did the story have points? Was the sprint goal met? None of those questions asks whether the software got better.

So rules and process serve agile’s ideas, and never the other way around.

Engineering, in both halves

The best description I know of what agile was reaching for comes from Dave Farley’s Modern Software Engineering. He argues that software engineering is a scientific approach to building software, and that it comes down to two skills. The first is optimizing for learning: working iteratively, getting fast feedback, working incrementally, being experimental, and deciding from evidence. The second is managing complexity, through modularity, cohesion, separation of concerns, abstraction, and loose coupling.

I apply both skills to two halves of our work: how we build the software, and how we organize the work. Most process discussions treat those halves separately, but I don’t think you can separate them. A team that writes well-factored code inside a chaotic process still ships chaos.

With agents, learning has one more piece that I care about a lot, and that’s product comprehension. An agent can produce a change faster than I can understand it. If I stop understanding the product, every later decision gets worse, because I’m deciding about a system I no longer know. So I treat comprehension as part of the learning loop, and I don’t cut it to save time.

How we build

Every task gets one pull request, and that 1:1 rule is strict. Our PRs live for minutes to hours, never days, so we have no long-lived feature branches. We’re close to trunk-based development.

We still use PRs because of our products. Some of them move fast, and we need to make quick product-level decisions. A PR lets us test a change in a lower environment (staging, for us) before it reaches production. If the change turns out wrong for the product, we close the PR, which is easier than reverting commits on main.

We also still do code review, and I still look at the code. We practice continuous delivery and acceptance test-driven development (ATDD). So every task starts with acceptance tests that say what “done” means before any code exists. An agent writes the tests, in Gherkin, so they read as plain English. A human confirms that each test captures the intent, and we watch every test fail before any implementation exists. A human verifies the result, too. If you want the review steps in detail, they’re in What’s left for me to review.

About half of our changes run through our factory, the agent pipeline that carries a task from intake to merge. The factory runs our SDLC as a sequence of skills inside a durable queue. Those same skills govern our interactive sessions, so a change gets the same process whether an agent runs it unattended or I’m pairing with one. Interactive sessions take the other half of the work. That half is complex and experimental changes, UI and UX work, and anything that needs human taste or a quick change of direction. The factory itself is in Build your software factory with the lights on.

Every one of these build choices, from the PRs to the review, is something I’m exploring changing soon. Pushing to main, lighter review, and less ceremony around the PR are all on the table. But I needed a quality foundation first. For our agents, guardrails, durability, and reproducibility mattered more than speed, because every later change builds on them. I’d rather loosen a process that works than tighten one that doesn’t.

How we work

We don’t start from a backlog of stories. We start from quarterly goals, break each goal into projects, and break each project into tasks that are thin slices. For every task, we declare its dependencies, its priority, and how it connects to other tasks. With that, the agent can make a smart decision about which task to pick up next.

We can let the agent choose, but usually we don’t. Picking the next piece of work is still a human judgment gate for us. In every stage of the factory pipeline, we hold a gate wherever human judgment matters most, and the agent waits there before it acts.

What comes out of this breakdown is an agent-ready task. It’s unambiguous, and its acceptance criteria are falsifiable, so you can say in advance what result would prove the task isn’t done. In Farley’s terms, each task is a small experiment with a stated hypothesis, and the acceptance tests are the observation. When a test still fails after the work is done, you’ve learned the hypothesis was wrong, which is useful.

This can look like spec-driven development at task size, and the overlap is real. The difference is what happens after the task ships. Spec-driven development treats the spec as the real work. For us, each task is one experiment, and what we learn in staging changes the next task or closes the PR.

None of our practices is new. Trunk-based development, continuous delivery, ATDD, and kanban all came before LLMs. What changed is the cost, and agents changed it most in writing tasks. Writing a task this precisely used to be expensive, so most teams wrote vague stories and filled in the gaps in conversation. Now the precision pays for itself. An agent can act on a precise task without a conversation (because the human conversation was already held), and it can’t act well on a vague one.

The manifesto, line by line

You probably know the manifesto has four values and twelve principles. Here’s how each one shows up for us.

Three of the values carry most of the weight.

• Working software over comprehensive documentation. Done means the acceptance tests pass in a lower environment, whatever a document says.
• Customer collaboration over contract negotiation. Product exercises a change with us in a live environment before it merges. Our weekly alignment meeting brings in people who represent client and downstream customer needs, and most of what they bring is direct feedback and perspective.
• Responding to change over following a plan. We close a PR when the product direction changes. Interactive sessions are for work where we expect to change direction.

The fourth value needs more care, because an agent pipeline is a lot of process and tools.

• Individuals and interactions over processes and tools. We use plenty of process and plenty of tools, and they serve the people. The conversations in our meetings decide what gets built, which keeps us on valuable work instead of on a volume of PRs and code. The outcome is the point, not the lines of code.

And these are the principles we follow:

• Early and continuous delivery of valuable software. Thin slices and continuous delivery.
• Welcome changing requirements, even late in development. Short-lived PRs make a late change cheap.
• Deliver working software frequently. Most changes reach staging in an hour or two. Production deploys happen weekly at most, depending on the product, and the business decides that timing.
• Business people and developers work together daily. Product tests changes with us before merge.
• Working software is the primary measure of progress. We don’t estimate. Falsifiable acceptance criteria decide whether a task is done.
• Continuous attention to technical excellence and good design. The factory’s SDLC skills, code review, and ATDD.
• Simplicity, the art of maximizing the amount of work not done, is essential. No estimates, and only two kinds of meeting.
• At regular intervals, the team reflects and adjusts. The weekly alignment meeting covers planning, retro, and strategy.
• Face-to-face conversation. The standup and the alignment meeting, where we make decisions in conversation rather than in tickets.
• Self-organizing teams. The agent could pick its own next task from the declared dependencies and priority. We hold that choice as a human gate for now.
• Sustainable pace. Thin slices keep each piece of work small, and the factory is a queue, so work waits its turn and the pipeline doesn’t get blocked. Slow is smooth, and smooth is fast.
• Build projects around motivated individuals, and trust them. Our organization runs on high trust. Our clients trust us because we communicate, listen, and respond to what they need. So we design the tool to solve their problems, and we never make them bend their use case to fit it.

The board, and why lean is the closest name

We have a simple kanban board, and cards move across it in one direction:

backlog → needs details → to do → in progress → in review → in staging → done

A task sits in “needs details” until it’s agent-ready. In “in staging,” we test it in a lower environment before it goes to production.

The rituals are short: one standup and one weekly alignment meeting. We started the alignment meeting for a new project, and it covers planning, retro, and strategy together. Stakeholders come from all over the company to bring client and downstream customer feedback. That meeting earns its place, because it decides what we build next.

On the board side, we use kanban, but kanban isn’t really our method. Lean is the closest name, and four of its ideas describe what we do:

• Flow. A task moves across the board without waiting on a sprint boundary.
• Small batches. One task, one PR, open for minutes to hours.
• Minimizing waste. No estimates, no ceremonies we don’t need, and no long-lived branches to merge.
• Build-measure-learn. Every task is a small experiment, and its result feeds the next task.

What we don’t do: estimate

We don’t formally estimate. I know that’s unusual. Most organizations need a forecast, and a team that can’t give one is hard to plan around. If your organization needs dates, our shape won’t fit you without changes.

Instead, you get quarterly goals broken down into thin slices. The goal sets direction, and the slices keep each step small enough that a wrong step costs little. The goals, although, are forecasted so we have a general roadmap. We also accept and expect things to change as we learn more.

One open question interests me: could we estimate from data after the fact? The factory records everything, starting with the agent’s session logs. An audit log ties each business-level decision to the human who made it, for accountability and history. The factory also tracks every rule, hook, and skill invocation, so we have real evidence of which ones even trigger. With that record, we might measure finished tasks and estimate future work from data instead of from a guess up front. I don’t know whether it works. Running it against a quarter of real tasks and comparing the estimates to the results would settle it.

What stays fixed

Most of this shape will change. I expect to loosen review, rethink PRs, and maybe push to main once the foundation earns it. The focus won’t change: the ideas of agile, and engineering in software. When a rule stops serving those, the rule goes.

That’s our process with no name, one team’s shape and not a prescription. The next time someone tells you agile is dead, here’s an exception. We’re a team using AI to do more of what the manifesto asked for, with fewer rules in the way.