Rolling Out Kanban by Andrea Fryrear

Read the original article on Workfront.

If you’ve seen a photo of an Agile team at work, chances are you’ve seen a Kanban board. Whether digital or analog, they all look something like this:

Kanban boards are awesome, versatile Agile tools, but having a board doesn’t mean you’ve successfully implemented Kanban. Just as calling your daily status meeting a “Scrum” doesn’t mean you’re actually using Scrum to manage your work, there’s more to Kanban than just the board.

The Kanban methodology was designed as an antidote to some of the problems that early Agile practitioners encountered with Scrum, which means its implementation path is much different.

It’s designed to be lightweight so you can get it up and running quickly, but there are still some core components you need to include. We’ll cover the essentials here so you can get going quickly.

Just remember, as with all Agile approaches, once you’ve mastered the basics there are always more paths to continuous improvement.

This article is part of our year-long series on successfully implementing Agile on your marketing team. If you’re looking for more background, you might want to start with one of these earlier pieces:

Why We Need Kanban

While Scrum remains the most popular methodology in the world of Agile software and IT, it simply doesn’t work for everyone. Early on in the adoption of Agile a super smart guy named David Anderson began to see recurring problems on many Scrum teams he was working with.

Some of his observations included:

Changes Were Imposed Out of Context – Scrum implementations happened the same way every time, regardless of what the team really needed at the time. The repeatability of Scrum is one of its many benefits, but in David’s experience it wasn’t right for every team every time.
Not Everyone’s Problems Were Being Solved – Because Scrum rolls out irrespective of context, it often created major disruptions without addressing the pain points of every team member. Those employees whose problems persisted even after a Scrum overhaul tended to be resistant to the Agile process as a whole.

As more diverse kinds of teams (including marketers) have begun to use Scrum, it’s become clear that another item needs to be added to this list:
Non-IT Teams Break Scrum a Lot – My first Agile marketing team lasted three whole Sprints before we had to start fiddling with Scrum. It was just too rigid for our constantly shifting marketing landscape, and our experience was by no means unique. There’s no getting around it: teams outside of the IT world break Scrum.

I point these shortcoming out not to disparage Scrum or steer you away from it. On the contrary, if it seems like the best fit for your situation, dive in and embrace all it has to offer.

But Agile is more than Scrum.

Many teams have missed out on opportunities to produce better work under more pleasant conditions because they thought Scrum was their only option. I don’t want that to happen to you.

So if Scrum sounds wrong for you, take a look at our friend Kanban.

Here’s what you need to know to get started.

Visualize Your Workflow

Before we can optimize the way work gets done on our marketing team, we first need to understand how things happen right now.

This doesn’t have to be a complicated, time-consuming process; all you need is a sketch on a whiteboard to get started.

Gather the team together and start discussing the reality of getting stuff done:

Where do requests come from—external stakeholders, managers, other teams?
How do they get to the team?
What happens once they come in?
Where does work go once the team is finished with it?

One content team I worked with had a visualization something like this:

Your Workflow doesn’t have to be beautiful, but it does have to be accurate, so let contributors, the people actually doing work from day to day, lead the discussion.

You need a real visualization that reflects reality, not the way you wish things happened, or the way your director thinks things get done.

Once everyone agrees on the flow, you can turn it into a simple Kanban board that shows the different states that work goes through. The simplest board has only three columns—”To Do,” “Doing,” and “Done”—but you can adjust those in whatever way fits your team.

Again, a content team might set theirs up something like this:

Limit Work in Progress (WIP)

Once the 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.

For example, if we have a four-person content team, we put a WIP limit of four on our “Working” column. This would mean each team member should be working on only one project at a time.

If someone pulls two pieces of content into “Working” without completing anything, one team member could be forced to sit idle because the WIP limit had been reached.

Or, even better, the idle team member could jump in to help get something ready for review, moving it out of the “Working” column and freeing up space within the WIP limit for a new project to begin.

Why WIP Limits

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 we try to do too much, we become shockingly inefficient. We lose enormous amounts of time to what’s known as context switching, the mental energy expended to jump from one project to another.

Here’s what happens when we’ve got just a few things going on at once:

You can see that if you have just five things in progress, you’re spending only five percent of your mental power on each one and losing 75 percent to waste.

WIP limits make it possible for us to stay in the green part of this graph, avoiding waste by getting one thing totally done before moving on to the next one.

From a business perspective, limiting WIP and reducing the loss to context switching delivers amazing results in work being delivered much faster.

As we can see below, there’s a direct relationship between lower WIP limits and more rapid deployment:

Choosing a WIP Limit

It’s tempting to set all your WIP limits at one and pat yourself on the back for being so Agile, but lower isn’t always better. What we’re looking for is the Goldilocks WIP limit: something that’s not so high that work languishes in the Workflow, but not so low that people are bored.

In this case, illustrated by illustrious Agile thinker Henrik Kniberg, the ideal WIP limit for the team’s “Doing” column is two.

It produces a rapid flow of work through the team because individual tasks are rarely idle, meaning someone from the team is always working on them.

Notice, however, that when we find our ideal WIP limit people are sometimes idle.

This idleness, known as Slack, is another counterintuitive piece of Kanban that unlocks enormous potential for improvement. These quiet moments when employees aren’t frantically busy allow them to invest in professional development, come up with new strategies, and/or improve the Agile team’s process.

In short, the perfect WIP limit is one that keeps tasks moving briskly through the team without creating constant stress on the team members themselves.

Choose Your Cadences

You’ll notice that so far we haven’t covered Timeboxes at all. 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.

For instance, our hypothetical content team may need to meet for planning every week if their audience and environment change that rapidly. But they may not feel the need to conduct a retrospective every single week.

In that case, their planning meetings would happen on a weekly Cadence, while their retrospectives would happen every other week.

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

Planning – In this meeting marketing 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 marketing work. Suggested initial Cadence: every two weeks.
Backlog Grooming/Refinement – Stakeholders, both within and outside the marketing team, get together to make sure the marketing Backlog accurately reflects current business priorities. The Agile marketing 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 – Depending on how complex the process is, you may want to schedule delivery of completed marketing 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.
Retrospectives – These meetings are the heartbeat of a successful Agile team, 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.

Because Kanban is based on your Agile marketing team’s unique context, all of these Cadences are up for discussion. Adjust their frequency and see how it impacts the team performance.

Daily Standups: The Unchanged Cadence

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

As with Scrum, 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 Agile team.

Kanban Standups, however, take a slightly different format.

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, the Kanban team focuses on the 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 Standup meeting.

(This altered daily Standup format is one reason that Kanban teams can be far larger than Scrum teams; a large team can stay up to date on the team’s progress without losing time to individual status updates each morning.)

Don’t Neglect Kanban 2.0

These three components of Kanban—visualizing Workflow, setting WIP limits, and choosing Cadences—are important first steps, but they’re just the tip of the Kanban iceberg. Take your time putting them in place, and inspect and adapt each one regularly.

But don’t forget that there are other Kanban components that we haven’t covered in this introductory article.

Work Item Types, Classes of Service, and Metrics for tracking Kanban’s success are all waiting right around the corner (you can see a little about them in this SlideShare). Each offers new ways to enhance the team’s performance and satisfaction through increased Agility.

Agile is a journey, not a destination, so don’t linger too long at your first stop.

Check out Workfront’s SlideShare called “Agile Marketing: A Beginner’s Guide” for more help implementing Agile on your team.