Don't Panic — Agile Software Development

The word has had a rough couple of decades. It now routinely names the things it was written against: a fixed plan, a certification path, a recurring meeting nobody can cancel. Underneath all that there is one small idea, and it is testable.

Cut a slice of product small enough to be usable, and put it in front of somebody qualified to judge it. What comes back decides what gets built next.

That is the entire feedback loop, and the honest test of whether a team has one is a single question: can what came back still change the next decision? Where it cannot, the meetings run to schedule and nothing is learned. Working software is the unit of evidence because it is the only kind a stakeholder cannot argue with.

The value system arrives from a one-page document written in 2001, which puts four things ahead of four others: people and their collaboration ahead of processes and tools, software that runs ahead of exhaustive documentation, working alongside a customer ahead of negotiating with one, adapting ahead of conforming to the original plan. The half everyone drops is that the losing side of each pair still has value — a preference decides which wins in a genuine conflict, it does not outlaw anything. So none of this argues against planning, documentation or design; the principles tie agility to technical excellence and good design in as many words.

Under the umbrella sit frameworks with different engines. Scrum works through cadence: a Sprint of a month or less, an ordered list of what the product might need, and an increment that counts as done only once it meets the team's agreed standard for finished.

Kanban works through flow instead. Cap how much is in progress at once so new work starts only as capacity frees up, then watch how long items take and how old the unfinished ones are getting. Neither is a more advanced version of the other.

Here is the part worth arriving with: the cadence is not the loop. A two-week sprint ending in one four-thousand-line merge has a feedback period of two weeks. A team shipping forty times a week has one measured in hours, whatever the calendar says.

Iteration length is a whiteboard decision anyone can make on a Monday morning. Batch size — how much change travels together — is an engineering property, bought with test coverage, deployment automation and an architecture that can be cut into slices. Only the second is genuinely inside the loop.

When a loop stalls, the cause usually sits above the team rather than inside it. Immaculate iterations can run inside an organisation that funds annually and approves quarterly, producing evidence nobody is positioned to act on. The diagnostic is to count how many people must say yes before a one-line fix reaches users — a number no rearrangement of meetings can improve, which is exactly why it is worth watching.

The Slides set Scrum and Kanban beside each other, the quickest way to see they answer different questions. Intro for the loop in full. Field Notes for what happens once an organisation is attached.