Rituals Without Reasons

Most engineering teams I have worked with in the last twenty years ran Scrum without being able to say what a sprint was for. Most of them are now adopting AI the same way, and getting the same result: the ceremony without the outcome.

This is the first edition of Unblocked. Each edition takes one thing that keeps engineering teams from shipping and looks at what actually removes it. I wanted to start with the oldest blocker I know, because I am watching it happen again, with a new vocabulary and a much higher bill.

The problem is not Scrum, and it is not AI. The problem is adopting a practice because everybody else did, without ever learning why it exists. I learned this the slow way, so let me start where I started.

2007: what does "Agile Web Development" even mean?

I learned Ruby on Rails in 2007 from the book everyone learned it from: Agile Web Development with Rails, by Dave Thomas and David Heinemeier Hansson. I had just graduated in Graphic Design, I had my first clients of my own, and I needed to ship web applications for them. The book delivered. I built things with it.

But the title bothered me. I understood "Web Development" and I understood "Rails". I had no idea what "Agile" was doing in front of them. The book itself did not really explain it; the word was in the air, and the authors assumed you knew.

I asked around. The answers I got were variations of "it means iterative" and "it means fast". That was not an explanation, that was a synonym. So I did what I still do when a word gets used by everyone and defined by no one: I went to the source. The source was Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, published in 2001 and, as far as I can tell, the first book ever written about Scrum.

I expected a process manual. I got a story about chaos.

What Schwaber actually built Scrum for

Schwaber did not start from ceremonies. He started from failure. The opening of the book is a list of projects that collapsed under their own planning: a company that cancelled a major project after two years with nothing delivered, methodologies that slowed his own company down while "my company's requirements were always changing", teams overwhelmed by complexity they had promised to control.

In 1995 he took the methodologies of the time to DuPont's process-control experts, led by Babatunde Ogunnaike. Their answer reframed his career: software development is too unpredictable for a defined process, the kind you can plan once and execute. It needs an empirical one, which inspects often and adapts, and which, in Schwaber's words, "expects the unexpected". Scrum is that answer written down.

Everything in the 2001 book follows from that. The Sprint was thirty days, and it was a protected window: the team commits to a Sprint Goal and a backlog, and nobody outside gets to change it until the Sprint ends. That rule is the whole point. It is how you give a team room to work while management, sales and customers keep changing their minds, which they will, because the process is empirical.

Each meeting had one job inside that loop:

• Sprint Planning existed to produce a goal and a commitment. The Product Owner brings the top of the backlog; the team decides how much of it they can turn into working software and defines what the Sprint is for. The team commits; nobody assigns.
• The Daily Scrum existed to synchronise the team and surface impediments, in fifteen minutes, so the Scrum Master could go remove them. It was never a status report to a manager.
• The Sprint Review existed to show working software, not slides, and to let stakeholders inspect it and reshape the backlog. This is where management gets its control back: every thirty days, on real functionality, instead of every afternoon, on a Slack thread.
• Abnormal termination existed because the Sprint was otherwise untouchable. If the goal stopped making sense, you ended the Sprint and planned again. The book says this should rarely happen. The fact that it was written down tells you how seriously the protected window was meant.

Two things I had remembered as part of the original design were not there yet. The Sprint Retrospective, the moment the team inspects how it works and not just what it built, only arrived in Schwaber's 2004 book, Agile Project Management with Scrum. And backlog grooming, the practice of keeping the backlog ordered, split and pruned, was added to the Scrum Guide in 2011 and renamed "refinement" in 2013. Both were added for the same reason as the rest: the empirical loop needs to be applied to the process and to the backlog, not only to the product.

That is what the word in the Rails title meant. Not fast. Not iterative for its own sake. A set of controls designed so that a team could keep its footing while the ground moved, and so that the people moving the ground had a scheduled, legitimate place to do it.

Everything I have seen since is backwards

I have worked on teams in healthcare staffing, fintech, e-commerce, professional networking and research, in Brazil, in the US and in Europe. Almost all of them ran "Scrum". I can count on one hand the ones where the ceremonies did what they were designed to do. The pattern is consistent enough that I can describe it without naming anyone.

The sprint has no goal. It is two weeks long, and it is a list. Somebody pulled the top N tickets from a board until the points added up to last sprint's velocity, and that became the plan. Ask anyone in the room what the sprint is for and you get a pause, then a ticket number. Without a goal there is nothing to protect, so nothing is protected: work gets added on Wednesday, priorities flip on Friday, and the sprint ends with 60 to 80 percent done. Every time. The team learns that the commitment is theatre, and stops treating it as one.

Grooming does not groom. The session that exists to keep the backlog ordered and shorter has become an estimation meeting. Items go in, get a number, and stay. Nothing is ever removed; the backlog grows for years until it is a graveyard nobody reads past the first page, which means the Product Owner is effectively planning from a different list than the one the team sees.

Planning takes thirty minutes. Because the tickets were "already estimated" in grooming, planning is reduced to dragging them into the sprint column. Nobody re-reads the priorities with fresh context. Nobody asks whether the thing estimated three weeks ago still matters. Then the sprint flunks, and the retrospective concludes that the team "over-committed".

Retrospectives are too frequent to be deep. When the sprint is two weeks, a retrospective comes every ten working days. That is exhausting, so it gets compressed: thirty minutes, three columns, a round of "went well / didn't go well", one action item that nobody owns. The one ceremony whose job is to make the team think about how it works becomes the one everybody wants to leave early. I have sat in hundreds of these. I can remember a handful that changed anything.

Each of these is the shape of a Scrum ceremony with the reason hollowed out. The meeting is on the calendar; the decision it was built to make is not being made.

"But software changed"

The fair objection is that Scrum was designed for a different world. In 2001 software shipped on a schedule, often on a CD. Releases were events. There were no CI/CD pipelines, no feature flags, no deploying forty times a day. A thirty-day protected window made sense when integrating and releasing was itself a month of work. Today it can look like a luxury nobody can afford.

I agree with the premise. I do not agree with where people take it.

If a thirty-day sprint does not fit how we deliver software now, then a fourteen-day sprint does not fit either. It is the same instrument, cut in half, with none of the surrounding mechanics re-examined. What actually happened is that teams kept the box, shrank it, and then dropped every part of the design that did not survive the shrinking: the goal, the commitment, the pruned backlog, the real review, the real retrospective. If continuous delivery really makes the protected window obsolete, the honest move is to adopt a flow-based way of working and say so. Keeping the ceremonies while abandoning their reasons is not modernisation. It is inertia with a calendar.

And this is the part that costs more than velocity. A team that runs hollow ceremonies for years learns, correctly, that process is something done to them. Commitments do not mean anything, so they stop committing. Retrospectives do not change anything, so they stop raising things. The practice that was built to protect the team from chaos becomes one more source of it, plus six hours of meetings a sprint.

Steve McConnell gave this a name in 2000, in an IEEE Software column: cargo cult software engineering. Teams imitate the visible rituals of successful teams without understanding what made those teams succeed, and are then surprised that the planes do not land. Twenty-five years later the rituals have changed. The cult has not.

The same movie, now with AI

I am watching the identical pattern with AI in engineering, compressed from twenty years into two. The company buys seats. Adoption is measured, and it is high. Everyone is "using AI". And the delivery numbers do not move the way the vendor deck said they would.

The data is not subtle. In a randomised study published by METR in July 2025, sixteen experienced open-source developers worked on 246 real issues in their own repositories, with and without AI tools. With AI they took 19% longer. Before the study they predicted a 24% speed-up; after it, they still believed they had been 20% faster. The gap between felt productivity and measured productivity was about forty points. The 2024 DORA report found that increasing AI use came with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. The 2025 report, with adoption at around 90%, saw throughput turn positive but instability still rising, and its lead summarised it in one line: "it's not whether or not you're using AI that's driving this, but rather, how you're using AI." DORA's own framing is that AI is an amplifier. It magnifies whatever the organisation already is.

How, then, are most teams using it? From what I see inside codebases, the same way they run sprints: the ritual without the reason.

• No understanding of the harness. Engineers do not know what a system prompt is, what their tool injects into it, how skills, plugins and commands load, how the tool indexes the codebase or infers context. They treat the agent as a chat box with file access, and are surprised when it behaves like one.
• Generic prompts. "Fix the bug in checkout." No role, no constraints, no examples, no expected output. None of the techniques that are documented and cheap to learn: role prompting, zero-, one- and few-shot examples, chain of thought, skeleton of thought, ReAct-style loops. The prompt is the one input the engineer fully controls, and it is the one nobody is trained on.
• No context engineering. Fifteen skills loaded at once, every one of them competing for attention. No statement of which files may be read and which may be written. No spec, no PRD, so the agent reads half the codebase to understand a two-file change. Then the context fills, the model loses the thread, and the team concludes "it hallucinates".
• No model of how agents work. The difference between an autonomous run, a sub-agent with its own context, and a plain loop is invisible to most teams. They launch a fully autonomous agent for a one-line fix and use autocomplete for a schema migration.

To those four I would add the ones I find most often when I am called in:

• No verification loop. The agent's output is treated as done. No tests written first, no evals, no small diffs. Review becomes the bottleneck, and reviewers now read far more code than they write. DORA's 2025 line fits exactly: "friction doesn't vanish so much as move", toward deciding and verifying.
• A codebase nobody prepared for a machine reader. No written guidelines, no architecture notes, no conventions file. The agent does what agents do: it replicates whatever is already there, including the mess, at speed.
• Tool-first instead of workflow-first. Buy Cursor or Copilot, measure seats activated, call it a strategy. The workflow around the tool, where the gains or the losses actually live, is never redesigned.
• No baseline, so no measurement. Nobody recorded lead time or change-failure rate before the rollout. "It feels faster" is the metric, and METR already showed what that metric is worth.
• No training budget. Prompting, context and harness engineering are skills, the way TDD and code review were skills. Companies that would never ship without a senior reviewer expect engineers to pick this up by osmosis, in the gaps between sprints.

What it costs

With sprints, the bill came due slowly: morale, trust, a team that stopped believing in commitments. With AI the bill is faster and it has a line item.

It starts with context rot. An agent dropped into a large codebase with no spec and no boundaries reads until the window is full, and from that point its output degrades: it forgets the constraint from the first message, contradicts a decision it made twenty minutes ago, reinvents a helper that already exists three directories over. The team sees hallucination. What actually happened is that nobody managed what the model was looking at.

Then it compounds. Code nobody fully understands, human or machine, gets extended by a machine that understands it even less. There are no guidelines for it to follow and no documentation for it to read, so quality drifts down while the codebase grows without anyone deciding it should. More code means more context needed per task, which means more rot, which means more bugs and regressions slipping through a review process that was already saturated.

And then there is the invoice. Token usage climbs because every task re-reads the same files, because fifteen skills are loaded for a job that needed one, because the agent loops on a failing test it cannot see the cause of. I have watched an agent spend hours and a serious amount of money on a change that a prepared engineer with a prepared context would have finished in minutes. Not because the model was weak. Because nobody told it what the sprint was for.

Understand before you adopt

The fix is the same in both cases, and it is not a new tool or a new framework. It is the question I asked in 2007 about a word in a book title: why does this exist? Applied to every ceremony, and to every component of the AI workflow, before it goes on the calendar or into the repository.

For the sprint, start by naming the decision each meeting exists to make, and if yours does not make it, change the meeting rather than keep the name. Then, if you want an engineering team that is involved with the product instead of spitting out code, which matters more now that the code itself has become cheap, this is what I would do:

• Stop the two-week sprint. We already ship many times a day. The sprint is no longer timing releases, so stop pretending it is. Use the cycle for the one thing only a cycle can do: improving the team and the product.
• Make the cycle longer and put a gap in it. My own shape is about four weeks, with two whole days taken out of the cycle for the ceremonies. One day for the end of sprint: a demo, feedback from stakeholders, a real conversation about where the product is going. One full day for planning the next one. The gap is where the end of one cycle informs the start of the next, instead of bleeding into it.
• Give planning and the retrospective the time they need. A plan built in thirty minutes from pre-estimated tickets is a list. A retrospective squeezed into the last half hour of a Friday is a ritual. Do both less often and do them properly.
• Use refinement to talk about the product. Are we still going in the right direction? Does this item still deserve to exist? Estimation belongs to planning. Refinement is where the team and the Product Owner argue about priorities, and where the backlog gets shorter.
• Choose the window you can protect. If the honest answer is "none", say so and move to flow. Half-protecting a sprint is worse than not having one.

How a modern software company adjusted agile: Shape Up

37signals is the clearest public example of a company that kept agile's reasons and rewrote its rituals. Ryan Singer's Shape Up, published in 2019 and free to read, describes how they build Basecamp. Work happens in six-week cycles, "long enough to finish something meaningful and short enough to feel the deadline from the beginning", followed by a two-week cool-down for bug fixes, ad-hoc work and deciding what comes next. Before anything is committed, it is shaped: someone senior defines the problem and the rough boundaries of a solution, with an appetite (how much time the thing is worth) instead of an estimate. Then a betting table chooses what the next cycle will bet on. A bet means no interruptions and an expectation to finish. Time is fixed; scope is variable. And there is no backlog: a pitch that does not get bet on is dropped, and if it still matters, someone will bring it back.

Look at what survived from Schwaber: the protected window, the single legitimate point where management redirects, the inspect-and-adapt loop. Then look at what they changed, and why. Longer cycles, because shipping is continuous and the cycle is no longer about releasing. No backlog, because a backlog of a thousand items is the graveyard I described earlier. Appetite instead of estimates, because the estimates were never right. Every change traces back to a reason that no longer held for them. That is what adjusting a method looks like: you keep the reasons and redesign the rituals, not the other way around.

Code at the speed of AI, teams at the speed of humans

Code can now be written at the speed of AI. The team is still human, and it needs these cycles. The code is binary; the product is organic, markets change fast, and with AI they change faster. The cycle is where the humans catch up with what they have shipped and decide what should happen next.

For AI, it looks like this:

1. Dedicate real time to training the team. Not only engineering, but especially engineering. How the model behaves before how the tool works: context windows, attention, non-determinism, what a token costs. An engineer who understands why output degrades as context fills will manage context without being told. Do not let the fear of missing out push you into adopting blindly; the companies that take the time to do this right will be the ones with the numbers to show for it.
2. Engineer the harness deliberately. Write the project instructions. Decide which skills load and when. Know what your tool injects and what it indexes. Treat the system prompt as code: versioned, reviewed, owned.
3. Engineer the context. Specs and PRDs before code, written with a method, not improvised; they are the cheapest context you will ever give an agent. Explicit read and write boundaries per task. Documentation, workflows and conventions the agent can read, because it will read them, and it will follow them.
4. Keep the human in the loop and revalidate everything. Tests first, small diffs, evals for the prompts you depend on. Design for a model that is sometimes wrong, instead of being surprised every time it is.
5. Measure against a baseline. Lead time, change-failure rate, tokens per merged change. Before and after. "It feels faster" is a feeling, not a result.
6. Expect productivity to arrive with method and experience, not with the licence. There is a real shift in how engineers worked for twenty years and how they should work now. That shift is learned, and learning takes time. Budget for it the way you would budget for any other change in how the team builds software.

None of this is exotic. It is the content of a few good books and a few months of deliberate practice, which is roughly what Scrum asked of teams in 2001, and what most teams skipped.

Why "Unblocked"

I have spent twenty years on the engineering side of products in healthcare, fintech, e-commerce and B2B networking, and for most of that time the things that blocked those teams were not technical. They were practices adopted without their reasons, architectures inherited without their constraints, tools bought without their workflows. This newsletter is about those blockers and what removes them: sometimes an architecture decision, sometimes a process, increasingly an AI practice. One per edition, with the data where there is data and my own scars where there is not.

Two questions to take into next week. At your next planning: can everyone in the room say, in one sentence, what this sprint is for? At your next AI-assisted task: can the engineer say what is in the model's context window right now, and why?

If either answer is a pause and then a ticket number, you have found your first blocker. Reply and tell me which one it was.

All in all, your company does not need to run Scrum by the book, or Shape Up, or anything else by the book. Agile was supposed to be flexible: a set of reasons you adapt to your company's needs and culture, not a set of rituals you copy. That is the whole argument of this article, and it applies just as much to how you bring AI into the team.

If your team or your company recognised itself in these struggles, this is the work Welaborate Labs does: helping engineering teams adopt AI, and the practices around it, in a way that actually shows up in delivery. Take a look at labs.welaborate.com and book a time to talk with us about how we can help.

Sources

• Ken Schwaber and Mike Beedle, Agile Software Development with Scrum (Prentice Hall, 2001); chapter excerpt on the DuPont visit and the origins of Scrum at InformIT
• Ken Schwaber, Agile Project Management with Scrum (Microsoft Press, 2004), where the Sprint Retrospective first appears
• Dave Thomas and David Heinemeier Hansson, Agile Web Development with Rails (Pragmatic Bookshelf, 2005)
• Timeline of Scrum's meetings, the 2004 Retrospective and the 2011/2013 grooming-to-refinement rename: Scrum: A Brief History of a Long-Lived Hype
• Steve McConnell, "Cargo Cult Software Engineering", IEEE Software, March/April 2000
• METR randomised study of experienced developers, July 2025, as reported by The Register
• DORA 2024 report: AI adoption and the 1.5% throughput / 7.2% stability decrease
• DORA 2025 State of AI-assisted Software Development and its summary in Research-Driven Engineering Leadership