Motor City – A Kanban Game : Overview

Game Overview

The game is designed to reflect a simplified operating of a delivery pipeline for a car manufacturing plant.

The player accepts orders from customers, chooses which products to make and allocates resources and manages the plant to deliver cars to customers in the most effective way possible.

Kanban

Each player manages a separate board representing a factory, the board is laid out as a Kanban board and the production is tracked as it moves across the board.

Wip Limits

In the core game WiP limits are optional. Players may choose to apply WiP limits to manage flow, or just use their instincts.

If played for fun the WiP limits are not explicit, but if using this in a training environment I’d encourage explicit limits and for them to be strictly enforced to enable the class to evaluate the impact of WiP limits on the game.
I’d also suggest that each player experiment with different WiP limits to compare the impact with each other and discuss the results.

Accepting Orders

At the start of a shift a player may choose to review and accept an order, once accepted an order must be delivered and if the player fails to complete an order they will be penalized.

Sourcing Materials

Each shift all players may choose to source materials for their production, this is done by selecting vehicle cards from the available selection, only 4 cards are visible and players may only choose from those available – this adds some competitiveness over resources, and an element of understanding your constraints and dependencies.

Production

At the start of each hour within a shift one player rolls dice to determine the available production points for all players (all players get the same to make this game about the allocation of resources rather than the luck of the dice.

Each player is allocated a quantity of Manufacturing, Assembly and Quality production points which they can allocate over the course of the hour. Unused production points are discarded. The player also has the option to trade production points of one type for another but at a 4:1 ratio to indicate the impact of repurposing machines.

The vehicle cards are pulled through the system and production points are allocated as they progress through the system.

Bottlenecks

There are a number of potential bottlenecks in the system and how you manage these will heavily impact the result of the game.

Game Success

Ultimately the winner will be the one that manages the production most effectively to meet their customers’ needs. It is hoped that applying Kanban and Theory of Constraints Practices will be rewarded, although there is an element of game mechanics and chance.

Purchasing the Game

The game is for sale at $120 + postage and is available now. Game contains 4 game boards so is suitable for 4 players (or 4 pairs).

Please email me at john.yorke@yorkesoftware.com to arrange to buy the game.

Thank you for your support and encouragement.

New Kanban Game Available

Around two years ago I was introduced to a Kanban board game which we used as part of a training program and I really enjoyed it, it was a great learning tool but it had three major drawbacks.

First it was heavily scripted and so it was only suitable for a single play through, you couldn’t replay it and get more out of it. It was not a game in that sense, it was much more of a training tool/prop.
The second issue was that the exercise was taking 3 or more hours to run and whilst Kanban is a critical aspect of the training the return on investment was not sufficient.
Finally it didn’t effectively address Little’s Law or the Theory of Constraints, there were aspects of that in the game but the heavy scripting meant that the learning was masked or even lost.

A New Kanban Game

It got me thinking and so I created a couple of workshop games that addressed this in more detail. One of those workshop games was such good fun that I expanded it and combined it with training. For the last year or so I have been running workshops using it and continually looking to find improvements and modifications to make it more fun or to emphasize the learning aspects.

I have now presented this at a number of Lean/Agile conferences and have had a lot of great feedback, including a lot of encouragement to publish it as a board game.

And so Herbie* – the affectionate name for the workshop game, became Motor City a Kanban based board game. That is first and foremost fun to play and re-play, but the game is under-pinned with an understanding of Kanban, Little’s Law and the Theory of Constraints. You can play the game without any knowledge of those and it will still be fun, but people that instinctively apply those practices or use them as a result of understanding will fare better playing the game.

*Herbie was named after the character from the book The Goal, by Eli Goldratt.

Game Prototype (Early Access)

The game is now in prototype, with a small number published for evaluation and for use in training and conferences, with the intent to publish the game more widely after getting feedback from the prototype.

To purchase the game…

The game is provisionally priced at $150 but for early access to the prototype it will be charged at $120
I’d love to hear of anyone that uses this as part of a training program or just as a fun game for your team to play.

If you would like a copy of the prototype board game for evaluation and feedback, please contact me.

Similarly if you are interested in training on the Theory of Constraints or Kanban and would like to use this game as part of that training, I would be happy to offer guidance on how to incorporate the training into a workshop.

Thank you

Thank you to those that have supported and encouraged me, I can assure you that board game design is far more complicated, costly and time-consuming than I ever imagined. In particular thank you to Toby Gerber who has helped with the graphic design and turning my ideas into reality, I could not have done it without him.

Henry Ford – Master of flow

I have recently been presenting a talk on WiP limits and as part of my research I spent some time looking into the history of Henry Ford as he was one of the most influential pioneers of what today we would call Lean or Kanban. He was the pioneer of almost all of our current thinking in industry, and I think was a thought leader in how Agile Software Development is now done.

Theory of Constraints in action

What really struck me however, was how he exemplified the thinking processes behind the Theory of Constraints in all his actions. Everything I read drew me back to that thought.

Ford reduced the average time to produce a car from over 12.5 hours to just 93 minutes.

Ford and his team (I won’t get into the debate as to who had the ideas) created a production line and improved upon it, first by making it a moving production line to keep the focus on flow. Initially simply a winch and rope to pull the vehicle and conveyor belts to deliver parts to the workers. This simple change alone saved hours, previously the workers had dragged their tools along the line of static vehicles as they were assembled.

At one stage the production line for the Model T took 12.5 hours but over the next 5 years Ford reviewed every procedure and managed to cut the production time to just 93 minutes, he cut 11 hours of waste out of an already efficient and profitable system.

Ford cut nearly 90% waste out of an already efficient and profitable system.

Was it a big deal?

Was it really that big of a deal? Yes! In 1914 Ford produced more cars than everyone else, not just more cars than his competitors but MORE cars than all of his competitors in the world combined.

He also produced more with far less, Ford employed 13,000 employees, his competitors combined had 66,000 employees, so the productivity of his employees was 5 times the rest of the industry average. That fact alone makes you sit up and take notice.

In 1914, Ford’s 13,000 workers built around 300,000 cars — more than his nearly 300 competitors managed to build with 66,350 employees.

Continual Improvement

It seemed like no improvement was good enough and Ford was continually pushing for the next improvement, 5 years of asking What’s next. Identifying every bottleneck and then the next bottleneck, his obsession for improving flow must have been relentless.

Fighting against local optimization

But Ford was not understood by his peers who’s focus was on Local Optimization, and even his own sales team who couldn’t understand his desire to simplify the design or reduce the price, they wanted options and variety. Ford wanted a car that was affordable to everyone.

Over the years Ford reduced the price of the Model T from $850 (approx. $22,000 in current terms) to just $265 which was less than 3 months wages for his workers.

The price of the Model T reduced from $850 to just $265 as a result of improvements.

His vision was to have a car available to everyone, but especially farmers, and the Model T was designed to be an effective Farm tool, and could easily convert to farm equipment.

I will build a car for the great multitude. It will be large enough for the family, but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary will be unable to own one — and enjoy with his family the blessing of hours of pleasure in God’s great open spaces.

Henry Ford

People Problems

One of the biggest issues that Ford faced was with his workforce, factory workers were unreliable and his new method of simple repetitive tasks and his desire for rapid growth meant he had high turnover and lower quality workers.

The manual processes Ford devised for assembling the Model T were not complicated but benefitted from training and consistency, so the lack of reliability and consistency of workers was an issue for him.

His solution was to double the average pay of factory workers, Ford offered $5 per day, he reduced the working day to 8 hours and the working week to 5 days, he also offered a form of tenure (on his terms) to all employees.

Ford quipped that it was the best cost saving decision he ever made, with a massive reduction in turnover the cost of training plummeted and productivity soared, and what was really a marketing bonanza his workers could afford his cars.

Blunder or Crime?

This decision was national news. But much of the press despised him helping the poor, seeing it as a social policy rather than a sound business decision. The press too seemingly had no comprehension of the Theory of Constraints or system level thinking.

They believed he was hurting business, with one major paper calling him a ‘class traitor’, and commenting that he shouldn’t bring “biblical or spiritual principles into a field where they do not belong.” going further suggesting that paying factory workers that much “was a blunder, if not a crime … against organized society“. That is pretty harsh for a man just wanting to pay people a little more so he could build cars.

Ford had the last laugh though, employee turnover declined radically, and profits doubled to $60 million in 1916 two years after the policy was introduced from $30 million in 1914.

Any customer can have a car painted any color that he wants, so long as it is black.

Henry Ford

Was the Model T only available in Black?

This for me is the most interesting story of all. Some say it is simply a myth, as the Model T was available in many colors over the years, others say it was a metaphor for his policy of being lean, others that it was a metaphor for his dominance in the field and how he could dictate what the customer wants.

Ford himself claims he made the statement in 1909, and yet he didn’t limit production to Black until 1914, and oddly in 1909 you couldn’t get the vehicle in black, it was not one of the 6 color options available. So the quote does have an enigma quality about it.

However, In 1914 Ford restricted the option to only Black and it remained that way for 14 years before expanding to 14 color options shortly before the Model T was replaced with the Model A.

Cost saving?

I have read that the decision to limit to black was a cost saving exercise, with a suggestion that the unit cost of black paint was less than the color options but I have been unable to validate that claim and frankly I find that very hard to accept. Unit cost considerations have not played a part in any of his other major decisions – the wage decision being a clear example of how flow was far more important to him than unit cost. Cost savings were a consideration at a system level only and certainly not a factor if it impacted on flow.

It is all about flow

From what I can deduce from applying lean thinking myself to the situation, Ford would have switched to black even if the unit cost had been significantly higher. Japan Black paint was completely different to the other paint methods and had two distinct qualities that would have appealed to Ford, the first was that it touch dried very quickly and secondly it baked hard in 48 hours, compared to 14 days for the other colors.

Increase flow and reduce Cycle-time

Because the paint could dry quicker it would improve flow and so a production line was able to complete a car every 3 minutes (with 3 minutes effectively being the slowest process on the line).

Reduce Inventory and reduce Lead-Time

For Ford, being able to ship cars from his factory 12 days sooner than previously was massive, he could reduce WiP, but more significantly it enabled him to reduce his inventory of finished goods by 85%. in 1914 at any given time he would be sitting on over $5 million (retail value) of stock, by switching to Japan Black he was able to ship more and more-sooner. That decision would have been an instant injection of over $4 million dollars (that is over $100 million dollars in 2017 terms). And by 1923 if he had still been offering colors that inventory cost to him would have been over $30 million ($750 million – 2017 value). Not to mention the space needed to store 80,000+ vehicles while the paint dried.

Using only black paint was a $750,000,000 Decision

In essence the decision to ONLY offer the Model T in black was a decision worth far in excess of $750 Million in todays terms, and yet very few people understood the ramifications of that decision and many opposed it or ridiculed it, and many still don’t understand it, even with the results being self-evident.

What is Productivity?

Business is a lot of numbers, and I don’t want to bore you with figures but the improvements that Ford made to flow and cycle-time and lead-time all went straight to the bottom line, by focussing on flow rather than local optimization, and by focusing on the throughput of the whole system rather than on keeping one worker busy, Ford was able to get his workers to be 5x more productive than the competition by doing less work.

Thinking is the hardest work there is, which is probably the reason why so few engage in it.

Henry Ford

Ford showed the correlation between effort and productivity is a myth, and it is about working smarter not harder. He passed his efficiencies on to the customer, as his productivity went up the price of the Model T came down. Eventually to just $260 in 1925 which is a mere $3600 in 2017 terms. A car truly affordable to the masses.

System Thinker

Ford seemed to understand Systems Thinking and the Theory of Constraints long before either were recognized, and he did so to a level that few of us will ever be able to comprehend and in the face of public and private pressure against this way of thinking and he was often vocally opposed for his decisions.

Ford changed not just his own organization but his actions changed an industry and likely even the economy of a country. He balanced profitability with altruism, although some of his values and politics were questionable and some of the rules he imposed on his workers would be unthinkable today. But for me he is the pioneer of Lean, Kanban, and the pioneer of the Theory of Constraints, everything since then seems to be built on his shoulders.

Do you know ‘what’ your problem is?

The title is a little tongue in cheek, because in my experience it is the ‘what‘ that is likely your problem. We focus far to much on what we are doing both in our work and in our product, and far too little on why we are doing it.

Failing to understand the why

The obsession with local efficiency and and maximizing utilization of people is crippling customer focus and value.

There is nothing so useless as doing efficiently that which should not be done at all.

Dr Peter F. Drucker

Peter Drucker has some very inspiring quotes but that one is by far my favorite and one that I wish was better understood and adopted in practice

We look for work to stay busy, whether it be setting up grand databases or magnificent CI solutions. I am not saying either is unnecessary, but does the solution fit the need? Were they built when needed or in anticipation of a possible future need?

The focus on lead/cycle times can result in stories becoming rushed, the focus becomes on getting work ‘done’ as quickly as possible, rather than a focus on getting the work ‘done right’. We are completing work quickly at the expense of adding value. It also leads to ‘creative accounting’ where the desire to reduce cycle times results in the definition of done getting corrupted.

Refactoring gets sacrificed when throughput is the priority.

Stories focus on the what not the why.

We are often in such a rush to complete we either skip the why entirely or we take the easy route and look for a ‘why’ that satisfies our ‘what’ rather than actually asking why or giving it proper thought and effort into understanding the real why.

Of course the “Why conversation” can be hard, or time consuming and sometimes it seems obvious but can be hard to articulate. Story writing is a time consuming process but when the process becomes rushed there can be a tendency to prioritize stories according to what is written or what is easy to write rather than what is the next priority based on value or other prioritization methods. We tend towards keeping people busy and the process flowing rather than ensuring we are delivering value and working on the right thing.

It is far too easy to get into a cycle of business as usual, all the time running to catch up but not really knowing if you are working on the right thing. But because everyone is busy and something is getting done “Asking why?” drops below the radar and the hard question of value does not get asked.

Step back and evaluate if you are working on the right thing. Sometimes going slower is actually going faster.

Taking a little while to do it right could well pay dividends. Our goal should be to give our customer the most value, not maximize how busy we are. And whilst logically these two should be related, in reality the opposite can be true.

Learning to write good stories with an emphasis on understanding the why this story adds value, learning to prioritize with the emphasis on why this story is the one we work on next can make a huge difference to a project delivery. Incorporating story maps; road maps, story boards and utilizing other prioritization techniques can help your product deliver the right thing.

The customer should be your focus

Your product owner should be able to articulate clearly and confidently why the next story is next and that justification should be customer centric. Your goal is to make the customer happy NOT to keep your team busy.

When lead/cycle times start to become more important than refactoring it leads to a degradation of the system, either in terms of a reduction in the quality of the code, or an increase in technical debt, but more often a reduction in quality of the user experience.

UX is an afterthought

When we teach story writing we teach the INVEST method, the I is independent, and V is valuable, but I wonder if the independent is misunderstood, especially when it comes to UX. The goal of a story is NOT to minimize Effort, it is to maximize Value. Sometimes we can maximize value by minimizing effort (ROI: Return on investment) but our goal is still the value and NOT the reduction in effort.

The goal of a story is NOT to minimize development Effort, it is to maximize customer Value

A story that adds new functionality could easily be tagged on to the existing system with little redesign of what already exists, e.g. We add a new tab or a new page or a new button, just append it to what is there. In some circumstances this may be the right outcome, but it should be a conscious decision not a default lazy way out.

A new story that is adding functionality should be assumed to be incorporating that extra functionality into the system where it fits best for the user and maintains the user experience and flow NOT where it is the easiest to integrate by the developer. If we just tag on new functionality without consideration for the user or the existing system it can quickly become ugly and cumbersome. Sadly the prospect of changing completed work – especially visible work can be daunting and many teams are resistant to make changes to the UI, instead preferring to add new functionality where it is least disruptive.

Each new story especially UI stories should require some reflection and a conscious decision to maintain flow and look and feel and maintaining the user experience, maintaining the user experience may very well be more valuable than the new functionality adds.

Acceptance Criteria is a substitute for thinking and conversation

We can get so focused on delivering quickly and meeting AC for a specific story that we become blinkered, we know we need to maintain quality in the sense of stability, reliability and security, but we can easily forget about the less quantifiable quality of the user experience of the system as a whole. We can seek to address the acceptance criteria without thinking whether what you are doing truly adds to the value of the product (not story) and when A/C is specific we don’t question whether it is right, we skip the conversations.

Being busy is not your goal

It can be a very hard adjustment especially when you are paid by the hour, or even bill by the hour, for us to accept and understand that sometimes the most effective use of our time is not keeping busy. It may be to do something inefficiently or to not do anything at all. Keeping you busy is not the goal, delivering the best product to the customer is.

Why do we use WiP limits?

I participated in a great discussion this week on the use of WiP limits. For those that don’t know, WiP stands for Work in Progress, and is a measure of how many activities you have started but not completed.

It is important to note that this is not a measure of how many tasks you are currently actively working on. If I started a task but have become blocked, so I start another then my Work in Progress is 2 – even though I am only actively working on one. WiP is a measure of how many started but incomplete tasks I have.

For example: call-waiting or being put on hold during a phone call: You are talking away and get another call so you switch to the second call without hanging up, and when you get another call you take that too, how many people can you have on hold at once? You are only working on one call at a time, although you must remember the content and context of all those other calls. For the people still on hold while you have all these conversations I expect they are wishing you had a WiP limit. Your WiP-Work In Progress is the sum of all active(incomplete) phone calls.

Limiting WiP

There are many reasons for limiting Work in Progress not least because I hate being put on hold. I will go in to some later and it is likely that if you follow any type of Agile framework you already limit WiP although you may not be consciously aware of it.

If you have a backlog, then you are limiting WiP. You are consciously choosing not to start new work immediately but are prioritising it and organising it to work on later. It is likely that you are informally limiting your WiP according to what you feel you or your team can manage at a given time. It is important to realise that this is a WiP limit even though it may not be conscious or scientific.

If you follow Scrum: WiP is consciously and explicitly limited at Sprint Planning, often by estimating effort, or counting stories or calculating story points. The limit is generally set based on Velocity – our average achieved over previous sprints. If on average we finish 10 stories a Sprint, or we average 35 points, then that average is generally taken as the starting point for our WiP limit, we may choose to push for a few more, or if we are expecting to be slower due to vacation time, or known issues we may choose to commit to less. But in Scrum we don’t usually refer to it as a WiP limit. But that is exactly what it is.

KanBan is actually very similar, if we on average are completing 10 stories a week, then it is likely that we will consciously or subconsciously limit ourselves to only take on 10 new stories within a week, although in the case of KanBan this is not done in a Big Bang explicit decision but gradually over the measured period and is more a consequence than a plan (A Pull rather than a Push). We pull stories when we are ready and we pull at the pace we are working at, that just happens to be 10.

Slightly off-topic, but one of the crucial differences between Scrum and KanBan is that Scrum is a ‘Push’ model and KanBan is a ‘Pull’ model. In Scrum we Push an amount of work to the board and spend the Sprint working to Remove(complete) it. With KanBan we are aiming for a more steady amount of Work in Progress and will pull new work as current work is completed, which creates a smoother flow, but conversely lacks a unified time based goal or target. But it is important to understand that both frameworks limit WiP and both focus on ‘completed’ work being the primary objective.

Why do we limit WiP?

I’d like to think it was obvious by now and I think the basic principle is, but there are nuances that may complicate things which may be where the cause for debate comes from.

At it’s simplistic level if I can only complete an average of 10 stories a week/sprint then starting an average of 20 a week without changing anything else is nuts, all that will happen is that on average 10 or more of those stories each week will remain incomplete and stay ‘in progress’ by the start of week 4 we will still have completed 30, but will have 50 now in progress. Chances are by now we will actually go slower because we will be distracted and falling over ourselves trying to juggle more than we can possibly achieve.

Think of all those people on hold, growing frustrated at being ignored, and you trying to remember all those conversations, the phone rings again, can you cope with another caller on hold?

We limit WiP because we understand that by working only on what we can achieve, we can focus and be more effective.

Limiting WiP and WiP limits

“Ah but you have talked about Limiting WiP but you haven’t mentioned WiP limits” I hear you say…

And this is where I think the conversation really stems from and where we get into nuances. KanBan began in manufacturing where work was passed from one workstation to another and there was a measurable flow through the system. Limiting the production on one workstation so that it maintained pace with the entire system limits waste. Having one hyper-performing efficient widget maker that can produce widgets 4 times faster than they can possibly be used is wasted effort. And the same applies to a software process, we use WiP limits to regulate one part of the flow to maintain pace with the flow as a whole, the goal is to visualise bottlenecks and by visualising bottlenecks we can take steps to increase the flow of the whole system.

Other forms of WiP limit

But WiP limits can take many forms and are applicable to almost all aspects of life. The most common example used is a highway, when a road gets busy it slows down, when it gets very busy it grinds to a halt. Limiting access actually speeds things up for everyone on the road, and ultimately more cars can get through far quicker.

But there are other less obvious WiP limits. A long-distance runner wants to increase her times, she starts fast but she runs out of energy and is slowing down near the end of the distance. By setting herself a slower time per mile early on (Pace is a form of WiP limit) she has a consistent speed and reserves energy so is able to run the full distance faster by slowing down during the early part of the race.

Are you dedicated to a single product/project? That is a very low WiP limit of 1 project.

Do you use a calendar and try not to book two meetings at the same time, that is a very tight 1 item at a time WiP limit.

What about a budget? Do you manage your finances as an individual or company. A budget is a WiP limit for your money, by limiting money spent on beer you have more available for clothes. By regulating your spending you can save for a holiday. By remaining in credit at the bank you do not have to pay interest and so on.

Example of how to choose a WiP limit in a workflow

In the case of the widget maker, if the system can only use 10 widgets a day then we may set his WiP limit to 10, when he gets to 10 he is free to go and help someone else. Suddenly rather than unused widgets we have an extra pair of hands to do other work. But hold on! these widgets are easy to make and only take a short while to do, we could probably limit WiP to a lower limit and jump on the workstation as an when needed to produce more. So how do we set the WiP limit? My advice is not very scientific at this point. Start by continue doing what you currently do and just watch, if your workstation/activity columns are sub divided in to doing and done, take a look on a regular basis and see where the biggest stacks are. If one column regularly has more cards on the done column than doing, it ‘may’ be a sign that you should reduce your WiP limit for that activity. Try it and see if it improves your flow.

The largest queues of done work are usually the area that needs limiting, but be aware of ‘bursts’ of activity, for example there may be a workstation that is only available for one day a week, in which case the queue for that workstation may need to be longer – or maybe you should be asking for more regular access to the workstation. But when imposing limits do it gradually and monitor to see if it improves the flow.

Anything in a done column is normally waste, if it is done and not in production that effort cost you money and is just sat there. Sometimes that makes sense but the car industry learned that complete cars sat in storage amounted to $millions of wasted investment, that components stockpiled in advance was essentially big piles of cash that could be used more effectively, we can learn the same.

What I am saying is that a WiP limit being reached is a conversation trigger, a long queue is a conversation trigger, and so on. With so many things in Agile we create early warning systems to create conversations and make decisions when it is necessary. We make small changes to the process and watch, we see what changes and if it is better we carry on, but look for another new small improvement.

Summary

WiP limits are not unique to KanBan, and like it or not you are already limiting your work and activities in all aspects of your daily life, you just perhaps didn’t realize it. In the context of a KanBan board we do not arbitrarily impose a WiP limit because we can or because it is fun. We impose a limit when we feel it adds value, normally where we see a queue of completed work growing faster than it is being consumed. We limit various stages of the work because our goal is the output of the system (the whole team) and not the perceived utilization of individuals. One team member being 100% occupied all day producing something that will sit untouched for a week is not efficient.

We are not trying to manage a system where our goal is to keep busy a group of individuals, our goal is to create a cooperative and coordinated team working towards a common purpose in the most effective way possible. A WiP limit is just one of many tools that can be used to enhance the prioritisation of work and focus the team on the true goal.