14.4 — How the Work Gets Organised

A team runs a two-week sprint, a daily stand-up, a planning session, a review and a retrospective. They estimate in story points, track velocity, and burn down a chart.

They ship to production every six weeks, because the release process is manual and the change board meets monthly.

They have every ceremony and none of the benefit. The point of short iterations is short feedback, and feedback arrives when a user touches the software — not when a sprint ends. This chapter is about telling the two apart.

1. What Agile actually said

The 2001 Manifesto is four comparisons, and it is worth reading exactly because the industry version differs:

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

That is, while there is value in the items on the right, we value the items on the left more.

That last line is omitted constantly, and it is what stops the manifesto meaning "no documentation" or "no plan".

What the industry calls Agile is mostly Scrum plus a certification industry. Some of it is genuinely useful, and some is the exact opposite of the manifesto — a heavier process, with more tools, tracked more closely. The useful question about any practice is: does this shorten the loop between doing something and finding out whether it worked? If not, it is ceremony.

2. Waterfall, honestly

Requirements, design, implementation, verification, maintenance — each phase completing before the next.

Two facts people get wrong. Winston Royce's 1970 paper, always cited as its origin, presented the sequential model and then argued it was risky, recommending iteration and prototyping. And waterfall genuinely works in some contexts: where requirements really are fixed and knowable, where change is expensive after the fact (hardware, construction), where a regulator requires documented up-front design, and where the contract fixes scope and price.

Where it fails is software with uncertain requirements, which is most software — because the expensive mistakes are in understanding the problem, and you discover those only by building something and showing it to someone.

The real distinction is not iterative versus sequential; it is how quickly you learn you were wrong.

3. Scrum

Roles: a product owner who owns priority, a scrum master who owns the process and removes obstacles, and the developers.

Artefacts: a product backlog (everything, ordered), a sprint backlog (this iteration's commitment), and an increment (working software).

Events: a sprint of one to four weeks, planning at the start, a daily stand-up, a review with stakeholders, and a retrospective on how the team works.

Two agreements that do most of the work: a definition of done (what "finished" means — reviewed, deployed, documented, monitored) and a definition of ready (what a piece of work needs before it is picked up). A team without a definition of done has stories that are "done except…" indefinitely, which is where sprints quietly stop meaning anything.

What Scrum is good at: a regular cadence for showing work to stakeholders, a forced conversation about priority, and a retrospective that makes process change routine.

Where it goes wrong, and these are the common ones:

Sprints become mini-waterfalls — plan, build, test, and everything lands on the last day. The fix is smaller stories, not a longer sprint.

Velocity becomes a target. Section 5.

The scrum master becomes a manager, so the retrospective stops being a place where anything is said.

Retrospectives with no actions. The same complaint every fortnight is not a retrospective, it is a ritual. One action item with an owner beats twenty observations.

The stand-up becomes a status report to a manager. Its purpose is coordination between the people doing the work — what is blocked, who needs help — and if that could be a written update, it should be.

4. Kanban, and what most teams actually run

Kanban is flow, not iterations. Visualise the work, limit work in progress, measure and improve flow.

The work-in-progress limit is the whole idea, and it is counter-intuitive: stopping people starting new work makes the team finish faster. Queueing theory (Chapter 10.12) says the same thing — high utilisation means long queues. In practice, a WIP limit forces the team to help finish something before starting something else, which is what turns five half-done features into two shipped ones.

Metrics that follow: cycle time (start to done — the number that matters), throughput (items per week), and a cumulative flow diagram, where a widening band shows exactly which stage is the bottleneck.

Kanban beats Scrum when work is interrupt-driven — operations, support, platform teams — because a sprint commitment is meaningless if a production incident arrives on day two.

Most effective teams run a hybrid: a regular planning conversation and a retrospective from Scrum, continuous flow with WIP limits from Kanban, and no pretence that the sprint boundary is a release boundary. That is fine. The framework is a starting point, not a standard to comply with.

5. Estimation, and what a point is

Why estimate at all: to forecast roughly, to decide whether something is worth its cost, and — the most valuable reason — because the conversation surfaces disagreements about scope. Two engineers estimating 2 and 13 have understood the task differently, and finding that out is worth more than the number.

Why estimates are wrong: the planning fallacy (people systematically underestimate), unknown unknowns, and the fact that a novel task's duration is not knowable in advance. Software estimation error is routinely a factor of two or more, and no technique removes it.

Story points are relative size, not hours. The claim is that humans compare better than they measure: "this is about twice that one" is more reliable than "this is fourteen hours".

Fibonacci-like scales (1, 2, 3, 5, 8, 13) exist to force distinction. Between 8 and 13 you must choose; between 8 and 9 you would argue pointlessly. The gaps encode the growing uncertainty of larger estimates.

Reference stories are what make points mean anything. "This is like the export feature, which was a 5." Without shared references, a point is a private unit and cross-team comparison is meaningless — which is why comparing velocity between teams is not just unhelpful but incoherent.

Velocity is a capacity signal for the team, and nothing else. Points completed per sprint, useful for the team's own forecasting.

And Goodhart's law is the thing to internalise: when a measure becomes a target, it ceases to be a good measure. Make velocity a target and it rises — through inflated estimates, split stories, and skipped quality work. The number improves and the delivery does not, and every team that has been managed on velocity has demonstrated this.

The honest alternative that works surprisingly well: count items and forecast probabilistically. Take the team's throughput over the last ten weeks, and run a Monte Carlo simulation for "how many items in six weeks". This produces a forecast with a confidence range, needs no estimation at all, and empirically forecasts about as well as pointing — because throughput already includes the variation that estimates try to predict.

Cycle time percentiles are the other useful number: "85% of items finish within nine days" is a far more actionable statement to a stakeholder than a story point total.

6. What changed with AI assistance

Coding assistants meaningfully changed the shape of the work, and being precise about what changed avoids two bad reactions.

What shrank: writing boilerplate, first drafts of well-understood code, translating between languages, writing scripts, and reading unfamiliar code. The typing part of the job.

What did not shrink: understanding the problem, deciding on a design, integrating with the existing system, debugging something subtle, reviewing, and coordinating with other people. On most non-trivial work these were always the majority of the time.

Three consequences for delivery:

Estimates need re-baselining, unevenly. A story that was mostly typing is now much smaller; one that was mostly design and integration is unchanged. So old reference stories are wrong in a way that varies by task type, and a team's point scale drifts until the references are redone.

Review becomes the bottleneck. More code is produced, and it still needs the same human understanding — and generated code needs more review, not less, because the author has less context on it than if they had written it. Chapter 14.7 covers making review effective.

Output metrics get worse, not better. Lines of code and pull request counts were always poor measures and are now actively misleading. Measure outcomes — cycle time, change failure rate, whether the thing worked — not volume.

7. Jira in practice

Whatever the tool, the structure is the same: issue types, workflows (statuses and permitted transitions), and hierarchy (epic → story → sub-task).

JQL is worth twenty minutes, because it turns the tool from a form into a queryable system:

project = PLAT AND status != Done AND assignee = currentUser() ORDER BY priority
project = PLAT AND created >= -14d AND type = Bug

Automation rules remove the administration nobody enjoys: transition on a linked pull request, notify on a stale ticket, assign by component.

The anti-patterns, all of which are common:

Thirty custom fields, most empty, because someone once wanted a report.

A workflow with eleven statuses, several of which mean the same thing to different people. If nobody can name what "In Review" versus "Ready for Review" means, the workflow is wrong.

Time tracking that nobody trusts, where hours are entered retrospectively to satisfy a report.

Tickets as the only record of a decision. A comment thread is not documentation; the decision belongs in a design document (Chapter 14.7).

The test for any field: does someone make a decision from it? If not, delete it. Process weight should be proportional to the cost of getting it wrong, and most teams carry weight inherited from a context that no longer applies.

8. Measuring delivery

The DORA metrics are the most evidence-backed set available:

• Deployment frequency — how often you release.
• Lead time for change — commit to production.
• Change failure rate — what proportion of releases cause a problem.
• Time to restore — how long recovery takes.

The important finding is that the first two and the last two are not a trade-off. Teams that deploy frequently also have lower failure rates and recover faster, because small changes are easier to verify, easier to diagnose and easier to reverse. "Move fast or be stable" is a false choice, and this is the data that says so.

And the essential caution: these measure a system, not a person. Applied to individuals they become a target and Goodhart takes over. The SPACE framework exists to make the same point — that developer productivity has several dimensions (satisfaction, performance, activity, communication, efficiency) and no single number captures it.

What actually makes teams fast, and none of it is a framework:

• Small batches. The biggest lever, and it improves everything downstream.
• Short feedback loops — fast pipelines, fast reviews, real users early.
• Low work in progress.
• Deployment automation, so releasing is not an event.
• Psychological safety — the ability to say "I do not understand this" or "I think this is a mistake". The most consistent finding in the research on effective teams, and the least amenable to a process change.

Recall

• The Manifesto's four comparisons end with "while there is value in the items on the right" — the line that stops it meaning no documentation and no plan. The useful test of any practice: does it shorten the loop between doing something and learning whether it worked?
• Royce's 1970 paper argued against the sequential model it is cited as inventing. Waterfall works with genuinely fixed requirements; it fails where the expensive mistakes are in understanding the problem.
• Scrum's real value is a definition of done and ready, a priority conversation, and a retrospective that produces one action with an owner. Its failures: sprints as mini-waterfalls, stand-ups as status reports, and velocity as a target.
• The work-in-progress limit is Kanban's whole idea — stopping people starting makes the team finish faster. Cycle time is the number that matters, and a cumulative flow diagram shows the bottleneck.
• Story points are relative size anchored to reference stories, which is why cross-team velocity comparison is incoherent. Goodhart: make velocity a target and it rises while delivery does not.
• Counting throughput and forecasting with Monte Carlo works about as well as estimating, needs no points, and produces a confidence range. Cycle time percentiles are the most actionable number for a stakeholder.
• AI assistance shrank typing, not understanding, design, integration, debugging or review — so reference stories drift unevenly and review becomes the bottleneck, and output metrics like lines or pull requests get actively worse.
• DORA: deployment frequency, lead time, change failure rate, time to restore — and speed and stability are not a trade-off. They measure a system, not a person. Small batches, short feedback, low WIP, deployment automation and psychological safety are what actually make teams fast.

Self-test: Which line of the Manifesto is most often omitted, and what does it prevent? · What does a work-in-progress limit actually do? · Why is comparing two teams' velocity meaningless? · What forecasting method needs no estimates at all? · Which parts of the job did coding assistants not shrink? · Why is "move fast or be stable" a false choice?

Next: 14.5 turns to making software fast — how to measure before optimising, what a flamegraph is telling you, and why benchmarks lie more often than they inform.