A Simulation of TameFlow®

Introduction

Something that I have been wanting to do for quite some time is to run a game called the TameFlow Simulation, based on an exercise found in the TameFlow book I reviewed in a previous article.

Running games or exercises onsite has been out of question for some time due to pandemic reasons. But rather than resigning to this, I figured I could try to build a computer simulation instead and see if the results are similar to the ones described in the book.

So I'm putting to use my skills in building SimEvents models to recreate the TameFlow Simulation. The article that follows is based on four full-blown Discrete-Event Simulation models, that are built around the four rounds of the game.

These exercises will help to illustrate the negative impact of executing multiple projects simultaneously in highly competitive environments, where individual performance is praised as opposed to overall system's performance. The last simulation is a powerful exercise that shows that a better way of managing multiple projects is possible.

Without further ado, let's see what these simulations are about.

Summary of the Simulation

The TameFlow Simulation is a game that is played by 8 participants. The roles among the players are as follows:

• 3 Product Owners
• 3 Upstream Teams (consisting of one player per team)
• 1 Downstream Team (one player)
• 1 Customer

The game simulates the execution of multiple projects by multiple teams.

A project is composed of exactly 10 coins, using euro cents: 1c, 2c, 5c, 10c, 20c and 50c. There are 10 projects in total.

At the beginning of the game Product Owners are asked to prioritize projects by value. Total project value is calculating by adding the value of each coin in the project. Then Product Owners agree on what projects will be assigned to each one of them, i.e.

• Project 1. Total Value: 122c. Assigned to Product Owner 1
• Project 2. Total Value: 99c. Assigned to Product Owner 2
• etc.

The game itself will consists of Product Owners releasing projects into the work stream by passing coins to the relevant players.

• Player A handles 1c and 2c coins
• Player B handles 5c and 10c coins
• Player C handles 20c and 50c coins

Each player will in turn flip each coin they receive before handing it over to Player D. Once Player D receives a coin he/she will flip or pass a coin depending on its value:

• 1c, 2c, 5c coins are passed
• 10c, 20c, 50c coins are flipped

After this action is completed, Player D also has to gather together all the coins belonging to the same project. Once a project is "completed" this way, the Product Owner for that project is responsible for handing over the 10 coins to the customer for final inspection.

Simulation Explained

Having introduced the mechanics of the game, let's turn to how it is depicted in the actual discrete-event simulation.

You may have noticed in the image above some bright yellow stars. These represent each project. At the beginning of the simulation you will see all stars piled up on the Product Owners table. As projects gets released into the workstream, stars are placed in front of the upstream teams (A, B and C). Once a project gets completed, the star shows up again and moves down to the customer table. This represents the PO handing over a project to the customer.

In addition to this, there are some color conventions as well. Coins and products belonging to a certain product owner have a different border color. These are the following:

• Blue border: PO1
• Red border: PO2
• Black border: PO3

One last bit of graphic detail added to the simulation is the flipping animation of coins. This is simply done by turning the coin color temporarily to black. That way we can visually see when coins are flipping.

I will obviate the most intricate aspects of the implementation of this simulation. However, I consider useful to add some brief remarks in that regard.

Firstly, the flipping and passing a coin by a player have different service times. Flipping a coin will take 2 simulation cycles whereas passing a coin will take only 1.

Secondly, at the beginning of each simulation you'll notice that nothing really happens. Behind the scenes the Simulink engine is loading the data for projects from a spreadsheet. Once that background process finishes the coins start to flow thru the system.

So let's take a look now at the first round of the simulation, a warmup.

Simulation - Round 1

The first round of the simulation is a warmup exercise for player to familiarize themselves with the mechanics of the game. As such, it only involves the first product owner releasing a single project into the system. A question that is posed to the players is: how long do you think it'll take to deliver this project to the customer?

Naturally, this is a DES simulation and we don't have actual players. So the duration displayed is based on simulation steps. Let's see the execution...

Take a mental note of the project duration, it was 20 simulation steps.

Simulation - Round 2

The second round goes a step further by releasing another project by the second product owner. So we will see two projects processed by the teams simultaneously. This will add a little bit messiness to the process.

Two questions to ask the participants at this stage are:

• What duration will each project have?
• Where will the constraint be?

Notice that by constraint we mean the team that has the biggest amount of coins to process, slowing down other teams as a consequence.

After simulation completes, we notice that Project 1 took 20 simulation steps whereas Project 2 was 24 steps. Also, it seemed like Team D was the busiest, making it a candidate to be named the constraint.

Simulation - Round 3

This round is when the pandemonium is unleashed. The rules of the game specify that projects should prioritized by value, but how and when to release a project is not mentioned.

Remember that one of the goals of the simulation is to visualize the impact of (mis)handling multiple projects spread across shared and scant resources in a highly competitive environment.

As in the real world, the simulation below is going to be chaotic. That is by design. A couple of questions to ponder are:

• What duration will project 5 have?
• Where will the constraint be?

Now we can hopefully appreciate the degradation of performance when the 10 projects are released. Project 5 took about 68 simulation steps to complete, that is almost 3 times longer than Project 1 in the first round.

We can also see that the constraint is not Player D anymore; as the coins piled up on Player A quickly, making the system throughput of the players dependent on Player A. How could that possibly be?

A key aspect of the simulation is to highlight two types of constraints that are taught in the TameFlow approach; that is the constraint in the work process and the constraint in the work flow. Explaining this concept fully is beyond the scope of this article, I will however give a simple definition for both and their relevance to the simulation result.

The constraint in the work process is determined by the flow time (some people call this cycle time as well) of the different stages in a process. Simply put, the constraint in the work process is the one that experience the longest flow time in process.

The constraint in the work flow is the stage that has the longest queue of pending work in front of it. Under normal conditions, the reason a particular stage has a bigger amount of work to do is determined by the shape of the demand. Up until now I haven't revealed the composition of the 10 projects in this simulation; see below the datasheet used in the simulation:

The coin distribution (or shape of demand) gives us a hint on what team is going to be overloaded with work. We can expect that as more coins are piled up on Player A's table, keeping track of what coins belong to what projects is going to get harder. This in turn will slow down Player A, and even though it is Player D the one that has to process the entire set of 100 coins, the performance of the entire system is impacted by the designed constraint.

The above paragraphs don't make justice to the full reasoning and analysis made by Steve Tendon in his Book Of TameFlow. If you find these ideas interesting I would recommend reading the book to fully grasp these concepts.

Bonus - Cost of Delay Calculation

One last thing I would like mention here, and no less important, is the economic impact of running a chaotic system like this. My own addition to this simulation was to perform a cost of delay calculation on each project, so we can compare with the later run. Once again, explaining cost of delay is beyond the scope of the article, so I will just show why and how I'm using it.

Taking the first round as a baseline, I established that each project had a cost of delay equivalent to its total value (remember, this was the addition of all coins in a project) per 20 simulation steps.

Why is this important? As a result of projects getting mixed up in the workflow, these were not delivered in priority order to the customer. That means that projects with lower value were delivered ahead of higher value ones. Cost of delay helps to quantify this.

See below a chart that shows the total cost of delay evolution in this round 3. It will be used for a comparison later.

Simulation - Round 4

Having witnessed the chaos and suboptimal results of round 3, the fourth simulation run introduces a scheduling mechanism to prevent such situations from happening. This is the so-called Drum-Buffer-Rope method.

In order to protect and maximize the performance of Player A (our constraint in this game) new rules are applied to the final simulation run.

A buffer is created in front of the current constraint, Player A. Such buffer will contain two projects ready to be pulled only when Player A has finished processing all coins from a given project. Projects are also placed in strict priority order in the buffer, and because only projects are released when Player A is ready, this will ensure that projects get executed in the desired order.

So, with this set up we ask again, what duration will Project 5 have?

Well, this time the results speak for themselves. Notice how Project 5 only took 18 simulation steps.

Furthermore, as it was originally predicted projects would be executed in strict priority order. This meant that highest value projects were delivered first. If we take a look at this simple cost of delay quantification chart, we can see how in round 4 it was somewhere around 1450. That's lower than the value of 1700 that we saw for round 3.

Conclusion

This article has shown an Discrete-Event Simulation implementation of the TameFlow Simulation. The main objective was to go through the game itself and ignore any of the underlying implementation details. I will just add as a note that all of this has been implemented in MATLAB Simulink®.

The TameFlow Simulation was conceived as a simple game that would illustrate some of the ideas of the TameFlow approach. In it, players get to experience the harmful effects of pushing work into an overworked system and competition. The game also shows that there is a different way of managing work, that leads to higher performance and cooperation.

What the results show is that in absence of mechanisms to ensure that projects are correctly prioritized and their execution follows a strict priority order the performance of the organization is subpar.

A scheduling method, like the proposed DBR, can go a long way in improving the predictability of project delivery and value throughput. Mind you, for any of this to be valid we need to be in the position of correctly sizing and prioritizing projects. As of today, this is extremely hard to do in knowledge work. Some methods do exist, but their empirical validity remains to be proven.

If anything, the simulation can help challenge existing mental models by showing the waste and chaos of running a system that is highly competitive, where high resource utilization is prized and local optimization rewarded.

Finally, for the sake of brevity I tried to explain things in the simplest way possible, without getting entangled in theoretical minutiae. What is depicted in a single article here, it is reflected in several chapters of Steve Tendon's Book of TameFlow. If this article has sparkled the reader interest in these ideas I encourage turning to the aforementioned book for a more complete and rounded treatment of this subject. Link below.

References

Tendon, Steve. The Book Of Tameflow