Don't run sprints.
Deliver Drops.
Move as fast as you can learn and make decisions.
Code is no longer the bottleneck
Code is now delivered at a speed and quality that were unthinkable a year ago. The process around it was built for an era when writing the code was the slow, expensive part. It is not anymore. The process needs to change.
What lost its reason to exist
- Sprints
- They gave us time to discover what written requirements really meant. A working prototype now answers that before work starts.
- Story splitting
- We made work small enough for the team to finish inside a sprint. Agents removed that limit, so now we make it small enough to tell whether it worked.
- Estimation and velocity
- We sized work by team effort and tracked how much of what we predicted we produced. With agents building, effort no longer predicts much: work that looks big can take an hour, and work that looks small can need a day of guidance. A scale built around people no longer fits the work.
Everything now waits on decisions. The rest of this page follows from that one fact.
Agile answered constraints that no longer exist
Planning was expensive
Specs took weeks to write, so we planned lightly and adjusted as we went.
Now: With human guidance, AI drafts a full spec in minutes, in several variants.
Building was slow
It took months to turn an idea into software, so we cut work into thin slices to limit risk of wasting time and money.
Now: Agents turn a spec into working software in hours or days.
Ambiguity could only be resolved by building
Requirements were words, and everyone reads words differently. The only sure way to learn what someone meant was to build something and show them.
Now: A working prototype can now be prepared during a meeting.
The prototype kills the sprint. Once the meaning is clear, the work takes hours or days, not a series of sprints.
So what is scarce now?
Build the way we work around what is in short supply now, not what was scarce before AI.
All four draw on the same resource: human attention, which is the one thing that did not grow. More drops mean more gates, and each one needs someone's attention.
The Drops model
Each drop is a small, complete piece of work, done start to finish: one problem, requirement or feature solved by one person or a small crew, from understanding what is needed to a decision on whether the solution is ready to be deployed.
Two decisions around every drop
The dam
We take the next idea or problem from the lake and start it. One drop at a time, with a clearly defined outcome in front of us. Today we usually make this decision months in advance.
The gate
The decider looks at a working solution and chooses: ship, refine or stop.
ship · refine · stop
What comes after shipping is new work for the lake. Real usage tells us whether the solution actually helped. Those insights return to the lake as new ideas or problems and pass the dam like any other request.
A drop is not a feature. A feature can take one or several drops. One drop can deliver several features. It is one complete step towards a goal: small enough to judge, big enough to teach us something.
Drops are where the work happens. Gates are where we decide what reaches users. The dam is where we decide what gets worked on.
From request to production
Someone describes an idea, a need or a problem in their own words. It lands in the lake with a minimum of information: what is wanted, its source, why it matters, what the value/risk is, and who decides.
Prioritisation. The dam keeper orders the lake and releases the next work. Only the minimum needed to prioritise is done here; the real work of understanding it belongs to the crew.
A person or a crew of one to three takes the work. With AI, they sharpen it and plan the work in full. Agents build one or more versions to the spec, as close to production code as possible. Anything a person sees has already passed AI checks and reviews.
A user test when the thing needs one; otherwise the decider looks at the working version and decides. Sometimes a day with users, sometimes a two-minute conversation.
The decider chooses ship, refine or stop. When the evidence was a sign-off, this is the same conversation and takes minutes. Work that depends on systems with fixed release dates is built against an agreed interface and waits for the next release.
Three points where someone decides: what we work on, how we solve it, and whether it ships. Only those three need human attention.
The steps are always there, but they shrink to fit. Little to decide means a five-minute gate. Checking and deciding sets the pace of work.
What size is a drop?
A drop is the biggest piece of work about which the decider, after seeing the working version, can say ship, refine or stop. It should take no more than a week from the decision to start to a solution ready for review.
| Stories and tasks | Drops | |
|---|---|---|
| Why we split | So the team could finish it inside a sprint | So we can tell whether it worked |
| What decides the size | How much the team could build | How much we can check at once |
| Result | Pieces that only make sense together | Whole steps, whatever size that takes |
| Typical size | Fixed: what fits a sprint | Varies |
We used to make work small enough for the team to build. Now we make it small enough to decide about.
ExamplesCannot tell whether it worked?
Too big. Split it until the end of it is something you could look at and say yes or no.
Nothing to look at afterwards?
Too small to be a drop. It is maintenance, or it belongs inside a bigger piece of work.
Not everything needs a crew
- MAINTENANCE
- Button colors, copy, small fixes. Agents do them; one human reviews the merges once a day. No gate. This group grows every quarter as agents earn trust.
- SOLO DROP
- One person plus agents, end to end — up to a pull request, or to production when the terrain allows it. The merge approval is the gate. Also open to people outside IT, within safe limits: easy to switch off, easy to undo, no changes to shared rules.
- CREW DROP
- 2–3 people plus agents, full gate. The standard unit. A feature is simply a series of these.
The model is close to a forward-deployed engineer: one person, close to the business, delivering end to end. With a good terrain, that person does not have to be a developer.
People, Crews, Roles
The team most likely stays as it is today, owning its domain and its context: its knowledge and its applications in production. Small crews of one to three form for a drop and dissolve at the gate. Work that spans domains gets a crew mixed from several teams.
Role boundaries blur. AI gives everyone a broad skill set, including technical ones. A person or a crew is chosen by two things: knowledge of the subject, and decision authority. When either is missing, the drop waits.
Dam keeper
Usually a Product Owner or Product Manager. Orders the lake, names a decider for each drop, and makes sure decisions do not stall. One person can look after several crews.
Decider
One per drop. Best inside the crew, or doing the solo drop themselves. At minimum available on the spot while the drop runs.
Crew / solo
The people who do the drop, chosen by applicable knowledge and decision authority, not job title.
Platform team
Builds and maintains the terrain: the AI tools and tech stack every crew works on.
Roles are becoming more like hats. A PO can keep the dam, decide, and work solo on a drop of their own. A product engineer can do the same.
Who takes on more is left open. In one organization the PO takes over much of the work that used to sit with other roles. In another, the developer moves towards a forward-deployed engineer. Both fit the model. It depends on the organization and on how it adapts.
Every drop has a named decider. Not a committee, and not something to sort out once the evidence is in.
Architecture: freedom inside a stronger frame
Weak architecture used to create mess slowly. With agents it creates mess at machine speed. The faster we build, the stronger the frame has to be.
Explicit, not tacit
Agile held things together through conversation: people talked, and that kept the work consistent. Agents are not in those conversations, so the rules have to be written down in a form machines can read.
Executable, not documented
Rules become automated checks that run on every drop. If a rule only lives in a document, neither agents nor people follow it.
Evolving, not frozen
Changes to the architecture are drops too: planned, built, checked, decided. A review board that turns into a queue brings back the waiting we just removed.
More freedom inside the frame, less freedom to redefine the frame. Teams still decide how to solve things. What they no longer change on their own are the shared rules everything else depends on.
Three layers, weakest to strongest. Context files tell agents how we work here. Written rules apply our policies while the work is produced. Automated checks block what must never happen, every time, for everyone. These layers make us fast and our plans trustworthy.
Terrain is shared by every team: the AI tools, the preview environment, the central architecture decisions, the automated checks, the security rules. The platform team builds and maintains it.
A riverbed belongs to one team: the context of its domain — the instructions agents read in the team's repository, the business rules, the context files. The domain team owns it and builds it on the standards of the terrain.
A person may ship their own work — solo, or as the decider inside the crew — within the limits set by the terrain: the automated checks pass, and the change belongs to a type that can ship without extra review (for example, it does not touch security). Outside those limits, a second review checks that the solution fits the architecture, done by a person or by an agent against the written architecture decisions.
Agents propose, people decide. No agent ever approves its own work.
The roadmap revisited
The front of the lake
The ideas and needs that pass the dam next, each with its expected outcome, in priority order. Forecast from position in the lake and the drop rate. Nothing here is a promise until a crew pulls it, but confidence in delivery is high.
Named outcomes
Results with a measure, not features with a date: onboarding under 30 minutes, orders placed without calling support. They set the priorities at the dam.
Themes
The direction of the river. No feature commitments: real evidence will likely rewrite them anyway.
Quarterly sessions no longer freeze full feature lists.
At scale
Coordination does not go away, it gets lighter. The word gate is used only for the decision that ends a drop; everything above that is prioritisation (a dam).
Days
The decider chooses ship, refine or stop.
Continuously
The dam keeper orders the team's lake.
Weeks
Leadership sets direction across teams and keeps the lake in order.
Quarterly
Leadership reviews outcomes and adjusts strategic and tactical direction.
Bigger lakes sit upstream and feed smaller ones.
A programme becomes a chain of drops and gates. The risk is never bigger than one drop. Gate decisions, recorded with their evidence, replace status reports.
The old metrics are out the window
Classic cycle time mostly measured waiting. Drops moves interruptions to the gates, so we measure different things.
Drop rate
How many drops reach a decision per team in a given period. It depends on how fast we check and decide.
Gate latency
Time between the evidence arriving and the decision. A slow gate is the new interruption.
Drop lead time
Time from leaving the lake to reaching the gate.
Idea-to-live time
Time from the written idea to its first release to users, even a small group.
Gate outcome mix
The share of gates ending in ship, refine and stop. Only ship means we are not taking risks. Many refines mean work is poorly framed before it reaches the dam.
Drop integrity
Share of drops where the goal did not change along the way and the crew was not pulled away to other work.
A drop is not done until there is a decision. Work nobody decides on does not count. Only maintenance and very small changes ship without an explicit decision.
The old metrics measured the team. These measure the decision-makers, because that is where the bottleneck moved.
Vocabulary, principles, traps
Vocabulary
- drop
- One idea, need or problem, taken by a person or a crew from sharpening it to the gate decision. Not finished until that choice is made.
- drop plan
- The full spec of one drop, written by the crew at the start of the drop. Drafted in a few versions. Easy to throw away: writing a new one is cheaper than fixing an old one.
- drop gate
- The decision that ends a round of work: ship, refine or stop.
- drop rate
- Our pace: how many drops reach a decision in a given period. Work that nobody decides on does not count. Replaces velocity.
- dropped
- Shipped, or stopped. Both are successful outcomes. Killing a plan is not failure, it is the mechanism.
- lake
- Ideas, needs and problems waiting to be worked on, in priority order.
- dam
- Prioritisation. It holds the lake and releases one drop at a time. There are dams at team, area and portfolio level.
- river
- A team's flow of drops. The current is the drop rate.
- riverbed
- One team's domain context, which agents work within.
- terrain
- The shared platform every riverbed is built on.
- ocean
- The market. You cannot control it, only read it. Every piece of real evidence is ocean weather.
The cycle closes: what we learn from the market comes back to the lake as new ideas, needs and problems.
Principles
Plans are disposable, decisions are not
Draft several full plans cheaply and commit to one per drop. Never patch a broken plan; write a new one.
Fixed goal, fluid everything else
Once what the drop is for is well defined, it stays fixed. The crew may change the solution freely.
Validation sets the tempo
A drop lasts until there is enough evidence to decide, usually days. Not a calendar convention like two weeks.
Humans own gates, agents own flow
People decide at drop boundaries. In between, AI drafts, builds and checks, guided by the crew.
Decisions sit with the work
The decider is in the crew, or available on the spot. A decision that has to be fetched is a wait.
Drops vs what we know
Drops is not a return to waterfall. The whole system adapts faster than Scrum because plans are easy to replace.
| Waterfall | Scrum | Drops | |
|---|---|---|---|
| Unit of work | The whole project or phase | Sprint of stories | One drop |
| Plan | One big plan, expensive to change | Light plan, adapted mid-flight | Full plan, easy to replace |
| What is fixed | Scope | The sprint | What the drop is for |
| Where agility lives | Nowhere | Inside the iteration | Inside the drop, and at the gates |
| Tempo set by | The plan | The calendar | How fast we check and decide |
| Killing a plan is | A crisis | A failed sprint | The mechanism working |
How Drops goes wrong
The old process pulls back
"Give us the requirements and the design" is a handover in disguise. A person or crew goes as far as it can, up to a working solution; handing over to the delivery pipeline happens smoothly, not desk to desk.
The decider is out of reach
The crew is done, the decision is not. If the decider is neither in the crew nor available, the drop waits — and everything we gained by building faster is lost.
Ready-made before the dam
Someone works the topic out in detail before the crew gets it. With AI, working it out is cheap, and it belongs to the crew.
Silence as consent
Treating a silent decider as a ship decision ships work nobody looked at.
Decisions stay in the meeting
A choice made in a call and not written down has to be reconstructed later. Record it when it is made, with the reason.
Moving your teams to Drops
Team assessment
A short check you take right here: how your teams plan, decide and ship today, and where the waiting sits.
Plan builder
Turns the assessment into a step by step plan for your first drops, gates and roles.
Let's talk
Tell me where your teams get stuck. We will look at whether Drops fits, and what a first small step could be.
Start a conversation →Asked and answered
The questions every team asks in the first hour.
How do we keep control when agents write most of the code?
Why does learning set the tempo? We can just produce faster.
What if there is nothing to measure, just "it works"?
Our stakeholders review things quarterly. Will drops just pile up?
How is a crew of 2–3 different from three people on a story today?
What gets thrown away at a refine or a stop? The roadmap?
What happens to our roadmap?
Is estimation still needed?
Who drafts the plans, the PO or the architect?
Where do tiny changes like a button color go?
Do we still need developers?
Ready to run your first drop?
One drop is all it takes to see the difference. See the playbook for how to start.
Drops · a delivery model for the AI era — Andrzej Maciejczyk