Posts Tagged ‘kanban’

I’ve always struggled a little with the concept of sustainable pace. Most examples are around team burn-out and not having a ‘death march’. I can buy into that kind of work-life balance idea(l) – although humans generally like a little bit of pressure to get things going – but always felt there must be more to it than that. Then I stumbled across this quote in an article:

‘Sustainable pace’ means that speed takes second place to good QA practices that keep technical debt low.

I like that. How do you feel about this statement?

I recently played a Kanban game with my new Kanban team. I’ve never played an Agile game before so was not sure how it would work, but had heard about the airplane game and how successful it is at teaching teams about flow, pull systems, cycle times, limiting work in progress, etc. After doing some online research, I stumbled across some variations of the traditional game, and was attracted to the Kanban Pizza Game. It looked fun and something everyone could relate to, plus it created the opportunity of actually ordering pizza for afterwards 🙂 The link goes into some detail about how to facilitate the game, so I won’t go into that here. I’d rather highlight some of the lessons I learnt trying to facilitate a game I’d never played or watched being played for the first time.

You need a helper!

There is a lot going on this game, not least of which ensuring teams don’t leave the pizza slices in their oven for too short (or too long without penalties). Thankfully I roped our Product Owner in at the last moment and he also helped with quality control and counting up for scoring, as well as keeping track of which slices had been “spoiled”.

Enforce WIP limits at least once

When I facilitated, I mentioned work in progress limits and enforced that each team had at least three stations (of their choice). In the close-out, one of the teams mentioned that they had set WIP limits but had not really stuck to them – or had changed them on the fly. My feeling is that some of the Kanban principles may have been more clear had these been enforced for the round. In hindsight, it may have worked better from a demonstration perspective to have enforced certain base stations and base limits to start with and then allowed the team to tweak them as the rounds progressed.

Track cycle times

The facilitator’s guide says measuring this is optional (perhaps because you really will need more helpers to do this). My feeling is that we lost a lot of the point by not tracking the cycle times between different rounds and changes to the process. We saw a significant improvement in the number of slices produced between rounds 1 and 2 (and one of the teams did observe that having a pull system – the orders – contributed to this), however, as things became more complicated, the points scored at the end of the round did not always correlate to improved efficiency. Cycle times would have also helped illustrate just how much value was being lost through wasted inventory.

Have a practice round

The group all said that they were more efficient in the second round merely because they had a better grasp of the process and rules. It may be an idea to run the first round twice before introducing Kanban concepts to mitigate this ‘learning’ effect on the outcomes.

Don’t give them timelines

The facilitator’s guide does warn why the team shouldn’t know how long a round is (watch out for clever teams timing a round for better planning!). I did let them know when we were busy with the final round, which in hindsight I probably should not have, as then they paced themselves to make sure there was no excess inventory at the end of the round rather than working towards getting as many orders filled as possible. I guess in real development this approach might make sense, but it didn’t really help from a demonstration perspective.


Things I felt came through quite strongly

  • Having stations.
  • The advantages of a pull system.
  • The group had fun!
  • The fact that the whole process was important: it was not helpful to have a highly efficient stickie cutter if the end-to-end process was too slow to consume the parts.

Things that didn’t come through as well

  • Limiting work in progress.
  • Impact of limiting work in progress on cycle times.
  • Having explicit policies (team felt that they were implicit).
  • Idle time.

Have you run this game before? What did or did not work for you?


Learning about Kanban

Posted: March 6, 2014 in Kanban
Tags: , ,

One of the teams I’m newly responsible for is called the “Kanban team”. This made me a bit nervous when I joined as my knowledge of Kanban was completely limited to some reading I did when trying to find a better way to visualise work while a team I was Scrum Master of at my previous company was going through a Lean Start-up phase. The Kanban team appeared to be functioning and was getting stuff done, but I found the board completely confusing and there didn’t seem any easy way to understand inefficiencies. My first task was, obviously, to try to find out a little more about Kanban and understand its principles, and I did this through conversations with colleagues who had been on the training and a lot of Google searches!

The first ‘retro’ I had with the team, I highlighted the main principles of Kanban, which are:

  1. Make workflow visible
  2. Limit work in progress (WIP)
  3. Measure lead time

We agreed that although the workflow was visible (via the board), we were not currently limiting WIP nor were we able to track our lead/cycle times. The first exercise was to review the workflow itself, which we approached with a ‘blank canvas’ approach, mapping the steps various items would go through to eventual release. This team is responsible for maintaining the system on a day-to-day basis, as well as building smaller features, which means some work is very ad hoc and other work is more structured and ‘plannable’.

The second session I presented a proposed version of the board (which was basically the existing board plus some additional columns) plus some suggested WIP limits for us to argue about. After much debate, we eventually agreed on a board that had similar columns to the existing board and was flipped (so that work items bubbled up the vertical rather than along the horizontal axis). The team agreed to track WIP at a ‘story’ rather than task level (although tasks were still added to the board for visibility), and we agreed on some WIP limits. It was a tiring session but it was nice to see the team take some ownership, although it took them at least a week to adjust to the new board once we got going.

Since then, we’ve made some minor changes. I posted up some policies (exit criteria) based on info we had, but we still need time to review and flesh them out (particularly our Definition of Done). I was also trying to track cycle time by tracking when stories moved, but this was proving difficult and time-consuming and prevented the team from moving items backwards (which is something they wanted to do), so we bought a date stamp (like they used to use in libraries) and agreed to stamp stories at three points in the process:

  1. When the story/item hits the board
  2. When it moves into the build phase (starting with design)
  3. When it’s tested and ready for release (done)

We haven’t been tracking tasks long enough to have any useful data yet, so I’ll have to see how this goes. The main thing I have noticed is that the team is still struggling with the concepts of lean, so my next big session will be to a play a game with them (similar to the airplane game) to try to demonstrate how the pull system is supposed to work. I’m hoping that they will then have an ‘a-ha’ moment and we can start focusing on improving our process. Think of it as a change management exercise 🙂

Useful links:

  • I found this comparison of Kanban and Scrum really useful as I could work from my existing knowledge.
  • I liked some of the task board ideas in this article.
  • And, in case you don’t know what it is, here’s more on the Airplane Game.