Kanban Methodology

What is Kanban?

Kanban is an Agile framework with a visualized workflow that is especially popular in software development. There are three components of the Kanban methodology—visualizing workflow, setting WIP limits, and meeting cadences.

When used by development teams, Kanban features a large backlog of user stories that need to be addressed. Business owners and stakeholders are responsible for maintaining and prioritizing the backlog religiously, because it is the sole source of work for the team.

When a team member is ready to work on a new story, they pull it from the backlog and into the “In Progress” column on the Kanban board. As the project progresses it moves across the board until it is completed. The team members handling that project should not start on anything else from the backlog until their current project is complete.

Whitepaper: How to Become an Agile Agency

Whitepaper: Agile Marketing for Creative Teams

History of Kanban

Kanban translates to “billboard” or “signboard” in Japanese, and was originally developed by Toyota in the 1940s. Inspired by grocery stores, which only stock as much product as people need, Toyota’s manufacturing teams began using cards, or kanbans, to signal to other parts of the production line when they needed more parts.

This early version of Kanban was part of a JIT (just in time) approach that allowed plants to create only as many parts as were needed at the time, and not waste resources by making extra.

Software developers built on these ideas to create their own version of the Kanban system as part of the Agile methodology movement.

Key components of Kanban

As with most Agile methodologies, Kanban is designed to make teams work better, and anything that isn’t working for your particular group should be up for change. The core of Kanban is made up of these components:

Kanban board

A Kanban board is a visualization of a project’s progress, and it’s a crucial part of the transparency that makes Kanban a great project management methodology. A Kanban board needs a real visualization that reflects the reality of your team’s workflow, not the way you wish things happened, or the way stakeholders think things get done.

The simplest Kanban board has only three columns—"To Do," "Doing," and "Done"—but you can adjust those in whatever way fits your team. 

Kanban cards

A Kanban card represents a single work task (or user story), which is moved throughout the columns of the Kanban board until completion. 

Work in progress (WIP) limits

Once the Kanban board is done, it’s time to put some rules in place for how work is handled in each column. Known as Work in Progress (WIP) limits, these guidelines help the team deliver on one of Kanban’s primary objectives: Stop starting and start finishing.

Each column and lane of the Kanban board has a limit, and once that limit is hit, no new items can go into that lane until one is moved out. For example, if you have four user stories that are “pending review” by an editor and your WIP limit for that lane is four, you can’t move any more content into that lane until one gets moved out.

Backlogs

This is where new user stories get added by business owners, project managers, and anyone else who has a stake in deciding what work the team does. The backlog needs to be consistently maintained and prioritized as a function of Kanban.

Continuous releases

There are no sprints in pure Kanban that require you to release a new iteration after a set period of time. Instead, Agile teams on the Kanban system release software or marketing projects as soon as they are completed.

Cumulative flow diagrams

Cumulative flow diagrams are used in Kanban as a way to visualize your complete workflow and are useful in identifying bottlenecks, manage WIP limits, and reduce your cycle time. 

Kanban meeting cadences 

Unlike Scrum, which is focused around regular iterations known as sprints, Kanban doesn’t run on a set schedule. But that doesn’t mean that it’s without structure. Instead, Kanban teams set their own schedule for each meeting or event that the team uses.

As you start rolling out Kanban on your team, you’ll want to decide how often to hold the following meetings:

Daily stand-ups

Although Kanban teams enjoy the freedom to set their own schedule for most meetings, there’s one that remains non-negotiable: the daily stand-up meeting.

Kanban team members get together for a short meeting every morning to stay up-to-date with progress and pitfalls. These meetings are vital to keep work flowing through the Kanban team.

Rather than have each team member recite what they did yesterday, what they plan to do today, and any blocks that are holding them back as in the Scrum methodology, the Kanban team focuses on the Kanban board and the work it contains. A facilitator starts on the right side of the board—the side closest to “Done”—and walks backward, against the workflow.

If there are any items that have gotten stuck or any that are flagged as blocked, these need to be discussed. Team members are welcome to bring up new information they’ve uncovered or make updates as needed, but there’s no expectation that everyone will speak at every stand-up meeting.

Required cadence: daily

Planning meeting

In this meeting, team members convene to assign upcoming work, discuss any new information that could affect their execution, and ensure they have all the necessary knowledge to deliver the next round of work. 

Suggested initial cadence: every two weeks

Backlog refinement meeting

Stakeholders, both within and outside the team, get together to make sure the backlog accurately reflects current business priorities. The team members need to be able to pull work from the backlog confidently without consulting a manager, so having a well-maintained backlog is crucial for success. 

Suggested initial cadence: every week

Delivery meeting

Depending on how complex the process is, you may want to schedule delivery of completed work on a recurring basis. Alternatively, if your team doesn’t need to coordinate with other groups to get work out, you could simply release work to your audience whenever it’s finished, a process known as ad-hoc delivery.

Suggested initial cadence: ad-hoc

Retrospective meeting

Retrospective meetings are the heartbeat of a successful Kanban system, so don’t neglect them just because you don’t have a sprint that’s ending every couple of weeks. Take the time to honestly discuss how the team is doing and commit to making your next round of work even better. 

Suggested initial cadence: every two weeks

Benefits of Kanban

If you move from another methodology to Kanban, you’ll likely see some nice boosts to your team’s productivity and morale right away. Eliminating sprints and implementing WIP limits will give many teams the flexible structure that they need to accomplish real world objectives.

Benefits of eliminating sprints

The beauty of Kanban is that it doesn’t box your work into predetermined sprint lengths. Depending on your team’s style and the industry you’re in, this can work much better than Scrum-style sprints. In the real world, things change constantly. The modern workplace can rarely afford to take six weeks to do anything like a development team might be able to do, and that means much shorter sprints.

This high velocity can create a lot of stress for an Agile team, particularly if urgent issues crop up often and derail their focus. Kanban doesn’t impose the time box of a sprint, and some teams will thrive without this limit. Others will need to keep the constant ticking of the sprint clock in place because it helps drive them on.

Benefits of WIP limits

WIP limits can also be a great tool because it forces teams to see a project through to completion before starting on anything else. Putting these sorts of limitations on the way work flows (or doesn’t flow) through a team may seem unnecessarily restrictive if you’ve never done anything like it. But in fact, WIP limits are one of the most powerful means of improving the productivity of individuals and teams alike.

One of the simplest reasons why WIP limits work is that when team members try to do too much, they become shockingly inefficient. Teams lose enormous amounts of time to what’s known as context switching, the mental energy expended to jump from one project to another.

On-Demand: Four Steps to Streamline Marketing Workflow

Learn more: Workfront for Project Management

Differences between Scrum and Kanban

There are two primary differences between these two Agile methodologies: how they deal with timing and their differing treatment of meetings and rituals.

Sprints

Scrum focuses on getting things done within the predetermined sprint length. Each Scrum team determines how long its sprints will be, but it’s nonetheless a fixed timeframe.

Kanban, on the other hand, focuses on continuous releases. As soon as a feature, project, or story is complete it goes out, and the team moves on to the next one.

Planning

Similarly, Scrum is more rigid in its approach to regularity and ritual. There is a great deal of importance placed on having the appropriate roles within the team and having the right meetings at the right times.

Sprint planning meetings, during which the team determines exactly what it can accomplish in a sprint by estimating the complexity of various tasks (Story Points), are often cited as a serious drawback to Scrum. These meetings can run very long (four to eight hours), and they rely on the team being able to estimate accurately the time it will take to do each item. For some teams, this process alone becomes the Scrum deal breaker.

In Kanban, the process is much looser. Teams are expected to continuously improve their own processes and procedures just as they are expected to release continuously. There is a greater onus on the team, particularly as there is no equivalent to a Scrum Master who is in charge of managing the processes themselves.

These are merely the two most glaring differences in these two Agile methodologies; here’s an overview of the rest:

Read more about Kanban vs. Scrum

Why choose the Kanban methodology

Teams who don’t take well to the rigidity of Scrum may find freedom in a Kanban system, while those who need additional insulation from upper management may need the buffer of a Scrum Master and product owner.

Your team should start with one system and pay careful attention to the feedback from your team. If you start with Scrum but hear about issues around meetings and processes, Kanban may be a better choice. Alternatively, if you try the Kanban system first and your team seems adrift, the structure of Scrum might help.

For teams completely not familiar with Agile methodologies, the ritual and constancy of Scrum may offer them a sense of security. Kanban is more often adopted when Scrum begins to break down. It’s quite possible that a hybrid Kanban methodology is really going to work the best.

The important thing is not to try and force your team into a system that isn’t right for them. Agile is about constant improvement, and that goes for your processes as well as your products.