How to introduce Kanban to a new team

Bringing an Agile Way of Working (WoW) to a new team is a learning experience for everyone involved, including me!

Some time back, I was hired as a Project Manager for a Security Team. We were keen to fix old problems, one of those was over-promissing whilst under-delivering, So we decided this was a good team to bring into the Agile fold.

I was lucky to find my self in an organisation that had an existing Agile Coach, so I reached out and asked how he might get my team ship-shape and raring to go.

The team I joined were relatively new, whilst some of the team members had long careers behind them at this particular employer, the team function was a relatively new addition, and with new, comes opportunity.

Selling Agile

I asked everyone how long they said a piece of work would take, and then I asked them how long that piece of work actually took. Some estimated too little, others, too much and some apparently estimated just right. I then asked how close was the product to what the customer had requested. No one knew.

With the help of the agile coach, we planned a sequence of meetings.

Meeting 1; Why Agile, Why Kanban?

In the first meeting, and as per this post on a Kanban Agenda, I setup an oversized kanban board along one wall in the meeting room showing my meeting agenda.

I started with a brief introduction on what I was proposing to do, and why. I explained what the kanban agenda was and asked the team to flag up to me if I forgot to move something, and then we began.

This is important as it introduces the most basic of kanban workflows (to do, doing, done) and focuses the attendees on moving the cards, this is an important part of the visuals in Agile delivery.

A small game…

Whilst preparing for the meeting, the in-house coach also used 2 walls to build 2 further Kanban boards. These are really simple and will be used to play a short game.

We’ve introduced the simplest of kanban boards, the next trick is to show the attendees how to actually complete a kanban board, the easiest way to do this is through a simple game, a game that does not require subject matter knowledge, i.e. trying to build a game around developing an app could hugely backfire if the team spends their time criticising your knowledge of the development life-cycle vs the actual kanban game.

For this game, you split the team in half, or in groups of 3/4 if you have a large number of attendees. You give each team member a coin or something that can be used to generate a 50/50 outcome (i.e. Heads or Tails, 1 or 2, A or B, etc).

Game 1 – The problem with Work in Progress;

For the first iteration, we follow these rules:

Everyone takes a card from the To Do column, write their name on it and move it to Doing
Everyone flips a coin
If you get Heads; you can

Move a card from To Do to Doing (add your name to the new card) or Move a card with your name from Doing to Done – or If you had a blocked card, you can remove the block

If you get Tails; you must

Add a B for blocked to a card in the Doing column and Take a new card from the To Do and move it to Doing

Repeat 5 times (to represent a week)

We finish week 1 by calculating how many heads it would take to unblock and move all the cards from To Do or Doing to Done, so in the above example we have nothing left in the backlog (to do) but many cards that are blocked:

4x heads to unblock all of the cards
6x heads to move the cards from Doing to Done

Game 2 – Introducing the WIP and working as a team;

The main purpose of the first iteration is to show how the Work in Progress (WIP) can build up if unchecked.

For the second iteration, We’re going to add more cards to the backlog, but this time we’re going to introduce a WIP limit – for the game, the limit is the number of people on that team.

The rules are expanded:

You can only move a card to Doing if the WIP limit has not been reached
Everyone flips a coin
If you get Heads; you can