Agile and Iterative Development: A Slice Through Every Layer

Contents10 sections

Agile is a toolbox held together by a few ground rules, and the rule that carries the most weight is that every piece of work cuts through the whole stack and ends in something a person can watch running. AI-assisted development speeds up the part of the loop that was rarely the slow part, and the pressure moves onto review, testing and the demo.

What agile is

Agile is a way of building software in short loops. Each loop ends with working software that somebody outside the team can look at and judge. The name comes from the Manifesto for Agile Software Development, a one-page statement written and signed in 2001, and its four values are short enough to quote whole:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Then comes the sentence most people skip: "That is, while there is value in the items on the right, we value the items on the left more." Most of the misreadings in the next section start where that sentence got dropped. Terms are explained where they first appear, and the glossary at the end collects them.

Two words travel with agile, and they mean different things. Iterative development goes around the same loop again and again: plan a little, build a little, check the result, adjust. Each pass corrects the last. Incremental development adds a piece the product didn't have before. An agile team does both at once, so every loop adds a working increment and every loop is a chance to change course.

The principles behind the manifesto set the pace: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." They also name the yardstick. "Working software is the primary measure of progress." That line is the spine of this piece; the tools are all negotiable, and the yardstick holds.

It's also the line that AI-assisted development strains hardest. An AI coding agent is a language model that can read a repository, write code and run commands on its own. It can produce a plausible change in minutes. The Collective's own build has run at about 500 merged pull requests a month across nine repositories, with one developer directing a team of agents, and a pull request is a proposed change to the code waiting for someone to review and merge it. Agile's loop was tuned for people typing the code. Once typing stops being the slow step, the ground rules still hold. What moves is where they bite.

What agile gets mistaken for

The misreadings are worth naming one at a time, since each one has a cousin in how AI is being adopted now.

Agile is mistaken for working without a plan. Agile teams plan constantly. They plan in smaller pieces and closer to the work, so a plan can be wrong for a week rather than for a year. There's a roadmap for the quarter and a backlog, the team's list of work still to do, ordered by value. There's a plan for the next two weeks and a plan for the day. What agile drops is the plan that claims to know month nine on day one.

It's mistaken for skipping documentation. The manifesto ranks working software above comprehensive documentation, and in the same breath it says the documentation still has value. Teams write what somebody will actually read: an interface contract, a decision record, the runbook that tells the on-call engineer what to do at three in the morning.

Agents raise the stakes. An agent starts every session knowing only what's written down. The team's instructions file, its acceptance criteria and its architecture notes are now inputs a machine reads every day, and a stale one steers every change it touches. The Collective's earlier piece on designing a CLAUDE.md file covers that instructions file in detail.

It's mistaken for a meeting schedule. The daily stand-up is a tool for running the loop. So are sprint planning, the review where work is shown, and the retrospective where the team looks at its own process. A team can hold every one of them on time — every stand-up, every review — and still ship nothing anybody can watch running. At that point it has agile's calendar and no loop inside it.

It's mistaken for Scrum, or for the ticketing tool. Scrum is one framework among several, and Jira is a product. Both can serve an agile team. Both can also sit on top of a two-year waterfall with sprints painted on it.

It's mistaken for speed. Agile shortens the time it takes to find out whether the team is building the right thing. A single feature can take longer, since every slice has to be finished, tested and shown before it counts. Agile was sold for years as faster delivery, and AI is being sold the same way now.

The data so far says to be careful. Google's DORA programme (DevOps Research and Assessment) reported in October 2024 that, as AI adoption increased, delivery throughput fell by an estimated 1.5 percent. Delivery stability fell by an estimated 7.2 percent, nearly five times as much. DORA's own reading was that a better development process doesn't automatically improve delivery without "the basics of successful software delivery, like small batch sizes and robust testing mechanisms." Those are agile's basics.

Speed was always a side effect of short loops and small batches. The loop is what the ground rules protect.

A toolbox with a few ground rules

Agile works as a toolbox. Several frameworks fill it, each one a bundle of practices that fit together:

• Scrum runs the work in sprints, fixed-length cycles that the 2020 Scrum Guide caps at "one month or less." Each one ends in a usable increment and a review.
• Kanban runs the work as a continuous flow across a board. It caps how many items can sit in each column at once, and the cap is called a WIP limit, for work in progress.
• Extreme Programming (XP) supplies the engineering practices. Test-driven development writes the test before the code. Pair programming puts two people on one change. Continuous integration builds and tests every change automatically as it lands, and releases stay small and frequent.
• Lean contributes the habit of cutting waste, and of watching how long work sits idle between steps.

A team picks the tools that fit its work. A support team handling a stream of tickets may run pure Kanban. A product team may run two-week sprints with XP's practices inside them, and a team in a regulated industry adds heavier review gates and keeps its sprints anyway. All of these are agile. From the outside they look nothing alike.

What makes them agile is a short set of ground rules that every one of them keeps:

1. Work in short loops that end in feedback. The loop is days or weeks long. It closes when somebody outside the team has seen the result.
2. Cut every piece vertically. Each piece of work runs through every layer of the system it needs, so it works on its own.
3. Done means usable and verified. The 2020 Scrum Guide calls this the Definition of Done: "a formal description of the state of the Increment when it meets the quality measures required for the product." Work that misses it doesn't count.
4. Show it working, and tie it to something that matters. Every delivered piece is demonstrable. The demonstration traces to value for a customer, and from there to a goal the company holds.
5. Inspect and adapt. The principles put it this way: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Everything else is a tool, and a tool earns its place by serving one of those five. Table 1 maps the common ones to the rule each serves, with a column for what AI agents change.

Table 1. Twelve common agile tools, the ground rule each one serves, and what AI agents change about it.

Read down the last column and a pattern shows. The tools that count how much was produced are the ones AI breaks. The tools that check whether the result works (and whether anyone wanted it) are the ones AI leans on hardest.

Building vertically through the stack

A software system is built in layers, usually called the stack. A typical web product has a user interface on top and an API under it, the application programming interface the screen calls. Business logic sits under that, and a database at the bottom, with deployment and monitoring wrapped around the whole thing.

There are two ways to cut work against that stack. The horizontal cut builds one layer at a time: the database in the first sprint, the API in the second, the screens in the third. The fourth sprint joins them up. For three sprints there's nothing a customer could use, and every layer was designed against a guess about layers that didn't exist yet. The guesses meet in sprint four — which is usually where the project finds out what it got wrong.

The vertical cut builds one thin capability through every layer at once. Take "a customer can see the status of an order." That slice needs one field on one screen and one API endpoint, one query and one column in one table. It needs a test at each layer, and a deployment that puts it in front of somebody. It's small, and it's real. The next slice might be "the customer gets an email when the status changes," which adds a trigger and a message and reuses everything else.

Cutting vertically pays off in four places. Integration problems surface in the first week instead of the last month. Feedback arrives on the real thing. Every slice could ship, so the project always has something of value if it stops early. Reordering the backlog costs almost nothing, too, because no half-built layer is left waiting for its partners.

Slicing well is a skill, and most of it is finding the thinnest version that still works. Common cuts take one step of a workflow, one kind of data, one business rule, or the plain path before the exceptions. A piece of work that touches only one layer is a task. Tasks are fine inside a slice; they just don't count as delivery on their own.

AI agents make this rule matter more. An agent asked for "the data layer" will build the whole data layer, quickly and tidily, with tables for screens nobody has designed. A vertical slice gives the agent a boundary: one capability, an acceptance test that defines done, and a demo at the end. Handed to an agent, a well-cut slice is a prompt that carries its own finish line, and anybody can check whether the agent crossed it.

Everything delivered is demonstrable

Every slice ends in a demonstration, and the demonstration can take many forms. A new endpoint is shown with one call from a terminal. A reporting change is shown as the report. A performance fix is shown as the timing before and after, and a security fix as the scan that used to fail and now passes. Even pure infrastructure can be shown. The deployment that used to need a person runs on its own, and the demo is watching it run.

Every demonstration also points somewhere. It sits at the bottom of a short chain. The chain runs from the slice to an outcome a customer would notice, then from that outcome to a goal the company has actually set: keep more customers, cut the cost of serving one, pass the audit, open the new market. Scrum's sprint goal, the one objective a sprint is planned around, is the link in the middle. A slice that can't be traced up that chain invites a fair question about why it's in the sprint. Sometimes the honest answer is that it shouldn't be.

Built this way, a sprint review is evidence. The 2020 Scrum Guide gives its purpose as "to inspect the outcome of the Sprint and determine future adaptations." The outcome is something running, in front of the people who asked for it, and they react to the real thing. That reaction is why the loop exists.

AI changes what a demo can fake. An agent can produce a convincing demonstration of something wired to nothing at all — scripted outputs, canned data, an integration that returns the same answer every time. The Collective's early demo of MARA (Medical Agentic Resident Assistant), the healthcare assistant being built on its MAX core, shows the honest version. It was published in September 2026. Its integrations are stubs and its AI outputs are scripted, and the demo says so on its face. That's MAX's rule that unfinished code announces itself as a stub, applied to a demonstration.

A demo for an agile review needs one of two things: the real slice running against real data, or a plain statement of what's simulated. Anything else is a mock-up presented as delivery. An agent can build one of those faster than anyone can check it.

What AI changes about velocity

In agile practice, velocity is the amount of estimated work a team finishes per sprint, usually counted in story points. A story point is a relative size the team gives a piece of work, calibrated against its own past work. Velocity is a planning tool for one team. It answers how much to take on next sprint, and it was never meant for comparing teams, a use that distorted it long before AI arrived.

Agents finish the job. A story sized at five points because it would take a person two days may take an agent twenty minutes to draft. Velocity spikes. It measures nothing anybody needs, because the points were a proxy for human effort and the effort has moved.

MAX, the Collective's own project, shows the scale. It's a local-first AI assistant that runs on one machine, and one developer builds it part-time with agents doing most of the writing. In one month that arrangement opened 350 pull requests on MAX alone, close to a dozen a day. Nobody reads that many pull requests closely.

Felt speed and measured speed disagree, too. In a July 2025 study by METR, an AI research group, 16 experienced open-source developers worked 246 real tasks in projects they knew well. With AI tools allowed, the tasks took 19 percent longer. The developers had expected a 24 percent speed-up beforehand, and afterwards they still believed AI had made them about 20 percent faster. METR has since marked those results as out of date. In February 2026 it said developers were likely getting more of a speed-up from newer tools than in early 2025; its fresh data, it added, was "only very weak evidence" of how large the increase was. For an agile team both results carry the same instruction, which is to measure the loop. The impression of speed was wrong once and may be wrong again in either direction.

DORA's 2025 report found the relationship moving. Higher AI adoption now went with higher delivery throughput, and delivery instability kept rising anyway. The report calls AI "an amplifier" that magnifies "the strengths of high-performing organizations and the dysfunctions of struggling ones." A team with short loops, thin slices and a strict Definition of Done gets more of those. A team without them gets more of what it already had.

So the measures shift from output to flow. DORA's four classic measures are worth keeping: how often the team deploys, how long a change takes from commit to production, what share of changes fail, and how long recovery from a failed deployment takes. Two agile measures sit beside them, and AI doesn't inflate either one. The first is the lead time from an idea entering the backlog to its demonstration in a review. The second is the queue of work that's written, finished and waiting for a person to check it.

That queue is where the constraint now sits. Kanban already has the tool for it — a WIP limit on the review column. When agents can fill the review queue faster than people can empty it, the limit stops new work from starting. Sprint capacity gets planned in reviewer-hours and acceptance-hours.

What AI changes about quality

Quality in agile has always rested on the Definition of Done, and on people reading each other's work. At a dozen pull requests a day, the second half breaks. So the Definition of Done has to be enforced by code: tests on every change, continuous integration that blocks a merge when a test fails, and security scanning. Mutation testing belongs on that list as well. It plants small bugs in the code on purpose and checks that the tests catch them. The Collective's build has run more than 31,000 continuous-integration runs to check its work.

Review by another AI helps, and it's uneven. When the Collective measured its own AI reviewers, they answered anywhere from 7 to 100 percent of the review requests they were sent. One paid service answered 60 of 822; a free one answered all 420. On a busy board, a review that never arrives looks exactly like a clean one. Silence reads as approval. The Collective's earlier piece on AI code review argues that the model that wrote a change is a poor judge of it, so the second reader should be a different one.

Tests move to the front. Test-driven development was always good discipline, and with agents it becomes the main control. A test written from the acceptance criteria before the agent starts is a specification the agent can't argue with. The person writes what done means. The agent works until the test agrees.

Watch for a status that reports health it never checked. The Collective's "False Green" piece found it to be the recurring high-value catch across three AI reviewers and four repositories. Agents produce green checks at volume, and some fraction of them are this kind. The fix is a line MAX's code holds to: "could not look" is never reported as "nothing there."

Ownership stays with a person. An agent can draft, test and propose. Somebody on the team still accepts the slice, and somebody still stands in the review and says it's what the customer needed.

Bringing AI into the loop

Agents fit into agile the way any new contributor does, under the same ground rules and the same Definition of Done. The ground rules stay as they were. What changes is mostly where people spend their time.

People keep the backlog, the acceptance criteria and the demonstration. Agents take slices, one capability per task, with the acceptance test written first. Every agent pull request links to the slice it serves and carries the evidence that it works. The reviewer starts from the demo and works back to the diff, the line-by-line change itself. The review column carries a WIP limit, and sprint capacity is set by how much the people can check and accept. Sprints may get shorter and slices thinner, since an agent can carry a small piece through the stack in a day.

Retrospectives gain a subject. The team looks at what its agents got wrong and writes each failure class down, with the check that now prevents it. MAX keeps that record as a failure registry. It held 276 entries when the Collective last published on it, each one a bug class that reached a person, written down with its cause and its check. The team's instructions file is the other half of the record: a working agreement written for a contributor that reads it at the start of every session and remembers nothing else.

Then the sprint review happens, as it always did. People sit in a room with a running system and the customer who asked for it, and a slice does what it was cut to do. Agents can bring more slices to that room each week than a team of people ever could. The room still decides which ones count.

Sources

• The Manifesto for Agile Software Development, 2001, and its twelve principles, read 18 October 2026.
  • agilemanifesto.org
  • agilemanifesto.org · principles
• The 2020 Scrum Guide, November 2020, for the sprint length, the Increment, the Definition of Done and the purpose of the Sprint Review.
  • scrumguides.org · scrum guide
• Google Cloud, Announcing the 2024 DORA report, 22 October 2024, for the throughput and stability estimates and the note on small batch sizes and testing.
  • cloud.google.com · announcing the 2024 dora report
• Google, DORA 2025 State of AI-assisted Software Development Report, for the amplifier finding, and InfoQ's summary of the report, 29 September 2025, for throughput and instability.
  • research.google · dora 2025 state of ai assisted software development report
  • infoq.com · dora state of ai in dev 2025
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 July 2025, and its February 2026 update.
  • metr.org · 2025 07 10 early 2025 ai experienced os dev study
  • evals.alignment.org · 2026 02 24 uplift update
• The Collective's figures for merged pull requests, continuous-integration runs and reviewer answer rates are from "What Building With AI Really Costs: The Whole Bill" (October 2026).
• The MAX pull-request count, the failure registry, the "could not look" rule and the MARA demo are from "MAX: The AI Resident, and the Road to MARA" (October 2026).
• The review findings are from "False Green" (July 2026) and "The AI Code Review Problem: Why the Same AI That Writes Your Code Can't Review It," and the instructions file is covered in "How to Design a CLAUDE.md That Actually Works." All are on www.maxresearchcollective.com.

Glossary