+43-676-330-4803ContactImprint en de


New Version of TWiG in 6 Languages

TWiG 1.5 is done. The biggest highlight right away: The simulation is now available in 6 languages (English, French, German, Italian, Polish and Russian) and the seventh language (Spanish) is Work in Progress. Many thanks to the TWiG Community for your support!

In addition to the languages there are a few smaller and bigger changes like for example we change the WIP limit in the simulation and there’s a bit happening concerning metrics. I would recommend every TWiG user to switch to the new version.

I would like to thank all the people who are willing to contribute to TWiG and post their experiences and suggestions for improvement in our Slack Channel. THANK YOU! A special thank you also goes to the following people:

So then, download TWiG 1.5, print it out, cut it to size and get started…

How to manage dysfunctionality with agile methods

“Hooray, we have a board and we are doing standups. We are agile!”

That would be nice.

Many people still think of a board with colourful stickies when they think of agility. And it’s perfectly clear: Visualizing work and workflows on a board is basically a great thing and an important prerequisite for improvement. However, many “Hooray Agilists” still don’t understand that more brain fat is necessary in order to fully utilize the real benefits of agility. This is what happens in many companies: Every team has its own board and uses it to push and pull its tasks back and forth. In some cases even the management team has its own board and manages its tasks on it. If the management also has a board, some already interpret this as enterprise agility or business agility.

Two things are wrong here:

  1. Waterfall 3.0: It’s great when many teams visualize their work. That’s a start. But you can also be totally unagile with lots of boards and visualization if nothing else is created but a waterfall 3.0. The analysts have their Kanban board, the developers have their sprintboard, the testers have their Kanban board. As before, tasks are simply passed on. The dependencies between the individual teams, let alone between operational and strategic levels, are completely ignored and not actively managed. In the best case scenario, a team always optimizes itself, but the company as a system of connected individual parts remains unaffected. In other words: It remains as little agile as before.
  2. Administration of the existing: Management boards in particular are usually just a prettier to-do list. The tasks are processed well, but there is no change in the way HOW these tasks are processed. And it is also not considered whether the tasks are meaningful at all. Sometimes it gets even worse: The visualization makes constant re-prioritizing and working with high work in process much easier, and that can drive a company into agile madness.


The fact that there are certain artifacts like boards or standups does not make an organization agile. Boards of all kinds – Kanban, Scrum or anything else – can be used to perfectily manage existing dysfunctions.

This happens when the focus is not on “business agility” and instead the methods are worshiped as “agile”. Everything then revolves around how many columns and swimlanes a board may have and whether a stand-up should not last a second longer than 15 minutes. You can make great but completely useless retros if you don’t follow the findings or if you never check whether actions were successful.

Where means and ends are confused, agile transformation intentions usually fall into the trap.

Busy People vs. Finished Work

You get what you’re optimizing for. Deming has already said, “Every system is perfectly designed to get the results it gets.” If we build a work system in which it is important that everyone is working at 100% capacity, then we will get exactly such a system. And now the important point: This does NOT mean that work is finished quickly!

If we want work systems in which work is finished quickly, we must – surprise, surprise – finish work. Therefore, the work in the system must be limited so that the focus shifts from starting to finishing. And now comes the disappointment for full utilization fetishists: That is not possible with 100% utilization!

When we make plans with 100% utilization we have to be aware that work is getting done slowly and that we will not meet deadlines.


Inflow vs. Outflow

Whenever agile methods are introduced into organizations, discussions about “prioritization meetings” revolve quite quickly. Replenishment, planning, grooming, blooming, zooming and whatever they’re all called. It must be made sure as soon as possible how new work gets into the system.

My experience says that the subject of “replenishment” can be initially neglected. I’ve never seen (and I use the words “never” and “always” very rarely) a system that wasn’t clogged at the beginning. It makes absolutely no sense to discuss replenishment until the clogged system is cleaned.

We need to shift the focus of prioritization: Priority must be given to which work is to be completed and not which is to be started.