Through simulating a conventional work environment that reflects a mechanistic mindset characterised by a focus on resource efficiency, command and control and specialist workers, participants experience which roadblocks need to be overcome. As the team is taking its first baby steps into agile, they will experiment (in 2 or 3 rounds) with policies and practices (e.g. pull of work, cadences, limiting WIP) that enable collaboration, get the team into flow, and allow an agile mindset to emerge. Weaved into the simulations they will discover the fundamental difference between resource efficiency and flow efficiency.

What happens when you have specialist workers involved when delivering value to the customer? When you rely on specialist workers, you automatically create dependencies, i.e. key man dependencies, and dependencies between work items. The purpose of this simulation is to experience bottlenecks as a result of assigning work to the specialist. This simulation is relevant when you want to introduce the concept of staff liquidity. It can be used in environments where methods like e.g. Kanban and Scrum are applied.

In most organisations work is handed over from one specialist role to another, following a certain sequence, also known as a workflow. Workflow cannot be ignored as it is an important part of how work is organised in most organisations, even including agile organisations. Participants will experience workflow (loopbacks) and dependencies. With this simulation we are simulating a typical workflow as defined in e.g. Jira or any other tracking system, whereby work goes from one person to another, and back in case of loopbacks. The Workflow simulation shows what Kanban really is about – differentiating between proto-kanban and Kanban as well as teaching how to deal with back-flow.

This simulation allows an experience of flow and collaboration across multiple teams that need to work together to deliver value. Individual teams can be competence, component or technology teams each with their own area of specialisation. They could even be feature teams (full-stack teams) to the extent that each feature team focusses on its own feature set (e.g. check-out, …). The simulation demonstrates multi-tiered flow and collaboration across 2 different levels: 1) the request level and 2) work item level. One of the elements of this simulation is to experience bottlenecks in a multi-team context and the effects of this on delivering value. This simulation is relevant in combination with methods that address scaling.

Many organisations struggle with the phenomena: performance versus cost versus quality and time pressure. Trying to validate all assumptions upfront will in the end lead to bad quality because at a certain point you will be faced with pressure to deliver and then suddenly the item is rushed through the system. Not agreeing on requirements might lead to high risk of failure further in the value stream. But how to find turning point, moment that you know you are over assessing. The urge to get everything cleared out makes that in the end we feel time pressure and we deliver bad quality. In this simulation participants experience the end-to-end flow along a value creation process, from customer request to delivery to the customer. It addresses dealing with assumptions of the upstream, hand-offs and loopbacks.