Flow simulation — your team will feel why their work takes so long before we explain it
You can show a team a diagram of their workflow. They'll nod and go back to working the same way. Or you can run them through a simulation where they experience the bottleneck, the handoff delay, and the cost of multitasking in real time. The second approach changes behaviour. The first rarely does.
What is a flow simulation?
A flow simulation is a hands-on workshop where participants work through a simplified version of their own process. Tasks flow through the team. Bottlenecks appear. Work piles up in unexpected places. Handoffs get dropped.
The simulation runs in rounds. Between rounds, the team can change how they work. They see the results immediately — in the numbers, and in how the work felt. By the end, they understand their system from the inside, not just from a presentation.
The simulation draws on Lean and Kanban principles: work in progress limits, flow efficiency, collaboration patterns, and the cost of context switching.
When a flow simulation is not the right tool
- When the bottleneck is already identified and the solution is already agreed — the simulation is for discovery, not confirmation
- When the team's work is highly unpredictable and not repeatable — flow simulations work best when there is a recognisable process to simulate
- When leadership is not present — insights from the simulation often require decisions that only leadership can make
How we run flow simulations
- We talk to the team before the session to understand their actual process and where they feel the friction
- We design a simulation that reflects their real work — not a generic exercise
- We run multiple rounds with structured debriefs between each
- We help the team translate what they experienced into specific changes they can make to their workflow
- We document the before/after: how the numbers changed between rounds and why
Flow simulation in practice
Software team: why sprint goals kept slipping
A software development team consistently missed sprint goals despite working hard. A flow simulation showed the real cause: every team member was working on four items at once, none of them finished. After one round of the simulation with a strict work-in-progress limit, throughput doubled. They changed how they planned the next sprint that afternoon.
Operations team: finding the real bottleneck
A team believed their slow delivery was caused by an approval step at the end of their process. The simulation revealed the real bottleneck was three steps earlier. Removing the approval step would have changed nothing. Changing the handoff at step three reduced delivery time by 40%.
Want to know why your team's work takes so long?
Tell us about your process. We'll design a simulation around it.