--- title: "Living in a post-Scrum world | Matt Fehrenbach" description: "When coding agents make implementation cheap, the ceremonies built around estimating and batching that work start to get in the way." canonical: https://m4t.tf/posts/20261101-1-post-scrum --- [![](/favicon.png)](/)[](/cv "CV")[](https://github.com/ma-tf "GitHub") menu ![Two satellite dishes on a desert ridge beneath a hazy orange sky.](https://cdn.m4t.tf/blog/sats2-540-crop.webp) [Blog](/blog) Living in a post-Scrum world ============================ 2026-11-01·1212 words·7 min read * [llms](/blog/llms) * [programming](/blog/programming) * [dx](/blog/dx) * [agile](/blog/agile) Scrum assumes that writing the code is the expensive part. That assumption is getting thinner. A two-week sprint, story points, a planning session spent estimating effort, a daily stand-up that reports yesterday’s progress; that made sense when a ticket took a person days to implement. An agent that can search, edit, test and iterate overnight changes the shape of the work. The bottleneck moves. Deciding what to build, and reviewing what got built, now take longer than building it. Scrum still helps where it forces decisions. The parts that treat implementation as the scarce resource get in the way. What Scrum was solving ---------------------- Scrum grew up around a real problem. Software took a long time to write, estimates were wrong, and stakeholders found out too late. A fixed cadence, a backlog, and a ceremony that forced conversation were a reasonable response. Story points, in particular, were never about hours. They were a relative measure of how hard a piece of work looked, so a team could see how much it usually got through in a sprint. The stand-up was meant to surface blockers early. Sprint planning was meant to stop people from taking on more than they could finish. None of that is silly. The parts that still force a conversation about priorities and risk are still useful. The parts that assume the cost of a change is mostly the typing are the ones under pressure. Cheap implementation -------------------- I have written about this from other angles. [LLMs are tactical programmers](/posts/20260908-1-llms-are-tactical-programmers): very good at making a change once you know what the change should be, less good at deciding which change should exist. [Plan, iterate, then implement](/posts/20260630-1-plan-iterate-implement-with-opencode) is the loop I use with OpenCode; plan in a read-only mode until the approach would pass a review, then switch to build. [grill-me](/posts/20260716-1-grill-me-skill) interviews the gaps in a ticket before any of that starts. The pattern across those posts is the same. The agent is fast at the middle. The expensive work is at the ends: what to ask for, and whether the result belongs in the system. At work I rearranged the header across several pages with no designer available. The agent moved titles and subtitles in minutes. The slow part was getting teammates to look, react and agree what looked right. When that is normal, a two-week batch starts to look odd. You are no longer waiting for the code. You are waiting for the next planning ceremony to decide what the code should be. Where the ceremonies fray ------------------------- **Estimation of effort.** Story points measure how hard something looks to implement. If an agent can turn a clear plan into a working diff in an afternoon, the number mostly measures how fuzzy the plan was. Fuzzy plans are a product problem, not a velocity problem. Points still move, but they stop meaning what the board thinks they mean. **Sprint planning as a batch.** Gathering two weeks of work into one session made sense when switching context was expensive and finishing a ticket took days. With agents, a written spec and a short review loop can absorb a change the same day it is decided. Holding it until the next planning meeting so it can be pointed and slotted is delay dressed up as process. **The daily stand-up.** “What I did yesterday, what I will do today, any blockers” assumes yesterday’s output was mostly human labour. When an agent ran overnight and the human spent the morning reviewing diffs, the useful question is different: what got merged, what got rejected, and what decision is still open. Reporting story progress against a burndown chart adds little once the work itself is bursty. ![](https://cdn.m4t.tf/blog/bird-80.webp) **Velocity as a planning input.** A team that ships mostly agent-assisted changes will see throughput jump and then wobble. Using last sprint’s points to promise the next one assumes a stable cost of implementation. That cost is no longer stable. It depends on how clear the ask was, how much of the codebase the agent could reach, and how picky the review was. What still earns its place -------------------------- I do not want to throw the whole thing out. Scrum still forces a conversation that otherwise gets skipped. Product, design and engineering in the same room, looking at the same backlog, is valuable even when the estimates are theatre. A visible cadence gives stakeholders something to aim at. A definition of done, a habit of demoing working software, and a retrospective that occasionally changes behaviour; those survive contact with agents just fine. The useful distinction is between ceremonies that produce decisions and ceremonies that produce estimates of effort. Keep the first. Treat the second as optional, and drop them when they cost more than they tell you. What replaces the batch ----------------------- A few habits fit the shape of this work better. **Smaller loops.** A change should move from decision to review without waiting for a sprint boundary. Plan mode, a short written brief, then build. If it is wrong, undo and tighten the brief. The [OpenCode loop](/posts/20260630-1-plan-iterate-implement-with-opencode) is one version of this. Sandcastle’s plan-then-dispatch shape is another. The point is the same: do not batch decisions you could make today. **Written specs over pointed tickets.** A ticket that says “add soft-delete for notes” is an invitation for tactical code. A short spec that names the boundary, the migration, the pattern to match and the trade-off you are accepting is something an agent can execute and a human can review. grill-me exists to pull that spec out of your head before the agent starts typing. **Review as the core activity.** When implementation is cheap, the scarce skill is deciding whether the system is better than it was before. In [Failing cheaply](/posts/20260921-1-failing-cheaply) I ordered automated checks by how expensive it is to ignore them. The same idea applies here. Let the pipeline rule out the boring mistakes. Spend the human attention on the strategic ones: is the abstraction in the right place, what will be harder next month, what can now be deleted. **Decisions written down.** Agents cannot infer why the awkward pattern is deliberate. ADRs, a short note in the pull request, a line in the spec; anything that survives the session. Strategic context used to live in people’s heads and old conversations. If an agent is doing the typing, that context has to live next to the code or it gets overwritten. My rhythm now starts from a thin spec, at work and on personal projects. Code is cheap enough to build a working prototype, then iterate and verify. I write down the end result I want and skip implementation detail that will be thrown out. The honest limit ---------------- None of this removes the need to coordinate with other people. If three teams share a platform, a public cadence still helps. If a stakeholder needs a date, a date is still a date. Agents do not dissolve organisational reality. They do change where the time goes. Less of it goes into producing the diff. More of it goes into choosing the diff and living with it. Scrum, run as a machine for estimating and batching implementation work, will keep producing meetings about a cost that is shrinking. Run as a machine for making and communicating decisions, it can still help. The ceremonies that cannot tell the difference are the ones I would let go first. The sprint was a way to manage the cost of building. When building is cheap, manage the cost of deciding instead. ![](https://cdn.m4t.tf/blog/pencil-and-rubber-128.webp) Explore[Blog](/blog)[Photography](/photography)[Graphics](/graphics)[Music](/music)[Vignettes](/vignettes) Site[About](/about)[Contact](/contact)[Privacy](/privacy) Resources[Developers](/developers) Back to top