I didn't come to Kanban because I read about it. I came to it because Scrum, as much as I love it, assumes a team. Sprints, standups, a shared backlog someone else is also looking at, that's built for more than one person. When it's just me working through something complex, I needed a different shape for the same idea, and Kanban is that shape.
Here's the problem it solves. When you're working alone on something with a lot of moving parts, the natural failure mode isn't too little structure, it's too many things open at once. A half-finished draft here, a half-researched idea there, three tabs and two notebooks all technically “in progress.” Nothing's actually blocked. It just never quite finishes, because attention is spread across everything instead of landing on anything.
Kanban starts from a simple, almost blunt premise: the problem isn't your task list, it's how much you're carrying at the same time. So instead of managing time in fixed cycles the way Scrum does, you manage flow, and you do it mostly by limiting how many things are allowed to be “in progress” at once.
Kanban doesn't come with much ceremony, and that's the point. Strip it down and it's really just a few habits, held together by one board:
That's close to the whole method. No roles to assign when you're the only one on the team, no story points to argue over with yourself. Just a board, a limit, and the discipline to respect the limit even when it's tempting not to.
Kanban isn't a smaller, easier version of Scrum. It's built for a different shape of problem: continuous work with no natural stopping point every two weeks, where the real risk is diffusion rather than drift. The common thread in the kind of work it fits best:
That's a lot of the work that doesn't look like a team project at all, but is still genuinely complex.
I'll be honest, a WIP limit feels a little uncomfortable at first, especially set low. There's something in most people that wants to say “I'll just quickly start this too,” and a strict limit says no, not yet, finish what's open. The first few times that friction shows up, it can feel like the system is getting in your way.
But I've come to see that friction as the entire value of the method, not a flaw in it. A WIP limit of one or two doesn't just organize the work, it protects your attention, which is really the only resource a solo project has. Every time I've ignored it and let a third thing creep into “in progress,” the honest result has been three half-finished things instead of one done thing. Every time I've respected it, even when it felt restrictive in the moment, something actually got shipped.
If I had to name what matters most, it's this:
The WIP limit is how you actually make those three things hold, week after week, instead of just meaning to. It's not a constraint fighting against getting things done. It's the thing that makes getting things done possible at all when there's no team around you to notice you've overcommitted.
This is really where Kanban, run with a small WIP limit, shows its whole hand. Scrum leans on a team to create accountability, someone else sees the backlog, someone else is in the standup. Working solo, that structure isn't there, so the temptation to quietly juggle six things at once has nothing external stopping it. A tight WIP limit is what replaces that missing team accountability with a rule you set for yourself and actually keep.
A few reasons it fits solo and small work so well:
The honest version is that a WIP limit this small takes real willpower to hold, more than it would on a team, because there's no one else watching to keep you to it. But for a project that's just you, or close to it, that's exactly why it works. It's not a lighter version of agile for smaller stakes. It's the version built for exactly this: one person, real complexity, and nothing but self-discipline standing between a pile of half-finished things and something that actually gets done.
