Somebody on your team has read a book. Now there is a proposal to adopt Scrum, and it comes with ceremonies, role names, and a two-week cadence that does not obviously match anything your business does. Meanwhile the marketing lead wants a kanban board, and the office manager quietly points out that the shared spreadsheet has worked fine for three years.
All three of them are right, for different teams. The useful question is not which framework is best but which one fits the shape of how work reaches you.
The question that decides it
How does work arrive at your team?
If it arrives continuously and unpredictably — support tickets, client requests, incoming leads, whatever came in overnight — you have a flow problem. Kanban is built for flow. If work arrives in large planned chunks that you commit to and deliver together, you have a batch problem, and Scrum is built for batches. If work arrives as a handful of things per person per week and everyone already knows what they are, you have neither problem, and a list will serve you better than either.
Teams get into trouble by choosing based on prestige rather than shape. Scrum has the certifications and the conference circuit, so it gets adopted by agencies whose work arrives daily from clients who do not respect sprint boundaries. The ceremony survives; the benefit does not.
Kanban: managing flow
Kanban is a board of columns representing the stages your work passes through, with cards moving left to right. Most teams stop there and call it done, which is a shame, because the columns are the least important part.
The mechanism that actually makes kanban work is the work-in-progress limit: a hard cap on how many cards may sit in a column at once. If your “In Progress” column is capped at three and there are already three cards in it, nobody may start a fourth. To begin something new, you must first finish something old, or help someone else finish theirs.
This feels restrictive for about a week and then transforms the team. Work-in-progress limits are what convert a board from a status display into a system that finishes things. Without them, every card creeps to the middle column and stops, and you end up with twenty-eight things eighty percent done and nothing shipped.
Kanban fits well when: work arrives unpredictably, priorities shift mid-week, tasks vary widely in size, and the team supports other people rather than building toward a fixed release.
Kanban struggles when: everything is genuinely urgent so the limits get ignored, or when the work requires long stretches of coordinated effort that a card cannot usefully represent.
Scrum: managing batches
Scrum organizes work into fixed-length sprints, usually two weeks. At the start, the team commits to a defined set of work. During the sprint, that set does not change. At the end, you deliver, review what happened, and plan the next one.
The protection of the sprint boundary is the entire point. It buys the team two uninterrupted weeks, and it forces stakeholders to make prioritization decisions at a specific moment rather than continuously by whoever shouts loudest.
That protection is also the reason most small teams should not adopt Scrum. If a client can call on Wednesday and reorder your week, the sprint boundary does not exist, and without it you have kept all of the meetings and lost all of the benefit. Scrum without a defended boundary is administrative theater.
Scrum fits well when: work is planned in advance, the team is between four and nine people, delivery is coordinated across several roles, and someone senior is willing to say no to mid-sprint requests.
Scrum struggles when: the team is under four people, work is reactive, or nobody has the authority to protect the sprint.
The simple list: managing a small number of things
A shared list with an owner and a due date on every line is a legitimate system, and for a great many teams it is the correct one. It has almost no overhead, requires no training, and everyone already understands it.
It stops working at a fairly predictable point. When the list grows past roughly forty active items, when several people need to hand work to each other, or when you cannot answer “what is the status of that?” without asking someone, the list has stopped being a system and become an archive of intentions.
Until then, adopting a framework will cost you more in overhead than it returns. Do not let anyone shame you out of a working list.
Side by side
| Simple list | Kanban | Scrum | |
|---|---|---|---|
| Best team size | 1 to 4 | 2 to 15 | 4 to 9 |
| Work arrives | Predictably, in small amounts | Continuously, unpredictably | In planned batches |
| Recurring meeting load | None required | Low | Moderate to high |
| Time to adopt | An afternoon | About a week | Six to eight weeks |
| Handles shifting priorities | Poorly | Very well | Poorly by design |
| Main failure mode | Silently outgrows itself | Limits get ignored | Ceremony without benefit |
The hybrid most teams actually land on
In practice, the arrangement that survives contact with a real small business usually looks like this: a kanban board with work-in-progress limits for the continuous flow of incoming work, plus one recurring planning conversation each week to set priorities and one short retrospective each month to fix what is annoying everyone.
That borrows kanban’s flow management and Scrum’s two genuinely valuable rituals — planning and reflection — while discarding the sprint commitment that small teams cannot defend anyway. It is not orthodox, and it works.
How to roll out any of these without a revolt
- Name the specific problem first. “Things get forgotten between hand-offs” is a reason to change. “We should be more agile” is not, and your team can tell the difference.
- Start with one team, not the whole company. A pilot that succeeds recruits people. A mandate that fails poisons the idea for years.
- Keep the columns to the stages that already exist. Do not invent a review step nobody performs just to have a column for it.
- Make one person responsible for the board being current. Shared ownership of data hygiene means nobody does it.
- Delete something for every process you add. If the new board replaces the old status email, actually stop sending the status email.
- Review after six weeks and be willing to reverse. Abandoning a system that is not helping is a good decision, not an admission of failure.
The honest conclusion
Framework choice matters much less than three unglamorous habits: every piece of work has one named owner, the board reflects reality rather than intentions, and the team finishes things before starting new ones. A team with those habits will do fine on a spreadsheet. A team without them will not be rescued by any methodology, however well certified.