共用方式為

What’s up with us playing Kanban games in the garage?

  • 發行項

A couple of months ago a colleague, Ewald Hofman, delivered a phenomenal Kanban training at Microsoft Vancouver, using the getKanban. game. It triggered numerous discussions during and long after the event, and influenced posts such as planning … it’s all about people and the secret sauce to managing our backlog and TODO lists‎. The game offered an opportunity for teams to experiment with the concepts of Kanban and engage in a fun way.

Derek and I were hooked! We organised copies of the game for our Garage (a place for engineers to come together and experiment), started working through the game, and preparing to host games for our teams and the community.

Our first game after Ewald’s event

We agreed to these rules:

  1. No changes to any of the work in progress (WIP) limits
  2. Encourage DevOps
  3. Cleanup the board at the start of each new day

Here’s a snapshot at the start of our game day 10:
image

We encountered a few interesting events, which we’ll discuss later, and quickly realised that our first rule had a negative, and the second a positive side-effect. The third rule simplified the game by promoting consistency. It’s up to you to organise the board before, during, or after each day, just keep it consistent. 

Our cumulative flow diagram shows the flow of work over time. It highlights that we started (1) with far more work in progress (WIP), than we ended (2) with, one of the side-effects of not adjusting the work in progress limit.

And we achieved the following financial summary, which landed us in 29th position on Edwards list of game results:
WP_20170104_010

We’ll definitely play the game again, fine tune our rules, and observe the side-effects.

Topics to discuss

Here’s a few topics we discussed during the game. What are your thoughts? 

Is it important to observe and adjust the work in progress (WIP) limits?

During the game we observed bottlenecks and resource wastage in our Analysis column, which resulted in the development and test resources sitting idle. We were unable to sustain the flow of work, as we intentionally did not adjust any of the WIP limits. It became painfully obvious to us during the game that we should be adjusting our WIP limits to sustain the overall flow of work. So, YES, it’s important to observe and adjust the WIP limits.

Interesting related reads:

Should we care about blocked items?

SNAGHTML4d90b14b

During the game one of the work items was blocked and we had a vibrant discussion whether to unblock or simply ignore the blocked item. s the blockage occurred late in the game, affecting a medium value and ageing item, we agreed that to focus on the other work items and ignore the blockage. Had we not agreed not to adjust WIP limits, we would have increased the associated WIP limit to maintain the overall flow. Again this speaks in favour of monitoring and adjusting your WIP limits. In our case, we were unable to adjust the WIP limit, creating another bottleneck in the Test column.

So, YES, we should care about locked items. How we deal with the item depends on it’s value, our ability to resolve the blocker, and whether there are dependencies.

Interesting related reads:

Would you take a risk when you assign resources?

SNAGHTML4d8d3b8d

We had the scenario as shown above.

  1. Item E1 was in the expedite lane, with five development units of work left.
  2. Item S28 was a high value item, with six development units of work left.

Would you (a) commit two resources (2xdice) on E1 and one on S28, as shown, or (b) commit one resource (1xdice) on E1 and two on S28 to prioritise the oldest item?

We opted for option (a), prioritising the expedite lane. It also felt like the safest route, allowing overflow to be assigned to S28.

What’s the value of the Lead Time Distribution and the Run charts?

We maintained both charts for only half the game. We felt that effort to maintain the charts was higher than the value we got from the visualizations.

BUT, with more players, or in real-life (not in a game) and with more historical data, there’s a definite value in both charts.

Interested?

If you’re interested to enjoy a game of Kanban, please contact us and we’ll make a plan!

Comments

  • Anonymous
    January 17, 2017
    The comment has been removed
    • Anonymous
      January 17, 2017
      Edward, we replayed the game without the constraints and managed to support your thoughts.We monitored and adjusted the WIP limits and we assigned resources (dice) outside their their specialization. As expected we did not observe many of the bottlenecks and were able to maintain a continuous flow of work.We photographed all charts as evidence and to pin point patterns.In terms of risk it's also a matter of luck, as a throw of two dice can be anything from 2 to 16 :)We managed to get 2nd place in Ewald's list of results, which shows that careful WIP limit management makes a huge difference. Perhaps we can improve on that when we play the game at TR24!