In the past, I’ve used and taught Scrum in preference to Kanban for Agile Marketing. Sure, I’ve admitted that you could use Kanban for a few applications, and sure, I’ve used a Kanban board, but as I’ve come to understand, that’s not the same thing as practicing Kanban as a methodology. Recently, I’ve learned a lot more about Kanban thanks to a couple of excellent books (more about that below) and exposure to a new generation of Kanban tools, particularly Kanbanize and LeanKit.
As a result, I teach Kanban before I teach Scrum in my classes, and in many cases I recommend Kanban for Agile Marketing.
Some teams will continue to prefer Scrum, and that’s great, but if you’re just starting out, take a close look at Kanban. And even if you’ve been using Scrum for years, and you’re sure that you will continue to use Scrum, read on: there are several practices within Kanban that can easily be applied to Scrum to make it more effective.
What is Kanban?
Kanban is a scheduling and work management system developed by Taiichi Ohno, an industrial engineer at Toyota, in the late 1940’s. It is closely associated with Lean. I’ve seen a number of translations of the Japanese word, Kanban, but literally it means “a card that you can see”.
Although Kanban got its start in manufacturing, it is also used in a number of different contexts: one of the most ubiquitous uses of Kanban happens every day at your local Starbucks.
The cup provides a visual cue to the barista: how many shots of expresso, how many shots and which syrups, what kind of milk, etc. He or she can see at a glance what drink needs to be made. The cups themselves control the work to be done.
Kanban for Agile Marketing
I began teaching Kanban for Agile Marketing because it provided an easier transition for marketing teams. I’ve found change management to be one of the initial challenges of teaching a team Agile Marketing. No one likes to change, and anything that I can do to make the change easier, I do. So I start with where people are today.
I begin by asking the team to list everything they are currently working on. Then, I ask them to categorize their deliverables into types. Deliverable types could include white papers, case studies, events, sales tools, web pages, advertising campaigns, etc.
I then ask them to document the process for creating and delivering each of these deliverables to their intended audience. For example, a white paper may begin with an idea, proceed to research, then writing, then editing and re-writing, then to the design team, through final approval, then on to content and promotion, and last to measurement and learning. Each of these steps represents one or more columns in a Kanban board.
Other deliverables, a webinar for example, may have very different steps. We document this either on a different board or in swim lanes if the tool supports it.
Process Policies
Different steps in a process may be owned by different people or different teams. When that’s the case, a handoff occurs. These handoffs are very critical, and if handled badly, can delay the completion of a task or hurt quality. Process policies provide an excellent way to ensure successful handoffs.
Most teams have informal process policies, they just don’t document them or enforce them. For example, the design team may tell the writers/editors that all of the writing and editing should be done, any diagrams or charts should be sketched out and/or the data for the chart should be provided, and that the audience should be defined.
If those process policies are explicitly defined and followed, it makes the handoffs smooth, and the work proceeds quickly without delays.
Process policies also make it possible for the team to establish service level agreements (SLAs).
Service Level Agreements (SLAs)
Service level agreements provide a degree of predictability in terms of the time it takes to process any task. For example, if the writing/editing team passes on a document to the design team, they want to know when they’ll have a draft to review. Design teams can commit to a date based on three factors:
- The design team has everything they need to begin and complete the work. This factor is satisfied by a process policy.
- Work in process (WIP) limits are established so that the team is not overwhelmed
- Work is sized. As I teach Kanban, I recommend estimating the size of a task in terms of t-shirt sizes (S, M, L, XL). The design team should commit to SLAs for each size task. For example, small tasks will be done in 24 hours, medium in 48 hours, large in a week, extra large in two weeks.
I also recommend that teams establish SLAs for expedited items, with a work in process limit of only 1 expedited item at a time.
Walking the Board
Kanban teams may hold daily standups, but they tend to be slightly different than daily Scrums.
Rather than have everyone go around the room talking about what they did yesterday, what they’re going to do next, and any blocking factors, Kanban standups, which are called walking the board, proceed as follows:
- Each day, a different team member leads the discussion. The leader begins by “walking the board” from right to left—to focus first on work items that are closest to completion—and asks of those cards, “What do we need to do to advance this piece of work?”
- The team takes responsibility for completing tasks. For example, if one team member says “I need a little help pushing this task across the line”, members of the team volunteer to help.
- The next question is “Can we spot any bottlenecks or other impediments to the flow of work?”
- Then ask “Are we tracking things at the right level of granularity?” For example, if a task is too large and doesn’t appear to be moving, can it be broken down into smaller tasks?
- Last question in a Kanban walking the board session: “Is anyone working on anything that’s not on the board?”
Other Kanban Benefits
The use of Kanban for Agile Marketing has other benefits. For example, Kanban has much less terminology and is generally less prescriptive. For many marketing teams, this is a plus, particularly when they are getting started.
Kanban for Agile Marketing has less meeting overhead. Teams do not have to allot half a day every Sprint to Sprint planning, several hours for Sprint review, and 30 minutes for the Sprint retrospective. Walking the board and an occasional meeting to talk about how to improve the process are the only meetings necessary.
Kanban also allows teams to release completed work when it’s done, rather than wait to the end of the Sprint. For example, if a web page is done, why wait until the end of the Sprint to post it? Post it right away.
And lastly, Kanban allows teams to anticipate incoming work. Particularly if each column in a Kanban board is owned by a different person or team, all they have to do is to look to the left to see what is coming up. This gives teams more of a sense of control and more predictability in their work, which increases job satisfaction.
Resources
If you want to learn more about Kanban, I recommend a couple of excellent books and one online resource:
Kanban and Scrum: Making the Most of Both
The online resource I recommend has been produced by LeanKit. They have some excellent training materials at their Kanban Learning Center. Check it out.
Brilliant article. This article makes Kanban look so simple – and it should be. Project management should not be tedious in itself, it should provide smooth instances to make it flow smoothly with less fuss. Your article addresses it as such. I like the way you expressed SLAs to be of three factors, particularly the factor: “Work is sized. …… the size of a task in terms of t-shirt sizes (S, M, L, XL).” For me, this sums what Kanban is all about!