An honest comparison of Scrum, Kanban, Shape Up, XP, and Shippable States Development — for teams of one to five. What each costs. What each assumes. What breaks at small team size.
Small teams are not just smaller versions of big teams. They have different bottlenecks, different failure modes, and different leverage points. A methodology designed for a 30-person engineering org imposes overhead a 3-person team cannot afford. The ceremonies that synchronize a large team starve a small one.
The right question isn't "which methodology is best?" — it's "which methodology assumes the constraints I actually have?" For a team of 1–5, those constraints are: no dedicated PM, no QA team, no release manager, no separate ops, and a hard ceiling on how much process the team can absorb before forward motion stops.
| Methodology | Designed for | Cost at small team size | What breaks |
|---|---|---|---|
| Scrum | 5–9 person teams with dedicated Scrum Master + PO | High — sprint planning, standup, review, retro consumes 4–6 hrs/week per person | No room for a dedicated SM/PO. Sprint commitments become theater. |
| Kanban | Steady flow of work through a defined process | Low — only WIP limits and a board | Doesn't answer how to ship; you still need a deployment discipline. |
| Shape Up | 5–20 person teams, 6-week cycles, betting table | Medium — pitch writing and bet/cool-down rhythm | Six-week bets are too long for one-person teams. Works for 3–5. |
| XP (Extreme Programming) | Co-located 5–12 person teams | High — pair programming assumes ≥2 people, on-site customer assumes another | Pair programming impossible solo. TDD and CI translate cleanly though. |
| Shippable States Development (SSD) | Solo devs and teams of 1–5, especially with AI tooling | Very low — no ceremonies, no sprints, no roles | Requires real CI/CD plus feature flags. If you can't deploy, SSD exposes that fast. |
Optimizes for predictability and synchronization across a team large enough to need both. Sprint planning is a forecasting tool; standups are coordination overhead; retros are a feedback loop the team is too disjointed to provide otherwise. At three people, all three of those problems are solved by a 5-minute conversation. The Scrum scaffold becomes ceremony for ceremony's sake.
Optimizes for flow and visibility. It works at any team size because it imposes almost no structure — but it also provides almost no shipping discipline. Kanban tells you to limit WIP and pull work through stages. It does not tell you how to ensure those stages produce shippable output. Pair Kanban with SSD if you like the board.
Optimizes for protecting product bets from interruption. The six-week cycle and cool-down structure assume a product team where designers, engineers, and stakeholders need a shared rhythm. For a solo dev, the betting table is just you, and six weeks is forever. For 3–5, Shape Up is the strongest competitor to SSD — particularly if your work clusters into discrete features rather than a continuous stream.
Optimizes for code quality through tight feedback loops. Many XP practices — TDD, CI, refactoring, small releases — are just good engineering and translate to any team size. The practices that don't translate are the social ones: pair programming, on-site customer, collective ownership across a real group.
Optimizes for making "deployable today" the default state. SSD assumes the team is too small to absorb deployment as a separate event, so deployment must be folded into the daily work. The methodology is essentially a single invariant — the main branch is always deployable, and a ship happens every day — supported by feature flags, CI, and the Nightly Ritual. For solo devs and teams of 1–5 building production software, this is the lowest-overhead methodology that still produces excellent results.
The methodology designed specifically for solo devs and small teams.
Read SSD