Design Thinking, Scrum, and Kanban: One Approach, Three Sizes

People sometimes ask me if I have a “methodology.” Not really, not in the branded sense. What I actually have is one belief, applied at three different scales depending on the shape of the work in front of me: you don't fully understand a hard problem until you're working on it, so the process has to be built for learning as you go, not for getting it right on the first pass.

Design thinking, Scrum, and Kanban aren't three competing systems to me. They're the same underlying idea, showing up at the beginning of a problem, in the middle of a team project, and inside a single person's day.

The idea underneath all three

Every one of these approaches starts from the same honest admission: you don't have the full picture yet, and pretending you do is the actual risk, not the lack of a plan. So instead of trying to out-think uncertainty upfront, each one shrinks the loop. Try something small. Look at what actually happened. Adjust. Repeat.

• Design thinking shrinks the loop around a question: what's actually the problem here, and what might solve it?
• Scrum shrinks the loop around a team: what can we build and learn from in the next two weeks?
• Kanban shrinks the loop around a single task: what's the one thing worth finishing right now?

Same instinct, three different lenses. Once you see that, they stop looking like separate toolkits and start looking like one way of working that just changes shape depending on where you are.

Where each one earns its keep

Design thinking is where I start, before there's a team, a backlog, or even a settled sense of what the actual problem is. It's the phase for sitting with a messy situation, talking to the people living inside it, and resisting the urge to jump straight to a solution before the problem is understood. Empathize, define, ideate, prototype, test. It's slow on purpose, because a well-built answer to the wrong question is worse than a rough answer to the right one.

Scrum is what I reach for once the problem is understood well enough to build against, and once there's a real team, five to ten people, working on it together. It takes the same try-it-and-learn instinct and gives it rhythm: a shared backlog, short sprints, a daily check-in, a review, a retro. It's built for coordination, for keeping a group of people rowing in the same direction without losing the ability to change course.

Kanban, run with a small WIP limit, is what I use when it's just me, or close to it, and the work is continuous rather than something that fits neatly into two-week chunks. No team to create accountability, so a tight limit on what's in progress does that job instead. One flow, one or two things moving at a time, nothing left to quietly pile up.

How they actually connect

The honest version of how I use these isn't “pick one.” It's more like a handoff, each one setting up the next:

1. Design thinking finds the right problem. Before anything gets built, this is where the real problem gets separated from the assumed one, through actual conversations with the people affected, not a guess made at a desk.
2. Scrum builds it with a team, in short, visible cycles. Once there's a direction worth committing to and people to build it with, the loop tightens into sprints, so the team is testing the idea against reality every couple of weeks instead of every couple of quarters.
3. Kanban keeps it moving day to day, mine or anyone's. Underneath a sprint, or entirely on its own for solo work, a WIP limit and a pull system keep the actual, individual tasks from piling up unfinished, whether that's one person's board or a piece of a bigger team's.

They don't compete for the same job. Design thinking answers “are we solving the right problem.” Scrum answers “how does a team make real progress on it together, on a rhythm.” Kanban answers “how does the day-to-day work of one person, or one thread of a bigger effort, actually get finished instead of just started.”

The part I'd defend

It would be easy to treat this as picking a favourite: team person likes Scrum, solo person likes Kanban, and design thinking is the fuzzy stuff that happens before real work starts. I don't see it that way. I've watched teams skip design thinking and build a beautifully executed solution to a problem nobody actually had. I've watched Scrum get imposed on true solo work, where the ceremony has no team to serve and just becomes overhead. And I've watched people try to run a five-person team purely on a personal Kanban board, with no shared rhythm, and quietly lose track of each other.

Each one is right-sized for a specific shape of problem. The skill isn't loyalty to one of them. It's recognizing, honestly, which shape you're actually in.

If I had to boil the whole thing down:

1. Start by understanding the problem before you try to solve it.
2. Build with a team on a short, honest, visible rhythm.
3. Keep the actual day-to-day work moving by limiting what's in progress at once.

Three different tools. One belief holding all of them up: that good work comes from tight loops of trying, learning, and adjusting, not from getting the plan right the first time. The scale changes. That part doesn't.