2 posts tagged with "agile"

"What did you do yesterday?" is the first question of every standup, and on a team that runs agent fleets overnight it has become impossible to answer honestly. The literal answer is: I wrote three prompts, went home, and woke up to eleven pull requests, four of which I have not read yet. The person reciting their update is not lying on purpose. The ritual is lying for them, because it was built around an assumption that no longer holds — that the unit of work is a human doing one thing at a time, serially, during business hours.

That assumption is load-bearing. It holds up the burndown chart, the sprint commitment, the velocity number, the "blocked / in progress / done" columns, and the whole choreography of who-tells-whom-what-when. Pull the assumption and the artifacts don't gracefully degrade. They keep producing numbers that look authoritative and mean nothing. A team can have a beautiful burndown and a green sprint while half its actual throughput happened between midnight and 6 a.m., attributed to no one, reviewed by no one, and reflected in no ceremony.

Here is a failure mode that happens quietly, at every company with a mature Agile practice that decides to add an LLM feature: the team estimates the work in story points, assigns it to a two-week sprint, and then spends three sprints in a row reporting "70% done" while the engineering manager stares at a burndown chart that refuses to burn down. Nobody lied. The feature is genuinely hard to finish — because the conditions that make story points a useful planning tool don't exist for AI features, and nobody noticed until they were already committed.

The problem is not that engineers are bad at estimating. The problem is that story points encode assumptions about the nature of software work — assumptions that LLM features violate structurally, not accidentally.