Rolling out Kanban in an IT team comes down to making the work visible, capping how much of it runs in parallel, and settling who pulls the next item. It needs no reorganisation and no new job titles — it needs agreement that the queue is visible and that it has an upper bound.
Quick Overview
What you’ll learn:
- How to build a board that mirrors the real flow rather than the org chart
- What work in process limits are and why they do all the actual work
- How classes of service keep planned work from being crowded out
- Which flow metrics tell you whether the rollout changed anything
Who this article is for:
- IT team leads who both run services and deliver changes
- Managers whose team reports that “everything is in progress”
- Support groups where planned work always loses to interruptions
Reading time: 7 minutes
Start Here: the Board Mirrors Flow, Not Structure
The first version of a board has a single job: show how work actually moves today, including the steps nobody planned. A “waiting for approval” column and a “blocked” column are the most valuable columns on a first board, because that is exactly where work stands while the reports still count it as being in progress.
The dora.dev material on visual management describes boards and dashboards kept in plain view as the way a whole team shares an understanding of the state of work. The practical consequence is blunt: a board only its author sees in a personal view is not visual management. There should be one board, shared, and current enough that the status conversation happens beside it rather than in message threads.
What not to do on that board: do not reproduce departments. A column per team shows the organisation rather than the flow, and it conceals precisely the handovers that generate waiting.
Next: Work in Process Limits
A work in process limit is an upper bound on how many items are allowed at once in a column, or across the whole flow. The dora.dev material on work in process limits ties them to better flow and less context switching — on the condition that the limit is respected rather than decorative. This is the part of the rollout that actually changes behaviour: without a limit, the board merely documents the overload that already exists.
Set the limit from observation rather than from a book: count the items currently in progress, set the limit below that number, and watch what blocks. The first block is the point of the exercise, because it shows the constraint. The response is not to raise the limit but to help finish whichever item has been standing the longest.
Tooling-wise this is unremarkable. The learn.microsoft.com documentation for Azure Boards describes setting work in process limits per column and flagging a breach visually. Every mature tool has the mechanism; the value is not in the configuration but in the decision that exceeding a limit starts a conversation rather than a click-through.
Then: Pull, Classes of Service and Batch Size
In Kanban work is pulled, not assigned: whoever finishes an item takes the next one from the upstream column, provided the limit allows it. The change is small organisationally and large culturally, because it takes the role of task allocator away from the manager and hands them the role of removing obstacles.
Classes of service sort out what most often breaks flow in IT teams: incidents, user requests and planned work living on the same board. Each class gets its own pull rule — an incident enters immediately under its own narrow limit, a standard request enters in order, and planned work enters from a reserved allocation so that it is not crowded out entirely. Without that split, planned work disappears from the board and returns later as debt.
Batch size is the quiet companion of both. The dora.dev material on working in small batches describes decomposing work so that it can move through the system quickly, which is what makes a low limit workable in the first place — a limit set over items that each take weeks produces a blocked board rather than flow.
In a service team it also helps to name the function that owns request order on the demand side; the Kanban Method calls it the Service Request Manager. The label is secondary. What matters is that order is decided by a named person rather than by whoever escalates to the lead.
Finally: the Metrics That Settle Whether It Worked
A short set is enough to begin with: the time an item takes to cross the board, the number of items finished in a fixed period, and the age of the oldest item in progress. The last is the most uncomfortable and the most useful — it surfaces work the team has stopped thinking about while it still consumes a limit.
What not to measure: people’s utilisation. Driving every person towards full load is directly at odds with limiting work in process, and in practice it lengthens the time to cross the board, because everyone is working on everything. A team that wants short crossing times has to carry slack; that is the price the rollout buys.
After the first month, do one thing: compare the crossing time before and after, using the same definition of start and finish. If the definition moved, the comparison is worthless — and that is the most common reason teams cannot say whether Kanban helped them.
Read Also
- Scrum vs Kanban: agile frameworks comparison — iteration or flow, decided before you build a board
- How Kanban techniques can improve transparency and efficiency of teamwork — board practices inside day-to-day teamwork
- Managing a project portfolio in the organisation: team roles and responsibilities — the same competition for people, settled a level up
Build Your Skills
This topic is developed in the AgilePM® Foundation - accredited training with exam and AgilePM® Practitioner - accredited training with exam courses. The first organises roles and management products in agile delivery; the second works on applying them inside a specific team. Contact us to match the scope to how your team works.
Frequently Asked Questions (FAQ)
Should a service team pick Kanban or Scrum?
That follows from the unit of rhythm. Scrum works in an iteration with an agreed scope and a review at the end; Kanban maintains continuous flow and caps work in process. Service teams whose scope changes during the day usually fit Kanban better; product teams with plannable scope more often benefit from iterations.
Does Kanban replace a method such as PRINCE2 or AgilePM?
It does not. Those two describe roles, management products and decision gates; Kanban describes none of them. Kanban is a method for managing workflow: it limits work in process, makes state visible and measures crossing time. That is why it can be laid over an existing way of working instead of replacing it.
Will a Kanban rollout force a reorganisation?
It will not. The default rollout starts with a board mirroring today’s flow, adds work in process limits and the pull rule, and touches nothing in the structure. Organisational changes come later, as a conclusion drawn from the measurements — once it is clear that the wait is always at the same step.
Is a dedicated tool needed before the first board goes up?
No: use what the team already knows, provided it supports per-column limits. A physical board is enough for a co-located team; issue trackers supply the limits and the history needed to measure crossing time. Choosing the tool is the last decision of a rollout, not the first.