Moving to Kanban: A Step-by-Step Path to a Smooth Transition

Kanban is a method that makes visible how work flows and improves that flow step by step. Unlike Scrum, it doesn’t introduce new roles or fixed-length cycles; it starts from your current way of working and evolves it. That’s why moving to Kanban isn’t an “installation” but an improvement journey.

When is Kanban a good choice?

• When work arrives in different sizes at unpredictable times (support, operations, maintenance).
• When the team depends on several suppliers, systems or other teams, and much of the work waits on those dependencies.
• When a two-week planning cycle feels artificial because priorities change often.

An observation from the field: Scrum works very well when all the resources are at your own desk. When work changes hands between several suppliers and teams, Kanban’s focus on flow usually delivers results faster. To compare the two, see What is Scrum?

Step 1: Understand today’s flow

Before moving to Kanban, learn how work flows today:

• Where do requests come from, and through which channels?
• Which stages does a piece of work go through from “started” to “done”?
• Where does work wait most: in approval, in testing, with another team?
• What does “on time” mean for the customer or stakeholder?

The answers determine your board’s columns and your improvement priorities.

Step 2: Visualise the work

The point of a board isn’t to look nice; it’s to show reality. Columns should reflect the team’s real working steps. For a good start:

• Show each work item on a single card.
• Add waiting states as separate columns (“Waiting for test”, “Waiting for approval”).
• Separate work types (new feature, defect, technical work) by colour or swimlane.
• Mark blocked work clearly.

You can’t manage what you can’t see. Every piece of work that doesn’t make it onto the board is a hidden consumer of capacity.

Step 3: Limit work in progress (WIP)

The heart of Kanban is limiting how many items are worked on at the same time. WIP limits push the team towards “finishing what we started” instead of “starting something new”. When setting limits:

• Start from today: if on average a certain number of items are open at once, go slightly below that.
• Agree on what to do when a limit is hit: help with the bottleneck instead of pulling new work.
• See limits as a learning tool, not a fixed rule; adjust them by looking at the data.

Step 4: Make the flow policies explicit

When does an item move to the next column? What do “ready” and “done” mean? How is urgent work handled? Having these rules written down where everyone can see them moves discussions from people to rules.

Step 5: Measure the flow

In Kanban you talk about progress with data, not feelings. Four metrics are enough to start:

• Cycle time: the time from an item starting to finishing.
• Throughput: the number of items finished in a period.
• Work in progress (WIP): the number of items open at the same time.
• Work item age: how long open items have been in progress. The best way to catch problems early.

These metrics let you answer “when will it be done?” with probabilities instead of guesses.

Step 6: Set up regular feedback loops

Kanban doesn’t impose fixed events, but without regular conversations there’s no improvement. Common loops:

• Daily flow meeting: look at the board, not at people. Walk it from right to left: what’s closest to done, and what’s blocking it?
• Replenishment meeting: where the next work is selected and prioritised.
• Flow review: a periodic meeting to improve the process by looking at the metrics. Think of it as a data-driven retrospective.

Step 7: Start small, then spread

Instead of moving the whole organisation to Kanban at once, start with a pilot team. Show the pilot’s results with metrics; a success story is the strongest way to convince the next teams. If several teams depend on each other, consider a portfolio board on top of the team boards that shows end-to-end flow.

Common mistakes when moving to Kanban

• Setting up the board without WIP limits. Kanban without limits is just a colourful to-do list.
• Overly complex boards. A board with twenty columns guides nobody.
• Turning metrics into a performance scorecard. Flow metrics are for improving the system, not for judging people.
• Ignoring dependencies. If most of the work waits in other teams, improving only inside the team won’t change the outcome.

Frequently asked questions

Does Kanban have a Scrum Master or Product Owner? Kanban doesn’t define new roles. In practice, many teams define a service delivery manager who manages flow and a service request manager who prioritises requests.

Can Scrum and Kanban be used together? Yes. Many Scrum Teams manage the work inside their Sprint with a Kanban board, WIP limits and flow metrics.

How long does moving to Kanban take? The first board can be set up in a few days. The real gains come from small improvements made over a few months by looking at the data.

---

Curious how we brought a scattered team at an airline into a single Kanban structure? Have a look at our cases. To review your own flow together, you can request a free assessment.