Agile

Software used to be ordered the way a building is ordered. The customer wrote down every feature they wanted in a requirements document, both sides signed it, the team designed and built exactly what the document described, and everything got reviewed at the very end. Doing anything the document didn't mention meant filing a change request and waiting for approval. Because the stages only ever flowed downward, one into the next, this way of working is called waterfall.

There is nothing wrong with that order in itself. When you already know precisely what has to be built, it is the safer choice. Nobody wants to move a bridge support halfway through pouring it. The trouble is that software rarely comes with that kind of certainty. Customers don't know what they want until they have used a screen, and the people building it don't know which parts are hard until they have tried to build them.

So the same conversation kept happening. Six months into a project the customer would say that having used it, the order of the steps on this screen should really be reversed. The team would answer that the change isn't in the specification, that a change request is needed, and that approval takes three weeks. Both sides are correct under the contract, and meanwhile the product spends another month heading somewhere nobody wants. Being wrong was something you discovered last, after the money and the calendar were nearly gone.

In 2001 a group of seventeen developers who all worked differently sat down and wrote out what their practices had in common. It came to four short statements, and they named the whole thing Agile. Exactly one assumption gets inverted. Instead of getting better at writing a plan and holding to it, a team gets better at noticing that the plan is wrong and changing it. That only works if finished, usable pieces come out every few weeks rather than all at the end. Usable is the load-bearing word: a design mockup or a demo that runs on one laptop does not count, because neither one produces the kind of reaction that corrects a plan. Somebody outside the team has to be able to do their actual job with the thing.

Agile stops there. It does not tell anyone how many meetings to hold or who decides what. This is why announcing that a company is adopting Agile says nothing about what will be different on Monday morning. The rules a team actually follows come from a framework one level down, such as Scrum. When people miss that split between an attitude and the rules that carry it out, they start using Agile and Scrum as if they were the same word.

The terms filed under Agile fall into four groups: where the attitude is written down, what it turns into when a team acts on it, what it was meant to replace, and where it collapses.

The written source is a single document. The Agile Manifesto, published in 2001, fits on one page and holds four values plus twelve supporting principles. Each value takes the form of preferring one thing over another — working software over comprehensive documentation, for instance. The second half is not being thrown away; the sentence only says which one wins when the two collide. Read without that qualifier, it turns into an instruction to stop writing documents, which is how a lot of teams get it wrong. The other three run the same way: people and how they talk to each other over processes and tools, working with the customer over negotiating the contract, and responding to change over following the plan. When people argue about how to work, this page is the thing to argue against.

The principles are what the attitude becomes in practice. There are four, and they split evenly: the first two decide how work is sliced, the last two decide how the team is assembled.

1. Iterative development — go over the same thing repeatedly and make it better each pass. Put up a rough search screen, add sorting the next cycle, fix the slow parts the cycle after that.
2. Incremental development — add finished, usable pieces one at a time. Ship the search screen complete, then bolt on the whole filter screen next cycle. If you think of a portrait, iterative work sketches the entire face faintly and sharpens it over several passes, while incremental work finishes the left eye before moving on. Real teams mix the two.
3. Self-organizing team — what to work on may come from outside, but the order and the method belong to the team. Hand out assignments person by person and the people next to someone who is stuck stop helping, because the authority to rearrange the plan left along with the choice.
4. Cross-functional team — every discipline needed to ship sits in one team. If product, design, and engineering report into three separate groups, releasing anything in two weeks is impossible from the start, since changing one screen requires three calendars to line up. The test is whether the team can take something from idea to customer without filing a request with anyone outside it.

The contrast group shows what Agile was pushing against, and waterfall sits there. Reading the pair as right and wrong misses the point. Where the requirements are fixed by law and will not move — a regulatory report in a mandated format, say — running the stages once in order wastes less. Agile wins on the work you have to learn your way through.

The last group collects what is left when only the form survives. Dark Agile is the term for it: the meeting names and the board came in, but nobody ended up holding the authority to change the plan. A team stands up for fifteen minutes every morning and nobody says what they are blocked on; a team runs a review every two weeks and none of the improvements it produces show up in the next cycle.

The four groups hold each other up in order. The source sets the attitude, the attitude comes down as decisions about slicing work and staffing teams, and dropping either one lands you back where waterfall was. A team that commits to shipping every two weeks but contains only engineers spends those weeks waiting on product and design, and the cycle collapses into a meeting schedule.

"Let's not design the whole thing up front — let's go agile on this. Ship whatever fits in two weeks, see the reaction, then decide."

There is no way to settle the answer before starting, so build something that produces evidence first.

"We say we're agile, but twelve features had dates on them before the quarter even started. What does the word mean here?"

Calling out a team that adopted the form without being given any room to change the plan.

"We don't run Scrum. We still work in an agile way — we ship every two weeks and revisit priorities every Monday."

Agile is not the name of a particular framework, so a team can skip the prescribed set of meetings and still qualify.

At Pagedeck the word comes up constantly around the features meant to move free teams onto a paid plan. Grace arrived before the quarter with a roadmap of twelve features, each with a date attached. Mia proposed dating only the first two and leaving the rest as an ordered list. Her evidence was the previous quarter: of the nine features locked in ahead of time, three went unused after shipping, while the thing customers asked for most often got pushed because it wasn't on the sheet.

This time Mia, Noa, and Theo worked as one team and shipped nothing but an invite screen in the first two weeks. By the third cycle they knew that what actually blocked upgrades was not the invite flow but the fact that a separate billing owner couldn't be assigned. On the original sheet that feature sat eleventh. Because only two dates had been fixed, the order could be rearranged and it got built first.

The most common reading is that Agile means working without a plan. The manifesto does say something about responding to change over following a plan, and it does put working software ahead of documentation, so the reading is understandable. In practice a team plans more often, not less. Replacing one plan that has to last eighteen months with a fresh one every two weeks means more planning conversations, not fewer. Teams that swallow this misreading end up with no ordered list at all, handling requests in the order they arrive, and three months later nobody can explain what was built or why. What Agile discarded was not the plan but the assumption that a plan cannot be changed. A rough order for the next six months and a firm commitment for the next two weeks can coexist, and most teams that work this way keep both.

The second reading is that Agile is a way to build faster. Short cycles sound like speed, and speed is usually the first argument anyone makes for adopting it. Building a given feature still takes as long as it takes. What gets shorter is the time between going in the wrong direction and finding out. Learning it after three weeks instead of eighteen months means throwing less away — the hands did not get quicker. Organizations that believe otherwise cut the cycle from two weeks to one and double the number of meetings. Pressure goes up, output doesn't, and the team starts slicing work small enough to look finished inside the cycle. The honest version of the claim is narrower: a team that ships every two weeks wastes less of the year building the wrong thing than a team that ships once.