Welcome

Agile was built for software where the unknowns are mostly about user needs and the implementation is mostly knowable. AI projects invert that: user needs are often clearer (a support team wants faster ticket triage), but the implementation is genuinely uncertain. You don't know whether the model will hit accuracy targets, how data quality will affect results, or what edge cases will emerge in production. That mismatch causes naive agile to break: sprints commit to features that depend on experimental outcomes that haven't been measured yet. This chapter covers what to keep, what to drop, and what to add when you adapt agile to AI work.

Why Vanilla Agile Breaks for AI

Three specific frictions show up. First, sprint commitments assume outcomes are mostly a function of effort. AI work has a meaningful component that is a function of nature, does the data support the task, can the model learn the pattern? You can put in two weeks of disciplined effort and produce a result that is too poor to ship, with no fault to the engineers. Sprint review meetings turn awkward when the answer to 'did we hit the goal?' is 'we ran the experiment and learned the goal was unrealistic.' Second, story points calibrated for software don't capture the variance of AI tasks. A single 'integrate model into endpoint' card might be a one-day task or a three-week one depending on what eval scores reveal halfway through. Third, definition-of-done assumes binary completion. AI features ship at a quality level, 78% accuracy, 91st percentile latency, and the business question is whether that level is good enough now versus continuing to iterate. The framework needs explicit handling of partial wins. Diagnosing whether your team is feeling these frictions is straightforward: if retrospectives keep producing the complaint 'we didn't hit the sprint goal because the model didn't perform,' your agile process is fighting the AI work instead of structuring it.

What to Keep from Agile

Several agile practices port cleanly to AI work and are worth keeping. Short feedback loops are non-negotiable: the right cadence for most AI teams is one or two weeks, with end-of-cycle demos that show the actual model behavior, not just code merged. Cross-functional teams (engineers, ML engineers, product, domain experts) outperform handoff-driven structures because so much AI work depends on rapid hypothesis testing where domain feedback matters. Visible work-in-progress on a kanban board still works; just expect cards to flow at irregular speeds. Retrospectives still earn their keep, but the questions shift: 'what did we learn that changes our model of the problem?' becomes as important as 'what slowed us down?' User stories remain useful for product framing, with the caveat that AI features need acceptance criteria expressed as quality bands ('triage suggestions accurate ≥80% with ≤15% false-positive rate on the held-out evaluation set') rather than binary check-boxes. Continuous integration extends naturally to continuous evaluation: every change runs an evaluation suite alongside the test suite, and regressions block merges as cleanly as failing unit tests.

What to Add for AI Work

Three additions earn their keep. First, an explicit experimentation track parallel to the delivery track. Each sprint includes both 'we will ship X' (deterministic delivery work) and 'we will run experiment Y to determine Z' (research work whose outcome shapes future commitments). Treat experiments as first-class artifacts with hypotheses, success criteria, and time-boxes, without this discipline, research work expands to consume all available time. Second, an evaluation suite that is itself a deliverable. The team's most valuable asset is often not the model but the eval harness that determines whether any candidate model is good enough. Invest in evals as production-grade code: version-controlled, peer-reviewed, with documented limitations. Third, a 'graduation' protocol that defines how a prototype moves through stages, exploratory notebook → reproducible script → tested service → production endpoint, with quality gates and reviewers at each transition. Most AI failures occur when work skips a graduation step, going from notebook to production with hidden assumptions about data shape, latency, or failure handling that surface only at scale. The protocol should be lightweight enough to feel like a tool, not a tax.

The Iteration Cadence That Works

A pattern that holds across many AI teams: a two-week cycle anchored by an end-of-cycle review where the team demonstrates working AI behavior against the evaluation suite, not slides about progress. Within the cycle, daily 15-minute syncs focused on blockers (skip status reporting), a midpoint check on whether experiments are producing usable signal, and explicit reservation of the final two days for evaluation runs and writeup. The cycle ends with three artifacts: a metrics-driven status of the eval scores compared to baseline; a list of decisions that the cycle's results enable (e.g., 'we now know retrieval-augmented inference outperforms fine-tuning on this dataset, so the next cycle commits to RAG'); and a list of learnings worth documenting in the post-mortem archive. Cadence longer than three weeks loses urgency; shorter than one week starves experiments of signal. Quarterly planning happens at a coarser level, the team commits to a small number of strategic bets ('reduce hallucinations on legal corpus' rather than 'achieve 89% accuracy') and revises commitments at the end of each cycle based on what was learned. Keep quarterly plans short, one page per bet, so they can be honestly updated rather than fictionally maintained.

Managing Uncertainty and Risk

AI projects fail predictably along a small number of axes: data quality (the dataset doesn't support the task at the required quality), model capability (the available model architecture can't reach the accuracy bar), latency (the model runs but is too slow for the use case), cost (acceptable performance requires per-call costs the business can't absorb), failure mode (the model has tail behaviors that violate user trust or compliance), and adoption (the deployed system works technically but users don't change behavior). De-risk early by sequencing experiments in order of which failure mode would most cleanly kill the project. Cheap kill-switch experiments belong at the front of the project: spend three days probing data quality before committing eight weeks to architecture. Make the kill-switches public, share them with sponsors so the project's failure paths are explicit and unsurprising. The worst project posture is one where the team confidently reports 'on track' on an eight-week project that has been quietly stalled on a data-quality issue from week one. Visible risk registers that name the failure modes and their current status produce earlier escalations, more honest conversations, and less wasted runway.

Common Anti-Patterns

A few recurring failure modes are worth naming so teams can spot them. Sprint scoping by guessing model performance before any experiment runs, produces false commitments and demoralized teams. Ceremony hypertrophy, trying to retrofit standard scrum ceremonies onto research work creates theater; cut what doesn't earn its keep. The 'demo gap', teams that demo polished UI prototypes without showing model behavior on real evaluation data create the impression of progress that evaporates at production. Over-investing in tooling before validating the core problem: pipelines, MLOps platforms, and evaluation infrastructure should grow as the project matures, not be built up-front for a use case that may not survive a kill-switch experiment. Conversely, under-investing in evaluation, most teams know they should evaluate; few invest until the inability to evaluate becomes a gating crisis. Build evaluation discipline before you need it, even if it feels like overkill. Finally, treating the model as the product when the product is actually the surrounding workflow: the highest-leverage AI work is often the prompt template, the retrieval strategy, the human-in-the-loop fallback, or the data preparation pipeline, not the model itself.

Key Takeaway

Adapted agile for AI keeps the parts that produce alignment and feedback (cross-functional teams, short cycles, retrospectives, demos) and adds the parts that handle uncertainty (parallel experimentation track, evaluation as a deliverable, graduation protocol, explicit risk registers). The cadence that works for most teams is two-week cycles with eval-anchored reviews, decision artifacts at the end of each cycle, and quarterly planning expressed as strategic bets that are honestly revised based on what's been learned. The discipline is the framework: name the experiments, name the failure modes, evaluate against shared criteria, and treat learning as a first-class output rather than a side effect. Three habits separate teams that thrive from teams that flail: (1) a written hypothesis and success criterion attached to every experiment before it starts; (2) a single shared evaluation suite that is treated as the team's most important artifact and protected from drift; (3) a leadership stance that rewards changing direction based on evidence rather than punishing it as 'failure to deliver.' Without these, even well-designed processes degrade into ceremony. With them, even imperfect processes produce learning that compounds across cycles.

What Comes Next

Iteration produces uncertainty for stakeholders who are used to deterministic project plans. The next chapter, Stakeholder Management & Expectations, addresses how to communicate honestly with sponsors, executives, and affected teams about AI work whose outcomes are inherently probabilistic, without either over-promising or hiding behind hedged language. Before moving on, audit your own team against the practices in this chapter: do you have a parallel experimentation track, written hypotheses, an evaluation suite under version control, a graduation protocol from prototype to production, and a risk register that names failure modes? If three or more of these are missing, the next iteration of your process is more important than the next iteration of your model.