← All writing · All tags · Atom feed

Why this human–agent workspace is Agile in spirit

April 2026

agents agile methodology

Agile is often sold as ceremonies and certificates. The useful part is older: short cycles, honest feedback, adjusting the system when reality disagrees with the plan — and collaboration that does not waste energy on blame.

That is also a good description of the environment this site argues for — except the “team” is you and an assistant, not only humans in one room.

Spirit, not theatre

Corporate “Agile” can mean standups that run on autopilot. The spirit is different: keep working increments visible, learn from what the machine and the people actually did, and change the setup when the flow is wrong.

When the assistant has access to compilers, tests, and debuggers, you are not debating opinions in a vacuum — you are closing the loop with facts. That is the same instinct as “ship something small and see what breaks,” just with a different toolchain.

Inspect and adapt — for real

Inspect: diagnostics, failing tests, stack traces, logs — the assistant can help read them, but the verdict comes from the same tools you would trust in a human-only workflow.

Adapt: notes, rules, memory, prompts, and the question “what should we add so this is easier next time?” — that is retrospective energy applied to the room, not a sermon at the model.

You are not chasing a perfect upfront design of the chat; you are tuning a system that includes people, models, and automation.

Individuals, interactions — extended

The Agile manifesto still privileges people. Here the cast is wider: a person plus something that behaves like a participant under constraints. The useful move is the same — psychological safety to surface signal, focus on reproducible issues, and repair process and environment before you declare moral failure.

That lines up with cooperation over a duel, and with asking why instead of performing outrage.

Systems, not villains (nothing new under the sun)

Engineering and safety have been writing this for decades. Sidney Dekker, in The Field Guide to Understanding Human Error, contrasts an old view (mistakes prove bad people) with a new view: human error as a symptom of how the work and organization were set up. The Google SRE book (Chapter 15, “Postmortem Culture”) puts the same idea into practice as blameless postmortems: focus on how failure was possible and what to fix in systems and processes — you cannot “patch” people, but you can change what they see and what the environment allows. Industry guides (e.g. PagerDuty’s blameless postmortem notes, which cite Dekker) spell out why hunting for a scapegoat hides the signal.

With a model in the loop, the parallel is direct: the productive question is not moral outrage, but why this setup made the next step look reasonable — and what to add to context, tools, or rules so the next chain is shorter.

Not a claim to Scrum

Nothing here says “we run two-week sprints with a Scrum Master.” The claim is narrower and, I think, sturdier: the habits that make Agile worth keeping — feedback, adaptation, transparency, shared ground for “done” — are the same habits that make human–agent work compound instead of resetting every morning.