Kanban, Meeting Facilitation

A Kanban Team Retrospective Activity

ticket-kanban

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).

Spectral-Analysis-Chart-Retrospective-1

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

Spectral-Analysis-Chart-Retrospective-2

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.

Spectral-Analysis-Chart-Retrospective-3

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!”

kanban-game-2

Preparations:
– 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)
Etc.

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.”

kanban-game-1

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.)

UPDATE MARCH 2013:
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, Meeting Facilitation, Scrum

“Sexy Not-So-Sexy Tasks” Retrospective Activity

In one of the last retrospectives a team member complained about the “not very sexy” tasks the team had to do. Well, we all know that life is not all beer and skittles. Nevertheless I think, the team member was actually pointing out, that the “sexiness” of tasks can have impact on the general motivation of the team, of course. That’s why I was introducing the “sexy <> not-so-sexy” activity in the last retrospective. (As this idea originated in the team member’s comment I also call it “The Thomas S. Approach”. 🙂 )

sexy-not-so-sexy-tasks-agile-retrospectiveIn general, the team’s job is split in tasks on a support level (approx. 65%) and project tasks on a product development level (rest of their time). The team is working with a Kanban system and is using several Scrum ceremonies (regular retrospectives, review meetings, agile estimation for project tasks etc.).

The “sexy <> not-so-sexy” activity fits perfectly in between the check-in (“Setting the stage”) and “Gather Data” activities and is as easy as this:

1) Prepare a chart that shows a line between “sexy” and “not-so-sexy”.
2) Put all “done” tasks on the table and let the team stick them on the line accoring to the task’s “sexiness”.
3) Discuss (“Any suprises? Any patterns?”)

Why I think this acitivity works:

  • The team is reviewing their finished tasks while sticking it to the flipchart. (Reflection: “Cool, we have done quite a lot.”)
  • The team is re-evaluating the tasks. (Reflection: “Wow. That was a cool task.” or “I really hated that task.”)
  • The PO (Note: The team decided to have their retrospective with the PO.) realizes that different tasks can have different motivation.

Of course, the activity also shows the big gap between doing tasks that have value (“sexy”) and tasks that are simply stupid mechanics (“not-so-sexy”). Team members are aware of that. And it does have impact on the motivation if you are only doing “not-so-sexy” tasks.

As there will always be “not-so-sexy” tasks: Maybe there is a way to morph “not-so-sexy” tasks into “sexy” tasks? Any suggenstions?

UPDATE FEBRUARY 2013
The activity has been refinded after discussing it with one of the team members. He pointed out, that value is more “valuable” than sexiness. As a consequence I added the value dimension to the chart.

Sexy-Value-Added
Sexy & Value-Added Matrix
Agile Coaching, Books, Kanban, Scrum, Scrumban

Soft Agile Transition: Slowly from nowhere to Scrum

Lean Thinking is what I’m trying to learn and adopt at the moment.
What a perfect coincidence that I stumbled over Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum from Craig Larman and Bas Vodde. On page 54 they describe Kaizen, one of the crucial Lean Principles, as a plausible “inspect & adapt”:

  1. choose and practice techniques the team and/or product group has agreed to try, until they are well understood
  2. experiment until you find a better way
  3. repeat forever

When I try to find this Kaizen practice in my work of the last years, it fits to what I call the “soft agile transition from nowhere to Scrum.” 😉
Here is the formula:
(0) Nothing > (1) Daily communication > (2) Visual Workflow > (3) Kanban > (4) Scrumban > (5) Scrum

When we started working with agile techniques we had a divergent mindset in our product teams. Only one team was ready and willing to start with Scrum straight away. Other teams were reluctant to try anything agile and stayed with “Nothing” or were led by project management.

By now all our teams are somewhere in the “soft agile transition from nowhere to Scrum” and I’m happy that all of them have passed step “(1) Daily communication” already.

The above described Kaizen was my fundamental line of action to move step by step from (0) to (5).

What are your experiences with introducing agile techniques to your company?

from nowhere to scrum via kanban and scrumban

Characteristics of the “soft agile transition from nowhere to Scrum”

(0) Nothing
– Black Box
– Led by Project Management

(1) Daily communication
– Daily Scrum

(2) Visual Workflow
– Daily Scrum
– Team board
– Regular Retrospectives

(3) Kanban
– Daily Scrum
– Team board
– Regular Retrospectives
– WIP
– Lead Time
– Optimize size of batches

(4) Scrumban
– Daily Scrum
– Team board
– Regular Retrospectives
– WIP
– Lead Time
– Optimize size of batches
– Agile Estimation
– Regular Review Meetings
– Release Plan via Lead Time

(5) Scrum
Do it without ScrumButs

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!

Books, Kanban, Scrum, Scrumban

3 Retrospectives in 2 Days

Last week I had retrospectives with three different agile teams within 2 days. I love retrospectives and a retrospective meeting is one of the first agile things I try to establish when I start working with a team. Every team needs to get used to the advantages of retrospectives though…

The agenda for retrospectives always includes the following 4 questions:

  • What went well since our last retrospective?
  • How can we do better, how can we improve our process?
  • Is there anything we CAN’T change by ourselves?
  • What in detail will we change until the next retrospective?

Besides those questions I experienced that a warm-up at the beginning is more than helpful: Draw a timeline of the past sprint (or period of time concerned in the retrospective) on a flipchart. Ask the team “What has happened in the last weeks?” and then let the team put sticky notes with their answers on that timeline.

The warm-up helps everyone to get their minds focused and it shows that everyone in the team can have a different view of the past couple of weeks.
In addition:
For teams that work with a Kanban system it is sometimes difficult to see what has been accomplished in the last weeks. This warm-up shows them that a lot of work has been finished.

Maybe you like to try out 2 things I experienced as useful:

  1. Have a short break after you have answered the first question (“What went well since our last retrospective?”): It could be a smoking break or as simple as just opening the windows to let in some fresh air for some minutes. The team (normally) has just mentioned a lot of positive things, so try to keep the good vibes for some moments! 😉
  2. Feel comfortable with the silence while the team is writing their sticky notes. Don’t hustle the team when the team seemingly is not writing anything more. Sometimes it only takes a couple of seconds and someone starts writing again.

Read “Agile Retrospectives: Making Good Teams Great” from Esther Derby and Diana Larsen for different tools and recipes in retrospective meetings.

In the next weeks I will try to write a post about how to get the results of retrospectives done.
[Update Sept. 07, 2011: Done. 😉 Please read How to Deal with Results from an Agile Retrospective?]