Every scrum team is a dynamic system. It has stocks that accumulate — backlog, work-in-progress, bugs, tech debt — and flows that change them each sprint. What makes teams predictable or chaotic isn't the people. It's the feedback structure connecting those stocks.
Donella Meadows put it cleanly: system structure is the source of system behavior. Swap the PM, fire the "slow" dev, hire two more — if the feedback loops stay the same, the behavior stays the same.
This essay builds a simulation of a scrum team and lets you break it. The math is simple — each stock updates by accumulating its inflows minus its outflows:
The interesting part isn't any single stock. It's the three feedback loops that connect them.
The Feedback Loops
Context-switching penalty (balancing): when each dev juggles too many tickets, cognitive overhead eats velocity. Below about 2 tickets per dev, negligible cost. Above that, every additional ticket makes all tickets slower.
Tech debt drag (reinforcing): debt makes code harder to change → features take longer → pressure to cut corners → more debt. This loop is dormant when debt is low and devastating when it compounds.
Bug generation (reinforcing): more concurrent WIP in crufty code produces more bugs. More bugs steal capacity from features. Falling behind → pressure to rush → more debt → more bugs. This is the death spiral.
The Model
The diagram below shows the structure. Drag the numbers inside the boxes to change them.
A team of 5 developers.
Velocity: 13.5 pts/sprint — context-switching costs 0%, debt drag costs 10%
Bugs: 0.5/sprint generated
Net throughput: 12.0 pts/sprint
Loop diagnosis: healthy — reinforcing loop dormant, team ships steadily
20-Sprint Projection
Over 20 sprints this team ships roughly 48 story points total. Here's the full trajectory:
What the Model Reveals
The "just add more WIP" trap. With 5 devs, low debt and bugs, start with WIP at 8 — things look healthy. Now see what happens when you crank WIP to 20:
Context-switching eats velocity alive. Gross throughput drops even though more work is "in progress." Little's Law fights back: throughput = WIP / cycle time, and cycle time is exploding.
The debt spiral. With moderate WIP and low bugs, slide debt from 2 to 14:
Velocity collapses. Bug generation climbs because defects breed faster in messy code. This is the codebase where every sprint is a slog and the team "doesn't understand why we're so slow."
The recovery. From a grim state (debt 14, bugs 12, WIP 15), try the counter-intuitive fix — reduce WIP to 5:
Context-switching drops. Fewer concurrent changes means fewer new bugs. The team can start paying down debt instead of generating it. Throughput actually rises with less WIP.
This is the core lesson of system dynamics applied to software: the reinforcing loops between WIP, bugs, and tech debt mean that pushing harder makes things worse past a threshold. The only way out is to reduce WIP, which feels like slowing down but is structurally the opposite.
Why Replacing People Doesn't Work
The PM sees the backlog growing and pushes more tickets into WIP. The tech lead sees bugs piling up and diverts developers to firefighting. The CTO sees velocity declining and asks for status reports, adding overhead. Everyone is locally rational. The system is globally dysfunctional.
This is bounded rationality — each person optimizes based on delayed, filtered information. The beer game proves it every semester: smart MBA students produce the same wild oscillations because the structure (delays, incomplete information, local incentives) dictates behavior, not individual intelligence. Replacing any one person changes nothing when the feedback loops remain.
What to Actually Do
The model points toward structural interventions, not heroics:
- Cap WIP ruthlessly. The context-switching loop has a hard threshold. Below ~2 tickets per dev, it's dormant. Above that, it compounds. WIP limits aren't bureaucracy — they're the single highest-leverage policy.
- Pay down debt deliberately. Allocate a fixed percentage of each sprint to debt reduction. Don't wait for a "tech debt sprint" that never comes. The reinforcing loop means early investment prevents exponential costs later.
- Measure bugs as a leading indicator. Rising bug counts are the canary. By the time velocity visibly drops, the reinforcing loops are already locked in.
- Resist the "just add people" reflex. More devs with the same WIP policy just distributes the same dysfunction across more people. Fix the structure first.