At the core of Kanban lies a paradox: by limiting the amount of work we do, we become more productive. That’s one of the things that make Kanban one of the most preferred Agile frameworks.
When you consider how much time we lose to multitasking (or, more accurately, task switching, since no one can truly multitask), you can see why this seemingly paradoxical methodology is so useful.
Compared to Scrum, Kanban is a young work-management method. Its main objective is to visualize a team’s workflow and improve the efficiency of processing tasks.
David J. Anderson best articulated its application to software development, in 2013, in the foundational book Kanban: Successful Evolutionary Change for Your Technology Business, and its adoption hasn’t been as universal as Scrum’s during the early days of Agile software development. But, for teams that chafe under the strictures of the Scrum process, Kanban can be a freeing alternative.
Although it was adapted to knowledge work only a few years ago, the concept of kanban (lower case k) has been around for decades.
The Japanese term “kanban” translates to “signal card,” and was originally developed by Toyota in the 1940s. Inspired by grocery stores, which stock only as much product as people need, Toyota’s manufacturing teams began using cards, or kanbans, to signal to other parts of the production line that they needed more parts.
The use of kanban was part of a JIT (Just in Time) approach that enabled plants to create only as many parts as were needed at the time and to conserve resources by not making extra. This production system created the foundations of Lean by setting the goal to create value without wasting resources.
Let’s say my job is to put tires on a car. It’s wasteful for me to have hundreds of tires that I don’t yet need piled up behind me.
It’s efficient for the team that makes tires to produce them just in time for me to install them on a car. So once my stock reaches an agreed-upon point, say a dozen tires on hand, I put out a kanban card to spur the tire-making team to action. Throughout the assembly line, “workers at each step in the process are not allowed to do work unless they are signaled with a kanban from a downstream step.”
When applied to software development and marketing, a Kanban implementation doesn’t typically include physical signal cards that cause another worker to begin work.
Instead, the signal to pull new work is inferred from the visual quantity of work-in-progress in any given state.
For example, if I’m responsible for editing content on my marketing team, I infer from the amount of work in the “Edit ready” column that it is or isn’t time to pull a new project into my own workload. (This assumes that the number of items in progress in the “editing” column falls below the set WIP limit, enabling me to pull in additional work; more on that shortly.)
Like Scrum, a Kanban implementation requires a prioritized Backlog of work-to-be-done, from which the team pull their work.
Business owners and stakeholders are responsible for religiously maintaining and prioritizing that list, because it is the sole source of work for the marketing team.
You’ve probably seen kanban tracking boards used on all kinds of teams, but simply having a Backlog and moving work from one side of a whiteboard to another doesn’t mean you’re using Kanban. Anderson reminds us that “card walls are not inherently kanban systems. They are merely visual control systems. They allow teams to visually observe work-in-progress and self-organize, assign their own tasks, and move work from a backlog to complete without direction from a project or line manager.
However, if there is no explicit limit to work-in-progress and no signaling to pull new work through the system, it is not a kanban system.”
So, putting a bunch of cards on a wall doesn’t mean you’re using Kanban.
In fact, many Scrum teams use this type of visualization to manage their work. The primary piece that sets Kanban apart is the commitment to limiting work-in-progress (WIP).
Instead of using timeboxes to govern their work, as a Scrum team does, a Kanban team uses WIP limits. Each state of work has an upper limit of productive work that it can contain.
After the team exceeds that limit, waste enters the system. That upper limit then becomes a formalized piece of the Kanban process.
Team capacity can be optimized by limiting WIP. It feels counterintuitive at first, but team members embark on new work only when the previous task is finished, preventing them from getting overwhelmed by their workload.
This limit is one of the core practices of Kanban. It allows the team to be efficient, fluid, and focused on the workflow. But WIP limits aren't constant; they vary from team to team and from one state of work to another.
For example, your team of 5 might have a WIP limit of 10 on their “Doing” column, enabling each person to work on 2 things at once. The limit on work being reviewed, however, might be different, depending on how long this piece of the workflow takes, how many people are assigned to review work, and other factors.
Routinely experiment with your WIP limits and document the outcomes, to ensure that your Kanban system functions at its highest possible level.
WIP limits may be Kanban’s core defining feature, but it’s not all you need. Anderson defines five core properties that make for a successful implementation:
Unlike Scrum, Kanban doesn’t prescribe a way of managing work; it doesn’t dictate regular meetings or create unique roles within the team.
Kanban enables you to boost the flexibility of already established workflows. With that being said, Kanban assumes that you already have some form of work-management process in place, and that you want to continuously improve it. This makes Kanban easier than Scrum for marketing teams to implement, because you can start Kanban with little educational overhead.
The good thing about Kanban is that you can start with what you do now. The method easily points out the problematic areas of the workflow, so you can address them and plan their improvement.
Kanban also adapts readily to changing contexts. No two teams -- even within the same department -- implement it in exactly the same way. This makes sense: the bottlenecks in each team’s workflow are distinct, so each team’s improvement strategy is distinct. For Anderson, this approach is freeing:
"Kanban is giving permission in the market to create a tailored process optimized to a specific context. Kanban is giving people permission to think for themselves...You have permission to try Kanban. You have permission to modify your process. You have permission to be different. Your situation is unique and you deserve to develop a unique process definition tailored and optimized to your domain, your value stream, the risks that you manage, the skills of your team, and the demands of your customers."
If you’re new to Agility and aren’t yet ready to think for yourself, this may sound terrifying rather than freeing; you might start with a Scrum implementation before moving toward Kanban.
The Kanban board is a core element of the Kanban framework. The board contains columns, and each one symbolizes a stage of the work process (e.g. To Do, Doing, Done). The cards in the columns show the progress of each task; the board helps the team to visualize the workflow and commit to the right amount of work.
The first rule of your first Kanban board is that it reflect reality rather than the official or ideal process for completing work on your marketing team.
Your first task is to identify the start and end points for your team. Where do you take over complete control of work, and where do you hand it off to another team or department? These mark the beginning and end of your workflow visualization.
Next, fill in what happens on the team between those two points.
One way to visualize how work makes its way through the team.
Think of any significant gates or gatekeepers in your workflow -- such as approvals, reviews, handoffs from one person to another, or releases out into the world -- and use those to define the columns of your board. Another approach is to think of parts of your workflow that have limits as to how many tasks can be in the same stage at the same time before your effectiveness in getting them all done begins to degrade.
At its simplest, a marketing Kanban board can start with five columns: To Do, Create, Review, Test, and Done.
A content team might start with one like this:
You may find it useful to sketch the flow organically, without trying to fit it into the vertical column view, before translating it into this format.
The first few weeks are likely to see lots of changes to your board layout, so don’t stress about getting it perfect the first time. You're free to create as many columns as you need and experiment with the visualization. Use a format that can easily be changed, such as dry-erase markers and sticky notes on a whiteboard.
Once you’re confident that the flow reflects your team’s flow, you can create a more permanent version with tape or Kanban software.
Depending on the type of work that your team typically does, columns just for work that has left one state and is waiting to be pulled into the next may be useful. Known as buffers, these columns can help some teams visualize bottlenecks.
This sample content marketing board, for example, includes columns for content that is ready to be reviewed and ready to be published.
When first setting up your Kanban board, don’t be too restrictive with the WIP limits you place on each column; make them a little higher than you need. Your workflow will be plagued by variability, waste, and bottlenecks early on, and you don’t want those problems to interfere with the introduction of a pull-based mentality.
The Kanban board is great for facilitating workflow transparency and for applying positive reinforcement. As opportunities for improvement become clear, you can reduce WIP limits and add buffers accordingly.
The daily standup meeting is an integral part of Kanban just as it is in Scrum, but the format deviates slightly.
The Kanban board accurately representation of all work in progress eliminates the need for team members to give daily status updates. Instead, the meeting centers on how work is flowing (or not flowing) through the system. A facilitator of some kind walks the board, usually from right to left, reviewing the cards and, when need arises, querying team members for a status update or information that the team does not already have.
A Kanban standup focuses on blocked items (a status that indicated on the card with a flag) or on cards that haven’t changed status in several days.
This condensed style of standup is one reason that Kanban teams can be considerably larger than Scrum teams. Teams as large as 50 can complete these kinds of standups in under 15 minutes, a rate not feasible using the Scrum standup format.
Many Kanban teams also engage in what’s known as an After Meeting, an informal gathering of team members who are collaborating on their own projects.
Anderson reports that this ceremony “emerged as spontaneous behavior because team members wanted to discuss something on their minds: perhaps a blocking issue, perhaps a technical design or architecture issue, but more often, a process-related issue.” As a result, After Meetings tend to be fertile ground for ideas to improve process and generate innovations.
In place of Review and Retrospectives, Kanban teams use queue-replenishment meetings to keep their backlog prioritized and refined. They must happen at regular intervals, but their cadence doesn’t need to be tied to any other cycle of Kanban.
So, even if you release new content every week, your queue replenishment might need to occur only once a month. Whatever timing you choose, make sure that it’s consistent, because “a steady cadence for queue replenishment reduces the coordination cost of holding the meeting and provides certainty and reliability over the relationship between the business” and the marketing team.
Whenever possible, include a wide variety of decision makers from the most-senior management position available in queue replenishment.
These attendees can often provide more contextual detail and make decisions where lower-level attendees would have to defer. The goal is to produce a Backlog from which the marketing team can work with the utmost confidence, so you need attendees that can make that happen during the meeting.
If you choose Kanban as your first Agile marketing methodology, keep in mind that the “essence of starting with Kanban is to change as little as possible,” and that you want to map your existing workflow and processes before you begin the ongoing improvement efforts.
This recipe for success comes from David Anderson, who crafted it based on his experience as a new manager adopting an existing team. For marketing teams looking to adopt this methodology, these steps serve you equally well:
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.
For teams completely unused to 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, and so may be a good second iteration of agile marketing for some teams.
The important thing is not to try and force your marketing 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.
