Kanban, Meeting Facilitation

A Kanban Team Retrospective Activity


Although Kanban does not prescribe retrospectives (nor any other mandatory meeting) all our Kanban teams are doing retrospectives on a regular basis. As a facilitator of a retrospective you should try to create an awareness of why things went well or not so well and let the team discuss issues that hopefully lead to improvement (“Kaizen”). The following approach describes how to review finished tasks or User Stories of the last Kanban cadence and at the same time making the Spectral Analysis Chart (SAC) more vivid (especially if a team is at war with (Kanban) metrics anyway). 🙂

The team I’m working with at the moment agreed on a 2 weeks cadence: Every other Monday we meet for a retrospective to look for improvements. We collect all items from the “Done” column before the retrospective. I write the lead time (in days) on the ticket and order them according to their lead time ascending on a board (or the wall of the conference room).


Then visualize where the team’s average lead time is.


Concentrate in the retrospective on the tasks that are above/beyond the average:

– What are the reasons for the high lead time?
– What can we do to prevent that this will happened with future tasks? Can we do something about it?

Point out to the team members that the visualization on the board (or wall) is actually a SAC, only upside down. With this approach the team members create a better understanding of a SAC (as they connect it to “real” tasks) compared to just showing them an generated chart.


What do you think?

Kanban, Meeting Facilitation

Learning Playfully: Kanban Lead Time, Spectral Analysis Chart, Service Level Agreement

Some team members are at war with Kanban metrics (and probably other metrics): What are Lead and Cycle Time for? What does a Spectral Analysis Chart (SAC) show? Why should we care at all about a Service Level Agreement (SLA)? (Especially when there are so many dependencies with other teams.) You can always quote David Anderson or Wikipedia, but simply quoting won’t make sense to everyone. To better understand what Lead Time and a SAC are and how those are connected to a (desired) SLA, I tried a playful approach with one of our Kanban teams: “Show me your Data!”


– You need a couple of balloons, 2 decks of cards, some LEGO and index cards in different colors.
– Furthermore you need Post-Its or index cards and label those with “1-10 sec”, “11-20 sec”, “21-30 sec”, “31-40 sec”, “41-50 sec”, “51-60 sec” and “> 60 sec”. Stick those horizontally on a pin board.
– Write 9-12 tasks on index cards (Here some ideas for tasks: Mixed deck of index cards should be a color-sorted deck of index cards, inflate 3 balloons, sort out all red LEGO bricks, build a 3-level house of cards etc.)

How to Play:
You play in cadences.
The cadence starts when presenting the team 3 tasks that have to be done.
After that a stop watch starts and the team are working on the tasks.
When a task is finished, a team member sticks the task card in the appropriate column of the pin board in order to track how much time was spent on the task until it was finished.
When all tasks are done and the according task cards have been stuck to the pin board, the cadence end with a short retrospective: How did that work? What could you observe?

You play several cadences, depending on how many tasks you have prepared.

Before the last cadence you should start with a first debrief:
Lead time is… (If you need some good explanation check here.)
The SAC is exactly what can be seen on the pin board. (mirrored horizontically)

Now, supposing all those tasks were tasks of the team’s “Standard” service class, you can derive a SLA that results from empirical measurement of the tasks finished so far: 70% of all tasks will be done within 30 seconds (or whatever time the team needed for the tasks).
“So, let’s try to accomplish this SLA in the last cadence.”


The tasks in the last cadence should be a little harder: a 3-level house of Spade cards from an un-sorted deck of cards etc.
In this case the team can also discuss if it makes sense to split a task to finish the task within the SLA.

Why I think this game works:
It shows that metrics in Kanban measure the system and not the performance of the individual.
It explains very straight forward lead time and SAC and how to derive a SLA from those metrics.
If the tasks are not finished within the SLA, it is easy to discuss why that was the case and how the team could improve and deal with similiar tasks differently in the future.

I named the playful exercise “Show me your data!”.  David J. Anderson mentioned in his “Kanban Advanced Master Class” I attended in November 2012 that this is what he likes to ask Kanban teams he is working with: “Show me your data!”

Contact me if you want to try this game yourself and need more information. (I did 4 cadences the last time and thought it was quite enough. It took approx. 60 minutes.)

I wanted to get some feedback on “Show me your Data!”, so I held a session at “Play 4 Agile 2013“.
Thanks for the honest feedback from the participants. 🙂

Here it is:

  • Definitely a good exercise to explain how SAC works
  • Easy to understand exercise
  • When introducing exercise: Point out that you want to measure Lead Time (not Cycle Time).
  • When  introducing exercise: Point out that this exercise is not about WIP limit
  • Don’t emphasize on SLA. Rather ask the team to encourage some Kaizen:
    Why did the tasks above Average Lead Time took longer? How much longer did they took? How could we reduce the Lead Time of those tasks?
Kanban, Scrumban

Visualizing Kanban Lead Time

Measuring the lead time is one of the three core means of Kanban (next to Workflow visualization and WIP limitation).  But whereas Workflow visualization and WIP limitation are easy to understand for the team, I experienced that nobody really cares about what to do with Measuring the Lead Time. This week I tried a different approach visualizing the Lead Time and got instant feedback from the team. 

One of our team is working with a two tier Kanban with an additional fast lane for immediate support tickets (similar to a bug line).
It looks like this:

kanban team board

We measure the lead time for the orange tasks as well for the blue tickets; Lead time clock starts from the moment the tasks/tickets are moved to In Progress and stops when they are moved to Done (blue tickets) / Done-Done (orange tasks).
We are not starting the clock when the ticket or task has been created (as described in Stefan Roocks Post), although this seems very reasonable especially for requirements from other teams.
Why measuring the lead time?
In theory, the goal is to make the lead time as small and predictable as possible by optimizing the process.

In reality, nobody here really seems to be interested in the lead time, even though I’m sending out a report every 4 weeks that is also printed out and pinned to the team’s board. It shows an overview of all finished tasks/tickets visualized in some charts. Most probably my report doesn’t make sense to them.

As a consequence I tried a rebrush of the report this week.

It now starts with a chart like this:

visualizing lead time in kanbanI got fast and positive feedback from the team: What does the lead time say exactly? … Interesting number! It’s good that we have a number like this! … Now I understand why all tasks should have about the same size and why we have to break down the tasks into smaller batches …

It seems as if it only needed a (simple) visualization of the lead time to get the team’s attention. Now that I have the team’s attention we can start to make the lead time as small and predictable as possible.

BTW: A much better agile coach than I am suggested to use the median of the lead time and not the average. This defintely makes sense!