A Facilitator’s Guide to The Ship Building Simulation
Introduction
The Ship Building Simulation is a powerful, yet simple exercise to introduce a group of people to the concepts of flow based work systems. Through practical experience the participants learn and understand the importance of Work in Process (WIP) limits and end-to-end optimisation.
This simulation was developed and made popular by Klaus Leopold from LEANability. It is described in Klaus’ book Practical Kanban.
Setup
- Build a long and narrow table with the participants sitting on each side of the table, similar to a production line, see image below.
- We will start folding ships at the head of the table, and the ships will be finished at the tail of the table.
- Prepare a flip chart for collecting the metrics and perform the calculations.
- Prepare a separate flip chart with “Little’s Law”
Instructing the Ship Building Process
Instruct the folding process for the ship. Each participant should perform a folding step for the ship. Make sure, that the last person performs several foldings steps, so as to have a bottle neck in the process.
The last person in the row, the scribe, will do the paper work and write down the arrival time of each ship. That is, we will start a timer and each time a ship is finished, the person writes down the time on the the stop watch. Make sure that the person writes down the timestamp as shown on the timer, demonstrate it on a piece of paper and remind them not to do any calculations. Experience shows that many people write down lap times instead of timestamps if not instructed properly.
The image below shows the foldings steps necessary to build a ship. Make sure that the last person, the one sitting next to the scribe, performs all the folding steps marked in red. Experience has shown that it is best to place the bottleneck at the end of the manufacturing line.
Rules
There are three simple rules:
- Everyone works as fast as possible!
Every ship we build can be sold and we want to earn as much money as possible. - We do not help each other!
In the real world we encourage you to help each other as much as possible. In this simulation however, we want to simulate and experience a specific system of work and compare two versions of it. If you help each other, we will not be able to do so. - Do not optimise the process!
We want to compare two versions of this system of work, the comparison will not be possible if we change the way we work.
Round 1, System 1: Unlimited WIP and Push
- Remind the participants to not skip folding steps.
- Start the timer and remember everyone to work as fast as possible. Make sure that the last person on the table, the scribe, notes down the arrival times.
- Pause the timer after 3 minutes and count the WIP, that is all the ships that lay on the table partly built.
- Explain the term “WIP”, see below.
- Introduce a red paper at the beginning of the process. This will be the last ship that we build in this round.
- Tell the participants to work in “First In, First Out” (FIFO) manner. The red ship should be the last ship we build.
- Start the time again and let everyone continue working until the last ship, the red one, is completed.
| Metric | Description | Question it answers |
|---|---|---|
| Work in Process | The number of items that are in the process at any given time. | — |
Round 2, System 2: Limited WIP and Pull
In this round we add a new rule:
- Everyone is allowed to have no more than one ship in front of her.
- After performing the fold, the person leaves the ship laying on the table in front of her and raises her arms in the air.
- Only after the next person in the process has pulled away the one ship laying in front of her, she is allowed to lower her arms and pull the next ship from her upstream colleague.
In contrast to the first round, we should never see ships piling up in front of someone.
- Remind the participants to not skip folding steps.
- Restart the timer and remember everyone to work as fast as possible. Make sure that the last person on the table, the scribe, notes down the arrival times on a new sheet.
- Pause the timer after 3 minutes and count the WIP, that is all the ships that lay on the table partly built.
- Introduce a red paper at the beginning of the process. This will be the last ship that we build in this round.
- Tell the participants to work in First In, First Out (FIFO) manner. The red ship should be the last ship we complete.
- Start the time again and let everyone continue working until the last ship, the red one, is completed.
Debriefing
Ask the participants the following questions:
- What was the difference between the two rounds?
- What did you observe?
- How did you feel?
Tell the participants, that you think the company went out of business because in the second round no one was working. Most people were holding their hands up in the most of the time.
Ask the participants what they think — in which system did the company earn more money? Also tell the participants, that in round 2 you observed many people holding their hands up in the air and thus not working. And in round 1 everyone was working all the time.
Analyse and Discuss the Metrics
Immediately write the insights on flip chart for later reference.
| Minute | System 1: Unlimited WIP and Push # of ships |
System 2: Limited WIP and Pull # of ships |
|---|---|---|
| 0 | (ignore, loading system) | (ignore, loading system) |
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | (ignore, partial minute) | (ignore, partial minute) |
| Work in Process (WIP) at Minute 3 |
||
| Throughput (average # ships per minute) |
||
| Cycle Time of red ship |
Throughput
Introduce the term throughput and fill in the numbers in the table above. Calculate the average throughput of both systems.
| Metric | Description | Question it answers |
|---|---|---|
| Throughput | The number of items that are completed per unit of time. | How many? |
Ask the participants the following questions:
- Why is the throughput (almost) equal in both system 1 and system 2?
Answer: The bottleneck is limiting the system performance. - In system 2: What could we do with the slack time?
Answer: We could spend the time for improving the system or we could support the bottleneck. - In system 2: If non-specialists would support the bottleneck, what would happen?
Answer: Non-specialists would be much slower in doing the work in the bottleneck. However, it would still help improve the throughput.
Note that in a system 1, the people are too busy to even think about helping one another.
Highlight the observation: in system 2 the team was able to deliver the same amount of ships per minute (throughput) despite many people holding their hand up in the air and not working on folding ships.
Insight
When we set limits, we have enough time for the work we never have time for.
Cycle Time
Introduce the term cycle time and calculate the cycle time of the red ships in both systems. Subtract 3 minutes, the start time of the red ship, from the last timestamp in the respective round.
| Metric | Description | Question it answers |
|---|---|---|
| Cycle Time or Lead Time | The time it takes for each of those items to get through the process. | How long? |
Ask the participants the following questions:
- In system 1: What would the cycle time of the red ship be, if we had introduced it
after 15 minutes instead of after only 3 minutes?
Answer: The cycle time would be longer. - Still in system 1: Why would the cycle time be longer?
Answer: Because the waiting queues would be longer. - Still in system 1: What would the cycle time of the red ship be if we introduced it
after 30 minutes?
Answer: We cannot really tell. It the depends on the size of the waiting queues and we cannot predict them either.
Note: The system is unstable. WIP is continually increasing and so is the cycle time. We cannot accurately predict cycle time. - Still in system 1: If someone from the sales department asked us: “How long does it
take us deliver a ship after it starts into production?”
Answer: We cannot tell.
Note: Despite having a simple product with a simple production process we cannot tell the lead times. It’s the system baby!
Note: What answer would we expect from a development team when we ask them how long it takes to implement a new feature? - In system 2: What would the cycle time of the red ship be, if we had introduced it
after 15 minutes instead of after only 3 minutes?
Answer: It would be the same. - Still in system 2: What would the cycle time of the red ship be if we introduced it
after 30 minutes?
Answer: It would still be the same. Cycle time remains constant.
Note: The system is stable. Cycle time is stable and that is why we can accurately predict it.
Insight
When we set limits, we become more predictable.
Thought Experiments
Priorities and their Pitfall
This is a thought experiment for system 1.
- We’re building the red ship for an important customer and we started building it
after 15 minutes into the simulation in system 1. After 40 minutes the customer
calls us complaining about having to wait extremely long for the ship to be built.
In an initial reaction and to appease the customer, our sales people tell him that
the ship is 80% done. What can we do to finish his ship as fast as possible?
Answer: We could introduce priorities and build the red ship with high priority. - What would happen to the cycle time of the red ship?
Answer: It would go down, but not below the cycle time of the red ship in system 2. - What happens to the cycle time of white ships?
Answer: It would go up. - What if we have other important customers?
Answer: We would add more ships with high priority. - What is the consequence for the cycle time of high priority ships?
Answer: It would go up, because we would start having queues of high priority ships. Eventually we would end up in the same situation of system 1 working almost exclusively on high priority ships and these “high priority” ships waiting in queues. - What could we do now?
Answer: We could introduce a higher priority and start the previous vicious cycle again.
Note: And at some point we probably would end up introducing “task forces” and prioritising them.
Insight
When everything is important, then nothing is.
Late Commitment
- In system 1: In the previous thought experiment, when the customer calls to complain
he tells us that the market conditions have changed. The red ship has no value
anymore, the market now demands blue ships. What would we do to fulfil the customer
need?
Answer: we would probably throw the red ship away and start building a blue one. Note the situation: we are in a system with a lot of unfinished work, and now where throwing away unfinished work! Because we start building the blue ship even later into the simulation, it would take forever for it to finish. - In system 2: Where in the pile would the red paper be when the customer calls us and
tells us, that the market conditions have changed?
Answer: the red paper would very probably be sill in the pile of paper to be processed. We would most probably not yet have started working on it. - Still in system 2: What would we do in order to fulfil the customer need?
Answer: we would replace the red paper with a blue paper without anyone in the production line noticing it.
Note that the benefit of “late commitment” is good for our company and the customer, because we can change requirements until very late when the order starts into production. Also note that this is the reason, why it is better to queue the work before the process than in the process (in the form of WIP, i.e. unfinished work).
Insight
The later we begin, the better for the customer (late commitment).
Note that when you order a new car you will be told two dates: the first date is the date when the ordered car starts into production (start date). The second date is the date when the car is shipped (start date + production cycle time). The customer can change the configuration (e.g. air conditioning, leather seats, etc.) at no additional cost up until the start date. Because the car manufacturer works in system 2, he can predict the shipping date with high accuracy.
Local Optimisation
- In system 1: What happens if we decided to become better by introducing agile ways
of working in the first team in this process, e.g. the first three people. The team
of three would process their steps extremely fast, like no other team in the world.
Would our overall throughput increase?
Answer: no, because the bottleneck remains.
Insight
We cannot complete more work, even if we work faster.
- Still in system 1: What would happen to the overall cycle time?
Answer: Because the agile team works faster, the WIP would increase faster. The unstable work system would become more unstable. Prediction of cycle times would get even harder. The local optimisations would make the whole system 1 even worse!
Insight
Local optimisation brings global sub-optimisation.
Carrots and Sticks
- In system 1: What would happen if we offered bonuses at individual or team level
to those working fastest?
Answer: we would most probably see many local optimisations. - How do we see bottlenecks in knowledge work?
Answer: we don’t, we have to make knowledge work visible! E.g. using Kanban boards.
Little’s Law
\[\overline{\text{Cycle Time}} = \dfrac{\overline{\text{Work in Process}}}{\overline{\text{Throughput}}}\]Put this to a test: validate the equation using the collected metrics. For round 1 and 2 divide the average “Work in Process” by the average “Throughput” and compare the result to the measured “Cycle Time”. The numbers should be roughly equal.
The corollary of Little’s law is that one can have all of the above benefits by just limiting WIP. As one can see in this simulation, the throughput will remain constant, that means that the work system introducing WIP will deliver just as much as before and the lead times will improve — at no additional cost: with the same way of working, the same people and the same resources.
Compare this to the rate limiting traffic light in front of the Gotthard Road Tunnel.
- How many thousands – over even millions – would a company need to implement WIP limits?
Answer: None. All that is needed are a couple of meetings to agree on implementing WIP limits.
Insights and Takeways
- We cannot complete more work, even if we work faster.
- Whether working in a push system or in a WIP limited system, the bottleneck determines the throughput, because the work is deadlocked latest at this point in the system. It doesn’t matter how much work we dump into the system or how fast the previous activities are finished: at the end of the day the amount of work completed is the same.
- We have enough time for the work we never have time for.
- Slack offers an opportunity, with the same amount of output, to identify and evaluate the weak points in a system, as well as working on quality and finding ways for improvement. In a non-limited system, these opportunities do not exist due to chronic overload.
- When we set limits, we become more predictable.
- The cause of incorrect estimations is the amount of work in the system is constantly changing. A reliable prediction method, regardless which one, can only function on the basis of a stable system.
- One of the greatest advantages of WIP limits for both the worker and the customer is predictability. On-time delivery is only possible when the amount of work which gets started is limited, which results in a stable system.
- When everything is important, then nothing is.
- The later we begin, the better for the customer.
- With a limited system, we strive to keep the cycle time short and at the same time start the undertaking of a job as late as possible (Late Commitment). Thereby we reduce the risk that job changes requested at a later time would make the work already performed useless.
- Local optimisation brings global sub-optimisation.
- Local optimisation, in most cases, results in a decrease of performance over the entire system. To improve the performance of a system, the focus needs to be on she interactions between the individual parts.
Sources
This is a ship building simulation as described in the book Practical Kanban by Klaus Leopold.
Comments