Tag Archives: ScrumMaster

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.



Kanban – What’s in for you as a ScrumMaster?

When I first heard something about Kanban several years ago I did not like it at all. Working as a passionate ScrumMaster with a team following good Scrum practices, I was very suspicious about it. The first thing I’ve learned about Kanban was that there are no sprints and there is no commitment and it sounded horrible to me. I just could not imagine that a team will aim for high performance without giving a commitment to the Product Owner and to themselves.

In the last two years I had a lot of touching points with Kanban. I listened to talks, read books, drank coffee with Kanban enthusiasts and finally even worked with several teams making use of Kanban implementations. My perceptions about the usefulness of Kanban in software product development changed completely. Nowadays I would not want to set up a Scrum team without making use of the principles and practices of Kanban. Otherwise I would not set up a Kanban team without using some of the Scrum ceremonies like retrospectives or daily stand ups.

I know ScrumMasters who are still very suspicious about Kanban and only think of it as being Scrum without commitments. If you are one of them, I want to give you a brief list of things Kanban can do for you to make your Scrum better.

Flow management

A Scrum team is self organized. That means after pulling a set of stories into the sprint or after committing onto a sprint goal, they can do whatever they want to have a successful sprint. Kanban has practices for your team to manage their work flow from generating ideas to delivering product increments to customers. It gives your team good guidance on how to use the freedom of self-organization successfully by explicitly visualizing the complete work flow and limiting work-in-progress for instance.

More to see

When set up properly you as a ScrumMaster will be able to learn more things about your team using several metrics and charts of Kanban. Those will add to your Scrum toolbox and your ScrumMaster’s intuition to evaluate the fitness of your team and to guide them to become better.

Experimental learning

There are retrospectives in Scrum. And your team is expected to use them as learning opportunities and to commit to improvements. Kanban in addition wants you to set expectations for each change your team commits to do and later on asses if your change was successful or not. By using learning models like the Deming cycle for instance Kanban shows you how to evaluate you improvement ideas in a complex environment and how to keep track of them.

Greater adaptability if needed

I love Scrum and I believe it is the best fitting framework for many software development teams working on innovative products. But Scrum is also very strict about many things, like its roles and ceremonies. It even expects me as the ScrumMaster to defend it against framework changes. This will sometimes put you as a ScrumMaster into the very uncomfortable situation to foster the team’s self-organization but not allowing your team to modify Scrum to their individual needs.

Kanban gives you a broader perspective. It helps you to see your team from a systems thinking point of view and encourages you to continuously change your process as long as there are sources of dissatisfaction left. Kanban helps you to let go and even to encourage your team to modify their process beyond the borders of Scrum if it increases their business agility. The evolutionary change that Kanban fosters will help you control the risks involved when crossing “safe Scrum borders”.

Less resistance to change

If you want to successfully change how people work you need their acceptance and trust. Many teams which are confronted with Scrum for the first time perceive it as a big revolution. It might initially scare them so much that they don’t even want to start changing at all and even if they start it might take a long time until they really see and feel the benefits.

Kanban encourages you to start with your team right where they are and even accept all roles, job titles and responsibilities. From that starting point you will change continuously and step by step. Most of the time it is much easier for others to follow your change management that way.


From my perception scaling a Kanban system is a very straightforward process, though it might not be easy in terms of getting more teams, departments and management into the system. Starting with the visualized flow of your team you can scale out by taking into account what is happening with the things your team builds and where does all this work for your team come from. You grow your Kanban and integrate more and more of the complete value stream.

By following the same principles and practices you can also manage the flow of many teams, departments or the whole organization as you do with Portfolio Kanban. You just have to choose the appropriate granularity for the work items on your board.

For me there is absolutely no Scrum vs. Kanban question. I see both of them acting in different dimensions and helping each other just the same way I would encourage my Scrum team to make use of XP practices like TDD or pair programming. Kanban made my Scrum better, I believe it will improve yours to.