What is Kanban project management?

Among the numerous project management methodologies, Kanban stands out as one of the simplest and most beginner-friendly choices that’s still capable of delivering great results.

First developed back in the 1940s by Taiichi Ohno to improve the inventory management at Toyota, Kanban has since been adapted for Agile project management by David J Anderson.

This methodology is suited to all kinds of knowledge work endeavors, including software development, healthcare, manufacturing, video game development, creative writing, etc.

In this guide, we’ll cover everything you need to know about Kanban, including:

• Important Kanban terminology, 
• The 6 rules of Kanban, 
• A step-by-step guide to using Kanban, and 
• The differences between Kanban and other Agile frameworks.

What is the Kanban process?

At its simplest, the Kanban methodology is the process of workflow visualization using a signboard and cards. The placement of cards on the board indicates the progress status of tasks (To do, In progress, or Done).

This is, of course, an oversimplification. However, we can’t go into more detail without first establishing some context surrounding the development of Kanban.

This is because the Kanban methodology used today differs slightly from its 1940s Toyota roots. Explaining the old system will help understand it as it is today.

The history of Kanban

The problem Toyota had faced back in the 1940s was keeping too much equipment. 

Taiichi Ohno noticed that supermarkets used a so-called pull system that allowed them to keep just enough stock to meet demands. 

As he explains in the book Toyota Production System: Beyond Large-Scale Production, supermarkets track the consumption of goods via the cash register. 

Through the cash register, the purchasing department has insight into the selection and quantity of goods purchased, and it uses this information to restock said goods.

So taking this as inspiration, he pioneered the Kanban method using a physical signboard. Fun fact: in Japanese, the word kanban (看板) means signboard.

By using this signboard and affixing cards to it that specified the materials needed for production on any particular piece of equipment, Taiichi was successfully able to prevent overproduction and excessive transportation, among other things.

Workers would request parts needed by specifying them on the cards and affixing them to the Kanban board. These parts would then be pulled from inventory and serve as a signal for what to restock. 

There’s a bit more to it than this — as a rule, the cards always remained attached to the goods, from the moment they were used to request parts and even after they were put together. But elaborating more on this would only serve to confuse us, as the modern Kanban methodology is all about the Kanban board and the cards never leave it.

Kanban today

So, how can the inventory management Kanban of old be used for creative work as an Agile framework?

The answer is surprisingly simple.

You just have to divide the Kanban board into several columns that signify the state of card (task) progress.

The simplest Kanban board has three columns:

1. To do
2. Doing
3. Done

When new cards get made, they are added to the To do column—ideally, their placement in the column would correspond to their priority.

Team members would then take the highest priority cards (one card per person), drag them to the Doing/In progress column, and begin work on the tasks described on the cards.

When the task is completed, they’d move the card to the Done column. Then they’d take another card from the To do column and repeat the process.

There’s a bit more to Kanban than this, but this is the first and most important step.

Using this column division makes it easy for anyone to gauge the state of the project and its tasks at a glance, and to remain up to date on what each member of the team is doing.

Basic Kanban terms to know

Before we can elaborate on some of the finer nuances of Kanban, we first need to go over the relevant terminology.

To understand the contents of this guide fully, you’ll need to know the meaning of:

• Kanban board
• Kanban card
• WIP
• Throughput
• Lead time
• Cycle time
• Bottlenecks
• Cumulative flow diagrams

Kanban board

Kanban board is the signboard (physical or virtual) to which you add cards and move them around to signal workflow. 

Since Kanban means signboard, saying Kanban board is tautological (like saying close proximity, new innovation, or short summary). 

However, the phrase has stuck, so we should get used to it.

Kanban card

A card in Kanban is a form (analogous to a sticky note) that carries information relevant to the task (name, assignee, due date, etc.). 

Sometimes, the term task is used instead of card. 

Virtual Kanban cards have the benefit of unlimited space, so they often contain other helpful resources, like links and images. 

In Plaky, each card also has a comment window to facilitate team communication and collaboration.

WIP

WIP is an acronym for work-in-progress.

However, this acronym is more often found in the phrase WIP limitation.

WIP limitation is one of the guiding principles of Kanban — the idea being that avoiding multitasking by limiting the number of cards individuals can drag into the In-progress column at the same time is greatly beneficial.

Throughput 

Throughput is used to quantify the number of completed tasks in a given time. 

This may sound redundant, but it’s worth pointing out that tasks that are still in progress don’t count towards throughput, only ones that are completed.

Lead time

Lead time is the time that passes between a task being made (not the moment you start working on it) and it being completed. 

Low lead time translates to good customer satisfaction.

Cycle time

Cycle time measures how long it takes to complete a task from the moment work on it begins.

Low cycle time indicates good workflow.

Bottlenecks

Bottlenecks are the main indicators of things going wrong in Kanban. 

Strong indicators of bottlenecks include longer cycle times and/or lower throughput.

Bottlenecks can also be discerned through cumulative flow diagrams.

Cumulative flow diagrams

Cumulative flow diagrams are a useful tool with roots in queuing theory that can provide valuable insight into the efficiency of your Kanban practices. 

While nothing that can’t be worked out simply by using the data from accrued cycle times and throughput, cumulative flow diagrams provide a visual insight that allows you to spot bottlenecks more easily.

What are the 6 rules of Kanban?

If you’ve done any digging on Kanban, you’ll likely have stumbled upon the six rules of Kanban. 

This refers to Toyota’s six rules of using Kanban and therefore doesn’t translate fully into the Agile project management framework.

For reference, Toyota’s six rules state the following:

1. “Never pass on defective products”
2. “Take only what is needed”
3. “Produce the exact quantity required”
4. “Level the production”
5. “Fine-tune production”
6. “Stabilize and rationalize the process”

These rules are general enough to be applied to knowledge work, but when discussing Kanban as an Agile framework — we prefer to reformulate them into the five guiding principles of Kanban.

The 5 guiding principles of Kanban

To reap the full benefits of Kanban project management and make it more than mere signboard visualization, you should keep these 5 guiding principles in mind:

1. Respect current roles
2. Make incremental changes
3. Limit WIP
4. Measure workflow
5. Visualize workflow

Principle #1: Respect current roles

“What are the roles in Kanban?”

This is one of the first questions that comes to mind when entertaining the idea of switching to Kanban.

Switching to a new project management methodology generally comes with a fair amount of team role, management, and organizational changes.

In other words, most project management methodologies (to some degree) ask you to stop doing what you were doing and make great changes to accommodate it. 

Scrum, for example, dictates assigning the roles of product owner and scrum master, which teams likely didn’t have prior to adopting Scrum.

Kanban is different.

Kanban asks you to respect the current roles. 

In other words, adopting Kanban requires the least amount of upfront organizational change.

The idea is to keep doing what you’ve been doing, making only the necessary changes, and then to see how you can improve the workflow over time using this framework.

This not only makes Kanban easy to implement, but it also makes teams less resistant to it and doesn’t slow down workflow as there’s no need for a lengthy adjustment period.

Principle #2: Make incremental changes

In keeping with the previous guiding principle, Kanban is all about making small but meaningful changes.

The idea isn’t to impose seemingly arbitrary rules and regulations upon your team. 

Instead, by using Kanban and adhering to the principles outlined below, your team will naturally find ways to streamline and improve the workflow by making small changes. 

The only major change that Kanban demands from you (and which you can still ignore, to your detriment) is getting rid of multitasking by implementing WIP limitations.

Principle #3: Limit WIP

It is said that multitasking is the death of productivity. 

What may seem like a workflow maximizing practice — juggling two or more tasks at once — is, in fact, counterproductive to a fault.

Kanban combats multitasking by imposing WIP (work-in-progress) limits.

In practice, this works by limiting the number of active tasks each team member is allowed to drag into the Doing column.

This is typically the first incremental change Kanban brings to teams using it and one that’s proven to heighten performance.

Principle #4: Measure workflow

At the end of the day, Kanban is a project management methodology that, like all PM methodologies, is supposed to improve overall performance.

Taking it easy by respecting current roles, making incremental changes, and limiting WIP sounds good in theory — but team leaders (or project managers) need something more concrete to track the performance rise and effectiveness of using Kanban.

This is where workflow measurements come into play.

The two most important metrics for measuring workflow using Kanban are:

• Cycle times (how fast work gets done)
• Throughput (how much work gets done)

By tracking these metrics, you can:

• Identify bottlenecks
• Predict future delivery times

Workflow measurements are the things that separate the Kanban methodology from teams simply using a Kanban board.

Principle #5: Visualize workflow

Despite what we’ve just said, the importance of workflow visualization for Kanban cannot be overstated. The point we tried to underscore earlier is that visualization isn’t the only characteristic of Kanban, but it’s still essential.

The methodology is called after its namesake signboard for a reason.

Teams can customize their Kanban boards to their needs. In essence, Kanban is all about taking limited WIP and workflow visualization and customizing it to fit your needs.

In Plaky, you can fully customize your Kanban board to fit your liking, including setting any number of columns and creating any number of boards. 

For example, a software development team has their board, HR has a separate board, sales has a separate board — same with customer service, marketing, and so on.

How do you manage a project with Kanban?

It should be clear by now that managing a project in Kanban is a fairly simple process.

Nevertheless, let’s go through a step-by-step guide using the Kanban features available in Plaky.

Step #1: Create a project/board

In Plaky, you can create a board by clicking on the + Add icon right below the name of your workspace in the upper left corner. 

By default, the new board will be presented in Table View, but clicking Add View and then Kanban will automatically create a Kanban board view.

Keep in mind that this last step will not create a new board, but rather just a new way to visually organize it. 

You can then switch between the Table view and the Kanban view on the fly.

Step #2: Add columns

If you switch to Kanban view immediately upon creating a new board, the Kanban board will be empty.

The first step then is to customize it with columns.

To create columns, press on the plus icon right of the rightmost column descriptor. 

If you wish to create a wholly separate Kanban board, you can do this by pressing the Create New Group button below the lowest-positioned Kanban boards.

The key to success lies in customizing the Kanban board to fit the needs of your team. Not all Kanban boards have to have the same number of columns.

For software development boards, the column most likely to get added first is the QA column. Usually, once the card’s been dragged to this column, a different person (Software QA) will continue working on it. 

After the QA column, there can be a Deploy column, since the Software QA is likely not the person who’ll be implementing the changes. In this way, the card is used to pass the work along through different stages of development in an orderly fashion.

For an even larger Kanban board, we can turn to video game development with level design as an example. Each level is a card, and it has to go through at least the following stages (columns) to be completed:

• To do
• Concept art
• Level design
• High-res art
• Collision testing
• Sound design
• Review
• Done

Different games have different requirements — collision testing can’t be as big a deal for 2D or isometric games — but the point is that you can have as many columns as you want. 

Always remember that Kanban is supposed to adjust to your workflow, not the other way around.

Moreover, the tasks don’t necessarily have to move to the adjacent column to the right. If there is a need for it, your workflow procedure can support column skipping. Just make sure the whole team knows how they are supposed to move the task cards around.

Step #3: Create tasks

When creating tasks in Kanban, it’s best to keep them small and simple.

For example, if you are tasked with creating a website, then you wouldn’t have one card with the task stating Create a website.

Instead, you should divide the task into smaller chunks and make each chunk a task, like UI fixes or Code review. 

While you can assign multiple users to a single task in Plaky, Kanban — as a methodology — favors individual work. This means one person per card at one time. You can hand off cards to other people—such as when a developer passes the card to a tester or a writer passes it off to an editor—but only one person is actively working on it at a time.

Even if the cards don’t change hands as they migrate across the Kanban board, adding reviewers to cards is still a worthwhile option, especially as it will notify them when any changes are made to the card. 

This way, even though one person is actively working on the card, the team lead and any other relevant party members will all stay notified at all times.

In Plaky, you create task cards by clicking on the Add button at the bottom of a column. 

The team leader should ensure that higher priority tasks find their way to the top of the To do column. 

Alternatively — and especially if the team using the Kanban board is large — you can use the To do column as a backlog and create a Priority tasks column for priority tasks. The project manager or team leader would populate the Priority tasks column and team members would only use this column to pull cards.

Step #4: Optimize the workflow

This last step is what separates the effective use of Kanban from just fiddling with a Kanban board — workflow optimization.

Using acquired data on lead time and throughput, check to see if there are any bottlenecks in the workflow.

Plaky helps with this by letting you add dates to task cards so that you can analyze them whenever you feel like it.

Take a time period — a week, a month, a quarter, whatever works for you — and work out the average lead time and throughput for that time period. 

The next time you look for bottlenecks, go back the same length of time and compare the results.

This will only show you if there is a bottleneck or not.

To find out where the bottleneck occurs, you’ll have to do a bit more digging through individual cards and look for commonalities.

For example, a common cause of bottlenecks is the lack of skill diversification in a team. 

If there’s only one person who can do one job, then that person is the bottleneck. 

Hiring more team members who can perform that job, or training existing team members to do parts of it, have shown to be effective solutions to this problem.

What is the difference between Kanban and Agile?

If, while reading the step-by-step guide, you’ve found that Kanban simply lacks processes your team needs or just doesn’t gel well with your workflow, then perhaps it’s just not for you.

Like all project management methodologies, Kanban is great for some projects but simply less fit for others.

In this case, you should look at other project management methodologies to see if they’re a better fit. Having already grasped an understanding of Kanban, most people like to compare it to other methodologies to see where major differences lie. 

Among the most popular comparisons, we have Kanban and Agile.

However, comparing Kanban and Agile is a bit like comparing apples and apple trees, since Kanban is merely a framework for Agile.

Following this framework makes you Agile, but you can use many frameworks to do so — Kanban is just one of them.

Nevertheless, Kanban does take some departures from Agiles that other frameworks don’t.

For example, Agile generally favors iterative development, but Kanban is not iterative by nature. The Kanban board simply demands a sequential workflow. 

While the drawbacks of multitasking have been extensively studied and are well-known, Agile doesn’t impose WIP limitations. It doesn’t argue in favor of multitasking either, but the idea of limiting WIP is all Kanban.

What is the difference between Kanban and Scrum?

Comparing Kanban and Scrum is a much more reasonable endeavor, as these are both popular Agile frameworks.

In other words, both Kanban and Scrum serve to make you Agile, but they do so in completely different ways. The most noticeable difference is the lack of visualization in Scrum.

In general, Scrum is more prescriptive than Kanban. Where Kanban only asks you to visualize the work using a Kanban board and limit WIP, Scrum adheres to the following set of procedures:

• Using dedicated roles (Product Owner, Scrum Master, Developers)
• Organizing work in Sprints

Your team cannot use Scrum properly until these roles have been decided on and the work has been organized in Sprints.

Conclusion: Kanban is a great way to dip your toes into project management

Kanban is not only one of the most popular project management methodologies, but it’s also one of the simplest and most easy to use.

By limiting work-in-progress and measuring workflow, Kanban becomes a great diagnostic tool for working out the bottlenecks in your workflow and improving overall performance.

It’s not going to be a fit for every type of project, but if what Kanban offers fits what you need, you can get started using it right away by registering a free account for Plaky.

References

• Anderson, D. J. (n.d.). A Brief History of Kanban for Knowledge Work. Retrieved March 28, 2022, from https://djaa.com/brief-history-kanban-knowledge-work/
• Ohno, T. (1978). Toyota Production System: Beyond Large-Scale Production. Productivity Press
• Tabaka, M. (n.d.). Multitasking in This Digital World is Killing Your Productivity, And Research Says There’s Worse News. Inc. Retrieved March 30, 2022, from https://www.inc.com/marla-tabaka/multitasking-in-this-digital-world-is-killing-your-productivity-research-says-theres-worse-news.html 
• Toyota Blog. (2013, May 31). Kanban – Toyota Production System guide. https://mag.toyota.co.uk/kanban-toyota-production-system/.