Three weeks ago one of our marketing teams asked me for some consulting about increasing process transparency for themselves, their stakeholders and their management. Since Monday we are running a Kanban implementation and having Daily Stand Ups in front of what became the company’s biggest Kanban board. In this post I will show you how we got that far and share some first observations with you.
Part of our marketing department is a team which is taking care for the planning and running of internal and external events and for creating and delivering educational content like webinars. This “Event Team” is responsible for the success of more than 500 events each year many of them being big customer marketing events. The work of the Event Team has great value to our company and the company knows the team is doing a great job.
Nevertheless the team asked for a workshop to talk about the way they work. They had the feeling some things could be improved on the team’s process and workflow level. In an initial meeting with the team they worked out, that their biggest pain is a lack of transparency. They are all working on many things at the same time, but they miss the big picture.
Who works on what? Who needs help? What is left to do to prepare event x? They want to have this transparency for themselves and for their stakeholders and managers. They want to be able to explicitly show how much stuff they get done and what kind of value they deliver to us all. So we discovered what is called a “source of dissatisfaction” in Kanban and what would give us a goal for improvement from now on.
Getting Buy In
After that meeting I had ideas how to tackle the transparency problem. I would recommend to the team and the team’s management that we set up a Kanban system where we start to visualize the flow of the team’s work, thus making transparent who works on what, what the work is and where the work lies.
Introducing Kanban to a team that has no explicit Agile background is not a small change. I knew it would affect how the team members interact with each other, it would call for even more self-organization and for the team to take ownership of their process. For that change, the related time and cost investment and the risk of failing I wanted to have an explicit buy in.
I met with the department lead and spoke with him about the team’s request for help and my ideas for supporting the team, got his go and promised to keep him updated. For the team I scheduled a short Kanban training. In 90 minutes I introduced them to the concept of evolutionary change, the J-Curve effect, the principles and practices of Kanban, the idea of creating a physical team board and the investments and risks evolved. I got their buy for the change and I planned the next step: Creating a Kanban board.
The Board Building Workshop
A week later I met the team to create the team’s Kanban board. I put some blank sheets of flip chart paper on the meeting room’s wall to scribble board designs and I introduced them to our approach of designing their Kanban system. Here are the steps I’ve prepared for them on another flip chart.
Starting with work item types we took a lot of time to discuss the work flow and the discovery process was very iterative. For instance we initially defined the work item types “Offline Event” and “Online Event” as the team said it was doing two different things here. During the work flow discovery we found that cards of both item types would flow the same way and we decided to have just one work item type “Event”.
The work flow we found for planning and running events in this team came down to “Inbox -> Briefing -> Preparation -> Running -> Finishing”. Inbox is of course the place where new event cards come in. Here the team needs to prioritize the events to make sure they prepare more important and more complicated events first. The first thing happening to each event is a briefing session with the event’s stakeholders. There goals, content, audience, expectations and so on are identified and documented by the event team.
An event card will leave Briefing if the team knows what to prepare for the event. The Briefing column is very similar to a task planning column of a software development team and the briefing itself reminds me of a Sprint Planning II in Scrum. The column Preparation has the typical three sub-columns on a task level To Do, Doing, Done. No surprise the work of the Event Team is mostly focused around preparation of events. After an event has been prepared, meaning that all preparation tasks went to Done, the event can take place. The card sits in Running. Finally for some events there is a debriefing or feedback session, which occurs in the Finishing column.
It took us 90 minutes to finish our board design. We did not make it through points 3 to 5 of the system design flip chart but I was fine with it as the problem to solve is the lack of transparency and for that having a visible work flow might be a good solution already. The last thing I wanted to know then was how big the real physical board would need to be. I asked how many events they are currently working on so I could multiply the amount with the sticky note size to get the board dimensions. I was really surprised when the team discovered more and more events they are currently preparing. I think we stopped counting at 30. Enough for me to know that we would need a very big board 😉
We used the team’s lockers as the board background every locker being a column of the Kanban board. I also scheduled a Daily Stand Up every morning with the team in front of the board.
The first week
Now after some days the board fills up with more and more tasks. Some events are “delivered” each day. They go into the Running column and into Finishing the next day. The team uses this to briefly give an update on how the event went. New events are entering the board from left and are pulled into Briefing and Preparation. On the task level the team is having spontaneous discussions. Sometimes someone adds additional information that have not been transparent to all, sometimes a task is trashed as the team notices it is not necessary to do it.
We already faced the limits of our current board design. It seems we are in need of a swim lane for tasks that are not related to a special event and I have the feeling we need one or two additional columns for events that are waiting to be prepared after the briefing and that are waiting to be run after the preparation. We also need to find a way to easily visualize who works on what for about 100 task cards. I scheduled a board iteration meeting and will post about the evolution of the Event Team’s Kanban system.
On other thing that took me some time to realize is that a plain optimization of lead time might not be an appropriate goal for this team. Most of the events they are preparing are scheduled for a fixed date in the future, so most of them have dead lines. For this team delivering an event in March that is expected to take place in April does not make sense, though the lead time would be less. If we seek for any optimization here I think we have to focus on the task level in the event preparation phase, but I’m not sure what the next goal could be and what kind of measuring will support us here. Any ideas and feedback welcome.