Bringing Kanban into Marketing – Part 2

A couple of month ago I started to implement a Kanban system for a marketing team in our company. This team is responsible for planning and running more than 500 internal and external events each year.

As you can read in my previous post they asked me for help because they were missing transparency. They just wanted to see what everyone in the team is doing on a day-to-day basis. They wanted to have their work visible. They wanted to be able to see redundant work as much as being able to recognize if they have forgotten something.

Very soon we set up a Kanban board that visualized the flow of their work beginning with an initial briefing for the event, all the necessary planning, the actual running and finally a closing phase for an event. Every day they met in a stand up in front of the board, updated each other on event preparation task progress, made decisions on how to handle blockers, pulled in new tasks and saw how great they were doing.

It did not took long to remove the primary source of dissatisfaction they had, the lack of transparency. Over time a couple of things emerged, that finally led us to redesign our Kanban board, which I want to share with you here.

One thing that happened really fast in the first weeks after we set up the board, was that transparency decreased again, not because they had submarine projects or did not make proper use of the board and task cards. It just got to filled up with events and tasks.

 

What you see here is the board filled up with event cards in the second column. Every card presenting a single event that is currently in preparation. At times there were more than 30 events in preparation in parallel. The next three columns “To Do”, “Doing” and “Done” are reflecting the work on a task level that has to be done to prepare an event. Usually we had lots of tasks floating around in “Doing” even over longer periods of time.

Also there are only few tasks in “To Do”. The team simply did not use that column to visualize the work still to be done for the reason that if they did, the board would have been exploded with upcoming tasks. In the end you see how this Kanban board was not longer able to provide a good overview about the work in the system.

Delivering events is different – fast is no goal

I came to realize that the nature of work of preparing and running events is very different from the work of a product development team in respect of how the work flows. Let me explain that. When I saw the filled up board of the event team, I initially thought they just have too much work in progress (WIP). So limiting the amount of events that they prepare at the same time, would reduce the number of cards on the board and increase the board’s ability to provide an overview again.

And limiting WIP in general reduces cycle times, which is exactly what we want in product development, where we seek to push out new ideas to our customers as fast as possible to generate feedback and iterate over it. This is totally different for the event team. There is absolutely no sense in delivering the company’s Christmas party in August. Nearly everything that they work on has a fixed dead line. And success for them means to deliver on time, not late and not early.

I got good feedback from Arne Roock on the issue. He suggested that, if they could not finish earlier, they may be able to start later thus decreasing cycle time in another way. Why shouldn’t we try to start the planning of events later? Good idea I thought, but then I was convinced, that it is not helpful for the team to start with the planning of the Christmas party say in early December. All possible event locations would have already been booked out by that time. Same is true with other external dependencies for events like event speakers, caterers and even attendees.

See my problem? I got a Kanban team, that has to start work items as soon as possible an deliver on time. All my talk about reducing cycle times, limiting WIP, working in serial instead of working in parallel just made no sense to them. And so I was missing goals and arguments to improve the team. Kaizen to what goal?

The nature of the team’s work – waiting is normal

Things got clearer for me when I understood that events are work items, which wait most of the time. When you come to plan a new event, you do some things very soon, like book a location or acquire speakers. When you are done with that early preparation, you wait.
Most of the rest of the preparational work for an event is then done in the weeks directly before the event’s “delivery date”. Waiting is normal in that system. So we decided to build that into the board, showing us which events are currently waiting.

I got the tip from Wolfgang Wiedenroth to add a space to the board, where events are explicitly allowed to wait. He suggested multiple waiting columns one for each month of the year and that’s what we did. You can see the additional waiting columns at the right on the board.

Now when the team starts to work on an event, it does all the early things to do, like booking hotels and contacting speakers. When this is done the event is parked and the team decides when it will continue to work on it. For instance they decide its OK to park the Christmas party till October after location is clear. The event card is then put in the October column.
When October comes they will decide to pull back the event card for the Christmas Party into the system and do all the remaining preparation tasks for the event.

Using this approach the team’s board is much more expressive again. The team sees what events they are currently working on at a glance as the number of events in preparation in parallel is reduced.

One other change to the board was suggested by the team. Instead of having “To Do” and “Doing” columns on the task level, they wanted to have “Tomorrow” and “Today” columns on the board, reflecting what are they working on today and what are they planning to do tomorrow. This column layout suites the reactive nature of their work much better. Though they have a rough plan when they start to prepare a new event, most of the actual work they do is highly dependent on the reaction of external factors and thus very reactive.

In result these two board changes increased the transparency for the team again. Everyone sees easily what’s currently worked on and who is working on what. The daily stand ups are running smooth and in time again and provide opportunities for the team to help each other and to decide how to organize for optimal progress. Still I am missing some kinds of measurable goals for them like faster time to market would be to a product development team. I am looking forward to get your feedback and ideas for system improvements.