Kanban Methodology: Why It Is Not a Framework
The Answer
The kanban methodology is a way of managing work that you apply to the process you already have, rather than a process you adopt. It rests on six practices: visualise the workflow, limit work in progress, manage flow, make process policies explicit, implement feedback loops, and improve collaboratively. What makes it unusual among agile methods is the starting position. Scrum asks you to restructure roles and adopt a fixed cadence before anything improves. Kanban asks you to draw what you already do, cap how much of it runs at once, then change things from evidence. That is why teams can start on a Monday without reorganising anything.
Is Kanban a Methodology, a Framework, or a Method?
Kanban calls itself a method, and its own literature is firm that it is not a methodology or a process framework. Kanban University’s official guide states plainly that kanban is applied to an existing process rather than replacing one. So the phrase “kanban methodology” is technically loose, even though it is what almost everyone searches for and says out loud.
The distinction has one practical consequence worth caring about. A framework tells you how to work: scrum specifies roles, events and a time box, and adopting it means changing your process to match. A method tells you how to look at and improve whatever you are already doing. That is why a kanban rollout does not require a reorganisation, and why it can be introduced to a team that has an established way of working without asking anyone to abandon it.
Beyond that, I would not spend a retrospective arguing about the label. Kanban framework, kanban model, kanban approach, kanban technique and kanban management all get used for the same thing, and everyone in the room knows what is meant. One phrase does mean something slightly different: a kanban-style board is any board borrowing the columns-and-cards layout, whether or not the team runs the actual practices. Plenty of kanban style boards have no WIP limits at all, which is the difference between the look and the method.
The Four Principles of the Kanban Method
The principles govern how you introduce change. They exist because most process improvement fails on adoption rather than design.
- Start with what you do now. Do not design a target process. Map the one you actually run, including the messy parts.
- Agree to pursue incremental change. Small changes that stick beat a redesign that gets abandoned in month two.
- Respect current roles, responsibilities and job titles. Nobody’s title changes. This removes most of the political resistance a rollout usually attracts.
- Encourage acts of leadership at every level. Improvements come from the people doing the work, not only from whoever runs the meeting.
Read together, they describe a deliberately unthreatening change model. There is a longer treatment of these in kanban principles, including the service-delivery principles and how classes of service work.
The Six Practices
The principles say how to change. The practices say what to actually do.
Visualise the workflow. Draw the real stages work passes through, one column per stage, one card per item. Include the waiting states. The queue between development and review is usually where the time goes, and a board that hides it will not show you that.
Limit work in progress. Put a cap on the columns where work collects. This is the practice teams most often skip and the one that changes behaviour, because a full column forces you to finish something before starting the next thing. WIP limits covers how to choose the number.
Manage flow. Watch how work moves rather than how busy people are. The question in a standup shifts from what everyone did yesterday to what is blocking the item closest to done.
Make process policies explicit. Write down what “done” means for each column, who can pull work, and how urgent items get handled. Unwritten policies get applied inconsistently and are impossible to improve because nobody agrees on what they currently are.
Implement feedback loops. A regular review of the board and the numbers. Kanban’s canonical set runs from a daily standup up to a quarterly strategy review, and most small teams get by with two or three of them.
Improve collaboratively, evolve experimentally. Change one thing, measure it, keep it or revert it. Flow metrics are what make this more than opinion.
How to Start With Kanban
Four steps, and the first two matter most.
- Map your current process onto columns. Whatever you actually do, including review, waiting and testing states. Resist tidying it up at this stage, because the mess is the information.
- Put every current work item on the board. All of it. This is usually the uncomfortable moment, because teams routinely discover they have three or four times more in flight than anyone believed.
- Add WIP limits where work piles up. Start with the number of people who pull from that column plus one, then adjust after a fortnight.
- Agree the policies out loud and write them on the board. What does done mean for each column. Who pulls next. What happens with an emergency.
Two or three weeks in, you will have enough flow data to see where the real delay is. It is almost never where the team assumed. In my experience the bottleneck sits in a waiting column nobody had drawn, most often review, and the cards had been aging there invisibly for months.
Where Kanban Came From
Taiichi Ohno developed kanban at Toyota in the late 1940s to control inventory between production stages, inspired by how supermarkets restocked shelves only as they emptied. Cards signalled that a downstream stage was ready for more parts, which pulled production instead of pushing it on a schedule.
David Anderson adapted the ideas for knowledge work in the mid 2000s, first at Microsoft and later at Corbis, and published Kanban: Successful Evolutionary Change for Your Technology Business in 2010. The physical cards became columns on a board and the inventory became work items, while the underlying argument stayed intact: limit what is in the system, and the system moves faster.
That manufacturing heritage is why kanban vocabulary sounds different from the rest of the agile world. Pull, flow, cycle time and work in progress are lean terms, not software ones.
Kanban Methodology vs Scrum
The short version is that scrum is prescriptive and kanban is descriptive. Scrum hands you a framework and expects your process to fit it. Kanban takes your process as the starting point and gives you tools to improve it.
That difference shows up most on adoption day. A scrum rollout means new roles, four recurring events and a team willing to hold sprint scope. A kanban rollout means a board and some limits, with no titles changed. Kanban vs scrum covers cadence, roles, metrics and change handling properly, including which suits which kind of work.
FAQ
What are the main components of the kanban methodology?
A board showing your real workflow, cards for work items, WIP limits on the columns where work collects, explicit policies for how work moves, and flow metrics to tell you whether changes helped. The first two are common to any task board, and the last three are what make it kanban.
Is kanban only for software teams?
No. Kanban development practices came out of software, and the method works for any repeatable process with a flow of discrete items, which is why support desks, marketing teams, recruitment and legal departments run it. The manufacturing version has been in use since the 1940s.
What is the difference between kanban methodologies and the kanban method?
Nothing meaningful. People write kanban methodologies when they mean the method plus the practices around it, and a kanban overview will describe the same six practices whatever noun sits in the title.
How long does kanban take to implement?
The board can be up in an afternoon, and the useful data takes two to four weeks. Meaningful improvement follows the data rather than the setup, so treat the first month as measurement rather than results.
Does kanban replace project management?
No. It manages the flow of work through a process, and it says nothing about budgets, stakeholder management, scope negotiation or hiring. Plenty of project managers run kanban boards without either discipline replacing the other.