Playing Get Kanban with an Experienced Team

One of my most popular posts is “Kanban Isn’t the Point” where I wrote about the four stages of competence and how people may flow through the stages with respect to learning Kanban.

Recently I had the opportunity to run the Get Kanban game with an experienced team that has been using Kanban for quite some time and it was interesting to hear the different types of discussions that were generated compared to when I’ve run the game with people new to Kanban. Shocking, I know.

At one point in the game, (spoiler alert!!) a situation happens that is designed to have work pile up with the testing team and the whole system grinds to a halt. Poor testers, always getting beaten. Anyway, how did the experienced team respond compared to in-experienced teams?

The Response from People In-Experienced with Kanban

– aaaaahhhhh! look at all the work!!! This isn’t fair!!!! no way!!!! The response gets worse when the next event happens that makes the situation worse!

The Response from this Experienced Team

– no problem. The response was the same when the other event happened too.

Notice the black line? That’s flow!

The difference between the two teams is that as soon as the game started, the experienced team looked at the work on the board, the amount of effort required for testing on ALL the cards on the board and the fact that there are only 2 dice (therefore 2 testers) in the testing column, they immediately saw a bottleneck forming and exploited it.

They were focused on flow. Notice the CFD, you can see they quickly adjusted to focusing on testing right away (the lagging indicator is where the green line goes flat on the left side of the chart). The black line (delivered stories) is almost perfectly parallel which shows consistant value delivery. There are no signs of problems due to the 2 testing events because of how the work was managed.

The board when the ‘Carlos’ factor kicked in

The teams new to Kanban are focused on maximizing the work in progress because the theory is that the more you work on, the more you get done.

Other Observations – Experienced Team

They counted total effort represented by circles on the story cards and related that to cycle time.

They immediately reduced WIP in the ready column by not pulling in more stories even though the game didn’t tell them to.

They were fined $2200 for not finishing a fixed date story because their math showed it was more effective to get other stories done that had higher value that would offset the fine. Obviously in this case there is no damage to the company, in the real world a fixed date could be a legislative change which has more severe consequences.

They delivered a story with every roll of the dice

They finished all the improvement stories and received the benefit of reduced development and testing time.

They worked as a team, considering each team members perspective

They use the data on their charts, the data on the story cards, the “trend of the rolls of the dice”

They see slack time as a good thing (these guys called it facebook time)….and they tracked it just in case.

Other Observations – New Teams

They always pick the highest value stories without considering effort. That makes the situation worse when the testing problem happens because by that time all the stories in test are high effort

They maximize WIP, and in the newest version of the game some teams DOUBLE their WIP limits.

They always do the fixed date story and usually don’t talk about tradeoffs of doing stories that have less effort and more value

They rarely do improvement stories

They ‘flatline’ often in value delivery (not delivering value every roll as shown through the CFD)

They are very impatient!! The most dominant personality wins and decides the strategy

They see slack time as waste…more work could have got done

To be clear, I’m not picking on new people who play the game. The point is, when adopting any new process the only thing that is going to help people and teams adjust to using it effectively is time.

Over time, experience teaches people how to “see” when looking at a Kanban board. The reaction to a Kanban board changes from “wow, a wall with sticky notes” to “holy shit!! there is NO WAY we’re going to get all that done!!”

It’s important to remember the 4 stages of competence when bringing change into your organization because progress is going to grind to a halt (or slow considerably) no matter what you do. Chaotic systems are unpredictable and change brings chaos. Experience is built by living through the pain of chaos through to integration of the transforming idea into the new status quo. It’s a natural change process and in order to progress through the 4 stages of competence all you need it time.

you get 2 analysts, the other red die (it’s actually pink) is for a special event later on in the game.

I don’t like the initial walkthrough, I simply start the game and facilitate day 9 without being prescriptive. The instructions are confusing. You roll each set of dice once to simulate a day starting with test, then development, then design work.

The instructions could be more clear about that.

DarynHolmes

Thanks for the speedy reply.

If I have understood you correctly it seems like you roll all the test dice, then all the development, then all the design.

That seems like a different approach to the one in the guide. I noticed in the day 9 walk through they show the following for the first roll: Orange: 4 Blue: 3 Red: 5
That seems like they roll one of each in the set of 3.

I will follow your advice about not being prescriptive at the start. I will probably go through the first 2 days slowly with the teams. Then I will bring in the ‘reward’ for being the first team to finish.

Thanks for your help with this. Any other tips would be most appreciated.

DarynHolmes

I really appreciate the underlying message here about the 4 stages of competence.

We are doing Scrum at the moment. With our situation I feel that a kanban approach would suite us better. I would like to see less focus on estimation and sprint planning and more focus on average cycle time and global optimizing of the delivery chain.

As you have pointed out ‘change brings chaos’. I suspect a gradual approach would be best. I was wondering if you have made such a transition in a team. If so, do you have any tips on where to start, what to look out for, what time frame did it take you and your team?

Hi Daryn, what does the rest of the team think about switching to Kanban? I tried that once and it didn’t work because the team was quite happy with the status quo. I was the only one who saw less than half the spring work getting done every sprint as a problem. When we tried it, no one really bought into it and at the end of the day they went back to their dysfunctional habits and first blamed Kanban, then me for suggesting it.