The Code's the Thing

The Code's the Thing

Fri 22 May 2026

Sat thinking about management, technology and organisations, which is rarely a good sign.

Specifically, I was thinking about the old argument between waterfall and agile, and all the management furniture that sits around it: ITIL, PRINCE2, ISO 27001, risk logs, control spreadsheets, governance packs, delivery boards, project plans, dependency maps, steering committee decks.

A lot of these things exist to create certainty about the world. Or at least to make uncertainty small enough that someone can pick it up, own it, and carry it out of the room as an action.

Waterfall does this by trying to describe the thing before the thing exists. Agile, when it works, does something different. It tries to make the thing exist as early as possible - as working software.

Documentation as control

There is a tendency in management to treat documentation as a way of controlling the future.

Write the requirements down. Produce the plan. Fill in the RAID log. Agree the milestones. Map the stakeholders. Define the operating model. Review the service transition checklist. Put it all somewhere SharePoint can slowly digest it.

None of this is inherently bad. Documentation is often necessary, especially once a team boundary is crossed. A small project team can get away with shared context because people are talking every day. They update each other constantly. They notice when someone has misunderstood something. They can point at a thing and say, "No, not that bit, this bit."

But outside that small circle, mental models do not travel very well. A user story might be a placeholder for a conversation, but that only works if the conversation can still happen. The minute you need to hand something to another team, an auditor, a support function, a supplier, or yourself six months later, the placeholder starts to look a bit thin.

So we write things down.

The problem starts when the document becomes the main artifact rather than a supporting one. At that point, we are no longer documenting the work. We are hoping the document can substitute for the work.

What agile actually learned

The thing that gets missed about agile is that the useful bit was not "have more conversations" or "put things on sticky notes".

Agile that really worked came out of extreme programming. And the point of extreme programming was that you had working software from the beginning. Not eventually. Not after the analysis phase. Not once the governance board had blessed the delivery roadmap with a ceremonial biscuit.

From the beginning.

The working software was the thing that reduced uncertainty. You could run it. You could inspect it. You could change it. You could find out what broke. You could show it to someone and get a reaction that was based on something real rather than everyone's private interpretation of a diagram.

That is why agile becomes untethered when it does not deliver software. You can have stand-ups, retrospectives, planning sessions, sprint reviews, showcases, backlog refinement, delivery leads, product owners, scrum masters, Jira hygiene, and enough velocity charts to tile a downstairs bathroom.

But if there is no working thing, the whole scenario drifts off into unreality and ceases to bite.

You have retained the meetings and lost the mechanism.

Software exists to do a task

It is worth being plain about why working software matters so much. Software is built in order to perform a task. That is what it is there for. A piece of working software in production is a working piece of technology doing work.

And once it is in production, it compounds.

You do not start from scratch next sprint. You start from something that already runs, already serves users, already handles edge cases that took weeks to find. The next increment builds on the last one. You go from something that works to something that works better, or scales to more users, or covers more use cases, or runs more cheaply, or fails less often.

This is the bit that makes agile worth the effort. Not the rituals. The compounding. Each cycle, the artifact you leave behind is a little more capable than the one before, and the next cycle starts from there rather than from a blank page.

Waterfall, in its purest form, struggles with this because it treats the project as a single arc with a single delivery. Compounding is something that happens to other people's products, after yours has been signed off and handed to operations.

The artifact has to carry the weight

This is where middle-management agile often gets into trouble.

I have seen attempts to apply agile to layers of management where the main artifact becomes a whiteboard. Usually a Mural board or something similar. Everyone adds their thoughts. The thoughts are grouped. The groups are named. People vote with little dots. Someone uses the ❤️ at least once.

Then what?

Sometimes it works, if the cards become actions. A thing to do. An owner. A date....