How to Implement Kanban in a Week

To implement kanban, start with the process you already have rather than a new one. Write down the steps work really goes through, turn them into columns on a board, put every piece of current work on it, agree how much may be in progress at once, write the rules of the board where everyone can read them, and then look at the board every day to keep work moving. A small team can do all of that in one working week. What takes longer is the habit: finishing before starting, and changing the process a little at a time based on what the board shows.

This is the rollout. For the board itself, see what is a kanban board. For choosing and defending a number, see kanban WIP limits. For measuring the result, see cycle time vs lead time.

What the kanban methodology actually asks for

There are two widely used definitions, and they agree more than they differ. Kanban University’s guide↗ (opens in a new tab) lists six general practices: visualize, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively, evolve experimentally. Its first change principle is “Start with what you do now”, which is why a rollout does not begin with a redesign.

The Kanban Guide↗ (opens in a new tab) by John Coleman and Daniel Vacanti is shorter. It names three practices: defining and visualizing a workflow, actively managing items in a workflow, and improving a workflow. It also asks for a written Definition of Workflow that covers what a work item is, when an item counts as started and finished, the states it flows through, how work in progress is controlled, explicit policies for how items move, and a service level expectation, which is a forecast of how long an item should take from start to finish.

Read together, they give you four things to put in place: a visible workflow, a limit on work in progress, a habit of managing flow, and written policies. The five days below install one or two of them each.

Before day one: pick the scope

• One team, one board. Kanban across three teams at once is three rollouts and a negotiation.
• One kind of work to start, or a few kinds that share the same steps, such as features, enhancements and bugs.
• Everyone who does the work in the room, or on the call, for an hour on day one. A board designed by a manager for other people is ignored by Thursday.

Day 1: map the workflow you already have

Take one recently finished piece of work and trace it backward: where did it come from, who looked at it, where did it wait? Do this for three or four items and the real steps appear. Write them as states, from “asked for” to “done”, and resist adding steps you wish you had.

1. List the states work passes through, in order. Most small software teams land on four to six.
2. Mark where work waits rather than moves, such as waiting for review. Waiting states hide most of the delay.
3. Agree the two points that matter most: when an item counts as started, and when it counts as finished. The Kanban Guide asks you to define both, and every metric later depends on them.
4. Agree what a work item is. “Anything someone asked for that takes more than an hour” is a workable first answer.

Day 2: visualize it

Turn the states into columns and put every piece of current work on the board: the half-finished, the blocked and the forgotten. The first board always shows more work in progress than anyone expected. That is the point of the exercise, not a failure of it.

• One card per work item, with a short title a stranger could understand.
• A way to see what kind of work it is, such as a color or a label for feature, enhancement and bug.
• A way to mark a card as blocked, and a rule that the reason is written on it.
• A queue column in front of the first working column, holding the next few items agreed to be most valuable. Everything else waits in the backlog.

Day 3: limit work in progress

Count what is in progress now, then agree a lower number. A common first move is one item in progress per person doing the work, applied to the working columns and to any review column. The limit is what turns a board into a pull system: when a column is full, nobody pulls another card into it; they help finish what is already there.

Day 3 is also when you deal with the backlog you uncovered on day 2. Anything in progress that nobody has touched for weeks gets an honest decision: finish it, stop it and move it back with a note, or drop it. The details of setting and adjusting the number are in kanban WIP limits.

Day 4: make the policies explicit

Policies are the rules of the board that currently live in people’s heads. The Agile Alliance glossary entry on kanban↗ (opens in a new tab) says they “should be sparse, simple, well-defined, visible, always applied, and readily changeable by the people working on the service.” Kanban University’s examples include when and how the board is replenished and by whom, when an activity counts as complete, the WIP limits, how different classes of work are handled, and meeting times and content.

Board policies (reviewed every two weeks)
- Started = card moves into In Progress. Finished = card moves into Done.
- In Progress holds at most 4 cards. Review holds at most 2.
- Next Up is refilled on Monday and Thursday by the product lead, max 5 cards.
- A card is Done when it is deployed and someone other than the author has checked it.
- Blocked cards say why and who is chasing it, in a comment, the same day.
- A production bug may go in over the limit. Say so on the card.

Keep the list to what the team will actually follow. A policy nobody applies is worse than no policy, because it teaches people the board is optional. For a longer set of norms, a team working agreement is the natural home.

Day 5: start managing flow

Managing flow means looking at the work rather than the people. Set up two feedback loops and put them on the calendar:

• A short daily look at the board, right to left: what is nearly done and what does it need, what is blocked, what is getting old. Daily standup covers the format.
• A review every two weeks: what got stuck, whether the limit bit, which policy nobody followed, and one change to try next.
• Start recording three dates for each finished item: created, started and finished. You will need them for cycle time and a first service level expectation.

By the end of the week you will not have a mature kanban system, and you should not expect one. You will have a board that tells the truth, a limit, written rules and a rhythm for improving them. Everything else is evolution, which is exactly what both guides ask for.

How to implement kanban in manufacturing

The word comes from the factory floor. The Lean Enterprise Institute defines a kanban↗ (opens in a new tab) as “a signaling device that gives authorization and instructions for the production or withdrawal (conveyance) of items in a pull system.” It distinguishes production kanban, which tell an upstream process what to make and how many, from withdrawal kanban, which authorize moving parts downstream. In a plant, the number of cards in circulation is the WIP limit: no card, no production.

The rollout shape is the same, with physical constraints. Map the value stream for one product family, size the containers and the number of cards from real demand and replenishment time, pilot on one line, and only then extend it. The software version in this post borrows the idea of a pull signal and a capped queue, not the card mechanics.

Mistakes that stall a rollout

• Redesigning the process on day one. Model what happens now; improve it later.
• A board with twelve columns. If nobody can say what separates two columns, merge them.
• Limits that never bite. If the limit is never reached, it is not a limit.
• Work done off the board. One “quick favor” a day and the board stops being true.
• No review. Without a regular look back, the board freezes in its first shape.

Implementing kanban on fenbs

fenbs is a kanban-style board with four fixed lanes: To Do, Next Up, In Progress and Completed. You cannot add a review column, swimlanes or a WIP limit setting, and it has no sprints, due dates or settable assignee. If your day-1 map needs six columns and enforced limits, a configurable kanban tool will serve you better. If four lanes fit, most of the week maps directly:

• Day 2: Add many pastes a list in as tasks, so the whole backlog goes on in one go. Each task is a feature, an enhancement or a bug, with a priority from 1 (most urgent) to 10.
• Day 3: the limit is an agreement. Each lane shows its count beside its name, and the Insights panel above the board has an In Progress tile.
• Day 4: write the policies as AI context notes under How we work, which people and every connected AI assistant read. A policy that must always hold goes on the Decisions and rules page as a rule, decided by a person; every connected assistant reads the rules first.
• Day 5: History records every move with who made it, a person or an AI assistant, and how long ago, which is the raw material for flow.