Throughput

Objective

The primary objective of the Throughput game is to move as many work items into the Finished Goods bin as possible while limiting the Work In Progress (WIP). Additionally, the game aims to help players learn how throughput works and why it’s beneficial.

Background

In the Throughput game:

• Work units are of equal effort and equal worth.
• The game assumes infinite consumption (output) of finished goods.
• A workstation represents a step from raw material to a finished good. This can be any type of process, whether mental or industrial.
• A workstation is the "place" where the server serves the queue and is sometimes referred to as a sub-queue. The entire process of the game represents the outer queue, and the sub-queues are served to move items or people.

Rules

Setup

1. Place seven stations in a row, with unmarked stations at each end. The color order of the other stations is unimportant.
2. Place cards in their appropriate slots.
3. For each colored station, roll a die to determine its throughput, which will be fixed for the duration of the game unless a "Booster" instructs otherwise.
4. The game uses a Score Card to track progress, including Week, Day, WIP, and Finished Goods.

Server Instructions

• Automated servers can only serve stations of the same color shown on their automation card.
• Human servers can only serve their station or stations for which they have acquired skills, denoted by color stickers.
• The team can move servers once per day, according to the server's skills.
• Stations with no servers cannot move work items; do not place a work card in the station’s server(s) work spot.
• Each server serving a station can move a count of work items no greater than the defined capacity of that station.
  • Servers are allowed to move fewer work items than the defined capacity.
  • If a station's capacity is two and there are two servers, it is possible to move up to four work items if both servers have successful work cards.

Keeper Roles

• The Timekeeper's objective is to keep play going to ensure the team completes all their weeks within the allotted time.
• The Scorekeeper keeps track of days, weeks, WIP, and finished goods.
• The Rule Keeper is responsible for ensuring teams adhere to the rules and instructions on the board and cards.

Weekly Planning (At the start of each week)

• The team draws one skill card.
• The team decides where to apply the acquired skill (following instructions on skills and training).
• A forecast of finished goods is made.

Daily Standup (At the start of each day)

• The team decides server moves applicable for the day.

Execution

• The team starts each day by finding the team’s mood by rolling a die.
• The team can then move work items up to or equal to the team mood from the week’s backlog to the first color station.
• Each station’s server(s) turn over their work card and follow its instructions.
• All moves for one station must be finished before moving to the next.
• This process is repeated for the remaining colored stations.

Week 1 Special Rules

• Week 1 must be played in "vanilla mode".
• During Week 1, no BIT cards, Skill cards, or server moves are possible.
• Instructions to pull BIT cards should be ignored.

Learning & Retrospective (At the end of each week)

• Tally the WIP and Finished goods.
• Calculate the score for the week.
• Move finished goods back into raw materials.
• Discard any BIT cards labeled “Use by the end of week”.
• Discuss what happened during the week.
• Decide if the team needs to adjust their daily strategy for the next week.

Strategy

A core part of the Throughput game involves learning how throughput works and understanding its benefits. Teams should continuously strive to maximize the movement of work items into Finished Goods while keeping Work In Progress (WIP) low. The game simulates concepts from the Theory of Constraints (TOC) and Queueing Theory, offering insights into process improvement.

Leveraging the Theory of Constraints (TOC)

The Throughput game serves as a simulation for the Theory of Constraints (TOC), a management philosophy developed by Dr. Eliyahu Goldratt, which focuses on increasing flow and Throughput by identifying and leveraging the system constraint. The core idea of TOC is "FOCUS!".

Key strategic elements from TOC to apply in the game:

• Identify the Constraint (The Drum): Just as a chain is only as strong as its weakest link, your process throughput is only as fast as your slowest production step. The "drum" is the constraint – the resource or station limiting your output. In the game, this will be the station with the lowest throughput capacity, as it sets the pace for the entire operation. Focusing improvement efforts on non-constraints will not improve overall output. The first step in the "Five Focusing Steps" (POOGI) is to identify the system's constraint.

• Exploit the Constraint: Once the constraint is identified, the next step is to maximize its utilization and productivity. In the game, this means ensuring the server(s) at your bottleneck station are always working and moving items up to their defined capacity. Instead of immediately adding more capacity, first learn to use the resources you already have more efficiently. Consider strategically applying skills to servers at the constraint or prioritizing work cards for that station.

• Subordinate Everything Else (The Rope): Any non-constraint has more capacity than the constraint. It is crucial to avoid producing more than the constraint can handle. This will prevent bloated Work In Progress (WIP) inventory, elongated lead times, and associated issues. The "rope" is how you control the release of new work. In the game, this translates to carefully managing the release of work items from the backlog (using the "team's mood" roll) to the first station, ensuring it does not exceed the pace at which the constraint can consume them. This synchronized approach preserves a harmonious and effective flow inside the system.

• Buffer Management: Buffers are strategically positioned reserves of inventory or time that serve to alleviate interruptions from process fluctuations. In the game, the work items waiting in front of each station act as buffers. The most critical buffer to maintain is in front of the constraint. This buffer of work ensures the constraint never runs out of items to process, thus protecting its utilization. Effective buffer management helps absorb variability and maintain a consistent workflow. While the game has multiple workstation "sub-queues", the principle is to use buffers to protect the constraint from starvation and to protect due dates.

• Elevate the Constraint: If exploiting the constraint isn't enough to meet objectives, the next step is to expand its capacity. In the game, this can be achieved by:

  • Applying acquired skill cards to servers at the constraint to increase their capacity or flexibility.
  • Using "Boosters" (if applicable) to increase a station's throughput.
  • Cross-training servers to allow them to assist at the constraint. This is only done after exploitation and subordination are fully complete.

• Continuous Improvement (POOGI): The "Five Focusing Steps" are part of the "Process of On-Going Improvement" (POOGI). The weekly retrospective phase is crucial for this. As you identify and elevate one constraint, another may become the new bottleneck. Continuously monitor your WIP and Finished Goods and discuss what happened to adjust your daily strategy for the next week. This ensures ongoing adaptation to evolving system dynamics.

Insights from Queueing Theory

Queueing Theory analyzes systems involving waiting lines or queues. In the Throughput game, each station acts as a service point with a queue of work items.

• Impact of Variability: Even when average capacity exceeds demand, waiting lines (WIP) can form due to natural variation in the system, such as the "lumpiness" of arrival rates or varying server success. The game's die rolls for "mood" and work cards introduce this variability, which buffers help absorb.
• Focus on the Bottleneck: Queueing theory reinforces the TOC principle that adding capacity or optimizing non-bottleneck processes will not improve overall throughput if the primary bottleneck remains unaddressed. The only way to increase overall output is by increasing the output of the constraint.
• Limiting WIP: Too much WIP is a common issue in many processes. The game's objective to limit WIP directly aligns with this principle, as high WIP can lead to longer cycle times and hide problems.

By applying these strategic principles derived from the Theory of Constraints and insights from Queueing Theory, teams can effectively manage their workflow in the Throughput game to maximize output and minimize costly delays.

Visuals

Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.

Run the Game

To start the ThroughputApplication, follow these steps:

1. Command Line Arguments:

   • The application accepts the following optional arguments:
     • sides: Specifies the number of sides for the die.
     • stations: Specifies the number of workstations.
     • periods: Specifies the number of periods.
     • turns: Specifies the number of turns.
   • Example command:

     java -jar throughputfxproject.jar --sides 6 --stations 5 --periods 5 --turns 5

2. System Variables:

   • The application loads system properties from a config.properties file located in the same directory as the application.
   • These properties are added to System.getProperties() and can be used throughout the application.

3. Execution:

   • The main method initializes the application by parsing the command-line arguments, loading the configuration file, and setting up the application state.
   • Finally, it launches the JavaFX application using launch().

Ensure the config.properties file is present and accessible, and provide valid arguments to customize the application's behavior.

Usage

Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.

Support

For problems or enhancement requests, please open an issue in the GitLab project ([issue tracker link placeholder]).

For user requests, you can email louis.burroughs@michelin.com.

Roadmap

The next iteration of this project will be to move it to a web version. The game should be facilitated for the best effect, a web version would require remote or AI facilitation.

Contributing

We welcome contributions, especially in the creation of new card decks for different types of workflows and improvements to documentation. Please see the CONTRIBUTING.md file for detailed guidelines and requirements for contributing to this project.

For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.

You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.

Authors and acknowledgment

Thanks to all the contributors who help me test the game in all of its iterations and gave great feedback on how to improve it. Special thanks to Patricia Gilstrap for many hours of playtesting and feedback, and to Carl,
Carolyn and Mary Hamilton for their contributions to the game design and endless support.

License

This project is licensed under the Apache License, Version 2.0. See the LICENSE file for details.

Project status

This project is currently in the Alpha stage. It is functional but may still have bugs and incomplete features. We are actively working on improvements and welcome contributions from the community. I do not have plans to improve the javafx version of the game, but I will continue to maintain it. The next iteration will be a web version of the game. If you are interested in contributing to the web version, please reach out to (mailto:louis.burroughs@michelin.com).