You have a team of eight engineers. You spend half your week in standups, sprint planning, sprint reviews, and retros. You wonder why velocity feels low. The answer is usually that the methodology you picked was designed for a 50-engineer org, and you are paying the ceremony cost without getting the benefit.
At small-team scale, the question is not Scrum vs Kanban in the abstract. It is how to keep enough structure to ship predictably without burning a day a week on process.
What actually breaks at small scale
Pure Scrum assumes you have a Product Owner, a Scrum Master, and an engineering team that can hold a 90-minute planning meeting without losing a quarter of its weekly capacity. None of that maps cleanly to a 5 to 15 person startup where the founder is the PM, an engineer doubles as the SM, and a one-hour meeting eats more than 10% of someone's week.
Pure Kanban removes the ceremony but also removes the rhythm. Without a sprint cadence, teams drift. Work-in-progress balloons. Estimates stop happening. Roadmap conversations stop happening. Six weeks later, you cannot explain to investors what shipped.
What works: Scrumban for startups
Most healthy startup teams we work with end up at the same hybrid. They run two-week sprints to keep a planning rhythm, but they manage work day-to-day on a Kanban board with explicit WIP limits. They keep retros (once a sprint, 30 minutes, blameless) and drop most other ceremonies.
The concrete shape:
- Two-week sprints, planned in 45 minutes on a Monday morning. The PM brings a ranked backlog. The team commits to what they can finish.
- Async standups in Slack. Three lines per person, posted by 10am. The 15-minute synchronous standup costs more than it returns once you are remote or hybrid.
- WIP limits on the board. Two items in progress per engineer, max. This is the single highest-leverage change most teams can make.
- 30-minute retro at the end of the sprint. One thing to start, one to stop, one to continue. Anything longer turns into theater.
- No story points. Track count of items shipped per sprint instead. It is a worse signal in theory and a better signal in practice for teams under 15.
When to add structure back
The hybrid above works until somewhere between 15 and 25 engineers. Past that, you need more explicit cross-team coordination. That is where you reintroduce things like quarterly planning, formal sprint reviews with stakeholders, and lightweight estimation. Adding them earlier is overhead. Adding them too late creates cross-team chaos.
The actual point of methodology
Methodology is not the work. It is the scaffolding for the work. At startup scale, the scaffolding should be the smallest thing that gives you predictable shipping, surfaces blockers fast, and lets new hires understand what the team is doing within their first week. Anything beyond that is process for its own sake.
If your team is debating Scrum vs Kanban, the honest answer is usually that the framework is not the problem. The problem is unclear priorities, ambiguous ownership, or too much WIP. Fix those first and any framework will work.
Process not working?
If your engineering team is shipping slower than it should, the cause is usually process, ownership, or technical debt, not methodology. We help startups diagnose and fix the root cause.
Talk to us