Learning with simulations

Experience-based learning with simulations means not explaining agile concepts, but making them physically tangible. In the Okaloa Flow Lab, teams move cards around a board game, measure key figures and change parameters such as work-in-progress limits in a targeted manner. What was previously not understood as a slide thus becomes anchored as intuition, especially for managers with no insight into agile working methods.

Key Takeaways

• Simulation-based learning anchors knowledge much better than slide presentations because it directly addresses intuition instead of just the rational mind.
• Managers only really understand agile mechanisms such as the pull principle when they experience their effects for themselves in a safe simulation environment without jeopardizing a real project.
• The classic project simulation deliberately ends with a frustrating result: the board is full of half-finished and blocked work to make the extreme of classic project management visible.
• Teams that set a work-in-progress limit in the second simulation round work around 50 percent faster, even though neither the frequency of blockages nor the events that occur have changed.
• The retrospective after the first simulation round regularly shows a blame game: teams look for the causes in external factors instead of recognizing their own work behaviour as a lever.

Experience-based learning beats pure lectures

Teams understand agile principles better when they experience them on a simulated object instead of reading them on a slide. This is the core behind simulations such as the Okaloa Flow Lab, a board game environment developed by a Belgian team that allows work flow, quality and agile mechanisms to be played out directly.

Andreas Wübbeke uses this approach both in teaching and in companies. The difference to traditional knowledge transfer is tangible: Instead of explaining why a work-in-progress limit makes sense or why a T-Shaped profile has advantages in a team, the simulation shows these effects using a running example.

The idea comes from sports training. In soccer, a rule such as one-touch football gives the players higher passing speeds in a small space, which they can call on later in the game. In the same way, the simulation sets framework conditions within which the participants can move freely and try things out.

This works much better because it doesn’t address the rational part of the mind, but intuition. You can try it out for yourself in your own hands.

Andreas Wübbeke

How a flow simulation actually works

A round consists of five players per simulation board: four work in a team, one takes over the project management at the beginning. The participants move work items, i.e. cards, around the board and record figures and statistics in each round.

Johanna Maduch describes the introduction as deliberately classic. You start with a simulation in classic project management and only then work your way up to the agile variant. The recorded key figures can be compared at the end, and it is precisely this comparison that makes discussions that would otherwise theoretically go round in circles superfluous.

Andreas has reversed the order of learning. First comes the practical simulation, then a retrospective of the experience and the statistics, and only then the theory behind it. The key question each time is: What has just happened here, and why?

The team then changes a parameter that they can influence themselves, such as a work-in-progress limit. The events during the simulation and the randomness remain the same. This shows whether the result is better or worse, without confusing cause and effect.

In total, around half a day is enough for a classic and an agile simulation, including working out the mechanisms of action in between.

The simulation intentionally reduces reality

A simulation deliberately excludes things, and this is not a shortcoming, but the purpose. Effects that are covered by other factors in real project work can only be made visible when reality is reduced.

A typical introduction is the classic project management simulation, which deliberately ends in a frustrating situation: The board is full, everything is half done, a lot of work is blocked. The blame game almost always follows in the first retrospective. The participants say that too much work comes in, the blockers occur too often, the probabilities are too high.

This is exactly where the learning point lies. The participants initially overlook the fact that they could change their own way of working in order to significantly improve the team’s performance. In the second round, they then work around 50 percent faster, although neither the probability of blockages nor the number of events decreases. More comes out, the board is emptier and the team feels better.

When testers or experienced practitioners come to the table, they like to tear up every rule and every piece of paper. Then you need an experienced game leader who exudes seniority and keeps things under control. A good response to such objections is to ask the transfer question: How can the effect shown be brought into your own reality?

Versions that grow with the level of knowledge

The simulation exists in several versions that increase in line with learning progress. You start classically, then playtest more agilely, and individual changes remain permanent. At the beginning, the project manager is included as a role, but is later replaced by other roles or almost completely eliminated.

Two new building blocks have emerged from this kit, which emphasize different levers.

Continuous improvement is not about real errors that have to be discovered, but about statistically added errors. The participants have to weigh up the options: When do I test, how much do I test, and is it worth skipping tests to have more done at the end?

The variants can be combined. You can try out what happens if a lot of testing is done early on, or skip testing altogether in the simulation and look at the result. A skills simulation contrasts two extremes: maximum learning in a team on the one hand, maximum expertise on the other.

Values become tangible instead of just asserted

Nobody understands agile values such as a T-Shaped profile or a WIP limit because they are written on a slide. They are often carried as unexamined convictions: I want a WIP limit, I want a T-shape because that is agile.

The simulation turns this assertion into an experience. You can go from one extreme to the other and find out the concrete effects of a decision. Instead of speculating ten times about the right limit, one team plays above it, one below it, one without it at all, and everyone compares the statistics.

This mode allows for mistakes without risk. The environment is safe, no specific project is at stake. Even people who stick to fixed ideas in the real world are willing to try things out in this protected environment.

Why the method works for management

Simulations work particularly well with managers and top managers because there is often a disconnect between them and the agile teams. Managers show up for the review, take a look at something and then leave again. They are not part of the cycle: no planning, no retrospective, none of the mechanisms that support agile work.

This leads to misunderstandings. A classic example is the pull principle, where teams pull their own work. From a classic perspective, this sounds like a loss of control: if the teams are allowed to pull, as I push. If you playtest how much this pull improves the flow of work, you gain an understanding of the mechanism.

Management needs more support for this learning step than a group of students. Experienced managers are filled with practical knowledge and ask very fundamental questions. A trainer must have equally fundamental and clear answers to these questions.

Hands-on learning anchors knowledge more deeply

Material sticks better when you experience it in practice. In teaching, this observation is reflected in the grades of the students, who retain the mechanisms much better after a simulation than after simply learning a set of slides.

This is based on the principle of constraint-led learning, the positive effect of which has also been scientifically described. This approach is the origin of sports methods in which the training environment is designed in such a way that certain automatisms take effect over time.

A lecture initially only affects cognition. However, people run on autopilot for a large part of the day because the brain is expensive to maintain and prefers automatisms. Intuition can be addressed directly via the haptic, via touch, and cognition follows intuition. This creates a shortcut to learning that a lecture does not offer.

Team dynamics are the reason why the simulation should be played in presence. Sitting together at the board does something to people, and teams act with very different ambitions. How a team is feeling at the moment can hardly be gauged online in the same way as at the table together.