+43-676-330-4803ContactImprint en de

Posts Taged Highlight

One Year Lean Business Agility Video Blog

It’s been a year since the first video was published in my Video Blog Lean Business Agility. What is more obvious than to draw an annual balance.

Florida, Cape Town, Johannesburg, Vienna, Munich, Paris, London, Dusseldorf etc. I was in really many cool places and met even more interesting people. I’ve created a Google map where I’ve entered the episodes’ places including the link to the episode.


I had to realize that creating objective charts is not that easy. That’s why I’ve divided the charts into two groups:

  • Most hits: The videos with the most accesses in absolute terms since the release of the video. The longer a video is online, the more absolute hits it usually gets.
  • Weekly traffic: average traffic per week since the video was posted until today. Video traffic is usually highest after publication and decreases to an average over the first four to six weeks.
Top 7, most hits
  1. DE E003: Strategisches Portfoliomanagement bei Autoscout24
  2. DE E007: Flight Level 2 bei AutoScout24
  3. EN E004: Metrics and Dashboards
  4. DE E002: Enterprise Kanban Coach
  5. DE E012: Selbstorganisierte Unternehmen
  6. EN E020: The Spotify Model
  7. DE E011: Backlog Management bei TOP@SBB


Top 7, weekly traffic
  1. DE E023: Agilität mit 350+ Personen bei OTTO
  2. EN E020: The Spotify Model
  3. DE E003: Strategisches Portfoliomanagement bei Autoscout24
  4. DE E019: Business Agility @ Rewe Digital
  5. DE E007: Flight Level 2 bei AutoScout24
  6. EN E021: Why Change is Inevitable
  7. EN E022: Managing Change in the 21st Century


Top 4, English videos only, most hits
  1. EN E004: Metrics and Dashboards
  2. EN E020: The Spotify Model
  3. EN E006: System Stability
  4. EN E009: Actionable Agile Metrics


Top 4, Englische videos only, weekly traffic
  1. EN E020: The Spotify Model
  2. EN E021: Why Change is Inevitable
  3. EN E022: Managing Change in the 21st Century
  4. EN E004: Metrics and Dashboards


Top 4, German videos only, most hits
  1. DE E003: Strategisches Portfoliomanagement bei Autoscout24
  2. DE E007: Flight Level 2 bei AutoScout24
  3. DE E002: Enterprise Kanban Coach
  4. DE E012: Selbstorganisierte Unternehmen


Top 4, German videos only, weekly traffic
  1. DE E023: Agilität mit 350+ Personen bei OTTO
  2. DE E003: Strategisches Portfoliomanagement bei Autoscout24
  3. DE E019: Business Agility @ Rewe Digital
  4. DE E007: Flight Level 2 bei AutoScout24


And of course we continue! I was back in Florida and did three cool videos there which will be published in the next days and weeks. To stay up-to-date, subscribe to the Lean Business Agility YouTube Channel or subscribe to the Podcast on iTunes or Overcast or use the RSS Feed.

Featured image by JESHOOTS.COM on Unsplash.

TWiG – The WiP Game – is Out!

Done! TWiG version 1.3 has a state that humankind might probably use without much harm. The material is print-ready and I’d call the simulation stable. A simulation is, of course, never “done” and I have tons of ideas to incorporate but I think it’s definitely playable. What’s missing is good documentation about the setup. There are only two pictures and that’s it but if it’s true that a picture is worth a thousand words, we’re good 🙂

Why a new simulation?

Does the world really need a new simulation besides getKanban, FlowLab, Featureban, and others I don’t know? Yes, they are really great simulations and the world most likely does not need another one but I do! One simulation takes too long, another one is too complicated and another one is too general. Sorry, but that’s how difficult I am when it comes to fulfill my mission to find easy explanations for complex topics.

TWiG is a board game that shows a WiP limited pull system in action. It can be played in only 1.5 hours. I usually play it at the end of a Kanban class because it nicely summarizes what you’ve learned before.

I basically developed the simulation out of pure selfishness and I never wanted to make it available to the public. However, after I played TWiG the first time in a training, I immediately realized that “not publishing it” was wishful thinking. I continuously get requests, where one can buy the simulation. TWiG was only developed to be part of our workshops and trainings and we (LEANability) don’t want to move to the board game business. As such it was just logical to make TWiG freely available for the public. And that’s what happened: TWiG is licensed under a “Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License”.


You can download the simulation on the TWiG website (although website is a bold word for what you’ll see): www.LEANability.com/en/twig (Use www.LEANability.com/de/twig for the German version.)

Help and further development

We are opening up the LEANability Slack community as TWiG support channel. You can sign-up for the Slack group on www.LEANability.com/en/slack. Please add to the comment that you’re interested in TWiG. There are currently the following Slack channels:

  • #twig-help-en: General help about the simulation: how to setup, debriefing tips, etc. Language: English
  • #twig-help-de: The German help channel.
  • #twig-devleop: This channel is about further development of TWiG. Language is English.
  • There’s a Trello board where I started to collect some improvement ideas: http://bit.ly/twig-dev-trello The idea is that we’re discussing improvements in #twig-develop on Slack and we’ll track progress of realization on Trello.

That’s at least the initial idea – reality will show what’s really working. We’re not afraid to adapt 😉

Thank you

Many thanks to Katrin Dietze for continuous feedback to the simulation and for the help with the material.

Thank you Mike Freislich for the translation help. You did a really great job and this although you don’t speak a single word German. We might also thank Google translate 🙂

Thank you Joanne Perold and Mike Freislich for being the English TWiG guinea pigs.

Have fun using and and I’m looking forward to your comments and improvement suggestions!

Podcast: Stories Connecting Dots

Markus Andrezak und ich tauschen uns ja regelmäßig zu allen möglichen und unmöglichen Themen aus, meistens jedoch alleine. Manchmal aber auch öffentlich: Vorige Woche veröffentlichte ich ein Interview zum Thema “Priorisierung, Verzögerungskosten und Risikobewertung”, das ich mit Markus für mein Buch Kanban in der Praxis geführt habe. Markus hat mich aber auch schon mal öffentlich befragt und zwar in seinem sehr empfehlenswerten Podcast Stories Connecting Dots. Ich hatte die Ehre, Versuchskaninchen zu sein und war Gast in der ersten Episode. Wir sprachen über Kanban und das es im allgemeinen ganz schlau wäre, alle Methoden zu töten 🙂 Hier gibt’s den Podcast noch mal zum Nachhören.


Flight Levels: The Organizational Improvement Levels

As soon as you get something written down, you look at it, think about it and continue to develop it. This was exactly the case with the Flight Levels model. Just as they were being released in my book “Kanban in der Praxis”, and despite already having been discussed many, many times before when consulting customers, at trainings and at presentations, my point of view changed—thanks to feedback from readers, audience members and training participants.

The Flight Level model poses one main question: Which organization levels offer which leverage for improvement? Along this line, I reorganized the Flight Levels because whether or not the input occurs in a controlled or disorderly fashion (until now, the distinguishing characteristic between Flight Level 1 and 2) is a question of detail that distracts from the essentials of the model. In most companies, there are mechanisms in place for deciding what should be done next. Whether these mechanisms are efficient or not is exactly the topic of improvement, but is not important for the Flight Level model. As a result, a new structuring of the flight levels emerged and looks like this:

>  Flight Level 1 – Operational Level

>  Flight Level 2 – Coordination

>  Flight Level 3 – Strategic Portfolio Management

Although the flight levels came about through working with Kanban, it is still a general-purpose model for organizational development. When working with my customers, for example, often the focus is to implement measures at Flight Level 2 and 3 to improve coordination and strategic direction, while the team level, or operational level, works with Scrum. As such, it isn’t important which method is used at the individual levels, but rather how the communication and coordination between the levels will be organized. If you can make improvements here, the entire creation of value will begin to be optimized—and that is ultimately our goal.

I did not randomly choose the label “flight levels”. Flight level relates to flight altitude and so it should also be understood in this context: The higher you fly, you have more of an overview with fewer details. The lower you fly, you can see more details but no longer the entire landscape.

The Flight Level model is an instrument of communication that reveals the effect of specific improvement steps at different levels, and for finding the most useful starting point within the organization to begin with improvements.

Flight Level 1: Operational Level

The first flight level belongs to the team that completes the daily work. Often those who are involved are highly-specialized experts, and I encounter such teams again and again, especially in high-tech environments. These specialists work exclusively in a sub-area of an enormous system, such as the fuel-injection systems for automobiles or the graphical processing of a weather radar for airplanes. Another typical manifestation of entities at Flight Level 1 are cross-functional teams, such as a designer, developer and tester, who work together on a small product or subsystem. Usually a large piece of work makes its way to a team where it is broken down into workable pieces, and implemented step-by-step. Looking at it from this point of view, a work system helps the team visualize, limit and continuously improve their work process. When a company consists of many teams, and not just one, the limits of optimization occur at the interface to other units and it can—as we already saw in the flow experiment—even lead to sub-optimization of the entire system. The improvements are limited to within the team, and can lead to difficulties in other teams.

The biggest disadvantage is that the customer’s wishes are not necessarily better fulfilled, despite the best intentions of the team. To explain this, I am going to use the keyboard as an example.

Let’s assume a customer would like a letter written. Let’s further assume that each team in the company is responsible for a row on the keyboard. Each team is the master of their row, but there is always room for improvement. For example, Team 3 can optimize themselves to the point of having a new world record for typing A the fastest. Fantastic! However, the customer’s letter will not be written any faster because of this. When writing a letter, it isn’t going about how fast you can type one single letter of the alphabet. It’s more important that the correct letter is typed at the right time, in order to achieve an actual increase in performance. That’s why the focus of improvement should involve the entire organization. The organization should be the one adjusting to the customer with an evolving process: What must be done in order to generate optimal value for the customer? If there is more than one team at the operational level, it is important to coordinate the work. It doesn’t matter in which branch or which area: On the road from “concept to cash” there exists, as a rule, dependencies between the teams. Each team, or each unit, completes only one portion of the value creation for the customer. For the coordination to be useful, the value creation chain of the products or projects must first be identified. Whether an organization is agile or not has nothing to do with the number of agile teams within the organization. The interaction between the teams must be agile.

Flight Level 2: Coordination

We can look at this in terms of a typical situation in the business world. The following picture shows a situation I see again and again in larger companies (40 to 40,000 employees). Several teams are required in order to generate value for the customer.

In most cases, the customer gets no value when tested code is delivered. The value is achieved once the code is integrated into a larger (live-) system within the company. On the other hand, customers rarely specify their wishes so clearly that they can be immediately implemented. In fact, it’s quite the opposite. As a rule, there is much to be done before the actual development work can be started. There needs to be leads generated and project teams drafted, the team must understand what the customer wants, contracts must be signed, etc. As soon as you take a look at the other areas, the value stream looks completely different, such as in product maintenance or in product management. Nevertheless, the idea behind it is the same: Creating value for the customer is more important than a hyper-productive team. This is exactly where Flight Level 2 begins.

At Flight Level 2, the interaction of the teams is optimized. To stay with the keyboard metaphor, at Flight Level 2, we ensure the right team is pushing the right key at the right time, i.e. working on the right work at the right time. A Flight Level 2 system coordinates the work of several teams who together are involved in fulfilling customer wishes, and bring specific services into the value creation chain. The goal is to optimize the work flow beyond the team border. Flight Level 2 work systems achieve massive performance improvements primarily for two reasons:

1 .  The employees work on the right things at the right time because the work flow is coordinated beyond team boarders.

2.  The number of work items is limited throughout, so the work system as a whole can be optimized.

Since the work flow is optimized over the entire value stream, the waiting time at the interfaces is reduced and, most importantly, the bottlenecks become clearly visible. Anyone who has experienced organizations at this flight level can only chuckle when high-performance teams are hyped as the secret to success. The larger the company, the more value creation chains there are within the company. Thus, there are more coordination boards being used that can also be hierarchically structured.

If we look at Flight Level 2 from the change management perspective, initiatives at this flight level are sometimes easier than at Flight Level 1, even if coordinating several hundred people. The decision to implement an across-team optimization falls to higher management. That means management has to set a good example and be the change they want to see. At the same time, there is no immediate need to change the way individual teams work at the operational level. Whether a team uses Kanban or Scrum, or just simply works on their stuff, is completely irrelevant. The only change, if you want to call it that, is that the delegates of the teams coordinate with each other in specific meetings, typically in routine Standups.

Is that a waterfall?
When you look at this picture, you might have the opinion that flight level 2 is the manifestation of a waterfall-type implementation. What does waterfall development mean? Just because things are worked on sequentially does not mean you are automatically in a waterfall development process (by the way, Winston Royce described the waterfall model as an iterative process). It is, however, a good model—such as programming software functionality before delivering it.

Working literally according the waterfall principle means work items pulled through the work flow are very large, such as a complete project. It is not expedient to first analyze an entire project, the develop it and finally implement it. This is not point I am making. Instead, the work items should be as small as possible, so you can verify the correctness of the approach as quickly as possible. This requires getting feedback as quickly as possible and be able to learn something from it.

Flight Level 3: Strategic Portfolio Management

Normally organizations do not work on just one project or one product. A company’s portfolio is comprised of a variety of projects and products, as well as strategic initiatives that keep the company fit for the future. Flight Level 3 manages exactly this mix. You want to gain an overview of what takes place in the company. You also want to know which projects and strategic initiatives are having an effect in which way, and how far the implementation has progressed. Can a new project already be started or should you wait until another project is completed? What investments should be made? Should a new market be conquered, or should an existing market share be increased? Which change initiatives are currently running in the company?

This last question—what is currently running with which purpose in the company—is especially suited to be visualized on a strategy board. This way, top management can recognize if contradictory orders were given and whether or not the initiatives are obstructing one another. Such contradictions occur primarily when companies want to become agile and several consultants, with their various opinions, are working with the company. On one day, self-organization is promoted, and the next day old-school reporting is requested. At this flight level, it’s going about strategic management of the entire organization and not about micro-managing the operational implementation. Large companies with offices around the globe have several strategies due to the various local market requirements, and as such, several strategy boards exist and a coordination board for all locations is at the company headquarters.

Having more demand than you are able to supply is fundamentally a good problem, otherwise a company must reduce its workforce. As a result, there is competition at the portfolio level between the options. This disparity between options and implementation possibilities must be explicitly clear, otherwise there might be an impression that there are unlimited resources available. This is not the case and this is exactly the point of a work system at Flight Level 3: making prudent choices and combination of projects, developing products and strategic initiatives, recognizing dependencies and optimizing the flow through the value creation chain with the currently available resources.

At Flight Level 3, the types of jobs being dealt with are large work items, such as “market entry in Hungary” or “less automotive, more aviation business”. At this Flight Level, these vast functionalities and initiatives compete with one another, so the organization is forced to make a well-considered and deliberate decision about what should be completed next. The focus is no longer the goals of the individual projects, but rather the overall result for the organization. Demand and possibilities must be balanced exactly.


The following diagram consolidates the flight levels into one complete picture:

Flight Level 3 is the strategic heart of the organization. The projects and initiatives of the company converge here and strategic management is located here. Flight Level 3 is connected with several systems at Flight Level 2 and Flight Level 1, where the operational work is managed. The example “market entry in Hungary” at Flight Level 3 may only contain two tickets, “prepare product group X” and “prepare product group Y”, but at Flight Level 2, these superficial work items will be broken down into smaller workable items and handed on to the teams at Flight Level 1.

It also happens quite often that work from Flight Level 3 flows directly to a team at Flight Level 1. Let’s assume that our company is an auto parts supplier and the strategy at Flight Level 3 states “more aviation business”. There is a product that is being developed for the automobile market, but with slight modification, in theory, the product might also interest the aviation market.  A team of specialists take care of testing this theory, so the work item flows directly from Flight Level 3 directly to a specialist team at Flight Level 1.

Flight levels are not a model for maturity or evaluation. A team problem cannot be resolved with a strategy board, just as a strategy cannot be implemented through a scattered team initiative. Nonetheless, I see similar thought processes with agile initiatives. There is a strategic problem, namely the uncertainty about how the market will develop in the future. And although nobody knows what the future brings, all the teams are made agile as a preventative measure. Agility is a strategic topic and cannot be resolved primarily at the operational level, especially in areas where it is not even necessary. If you want to make improvements in an organization, you must first be clear which level is best suited to achieve them. The flight levels should help identify the appropriate level. Generally, it can be said that the higher the flight level, the greater the leveraging effect. If there is the possibility to start an initiative for improvement at Flight Level 3, you should do it. The only agile team that is needed at the start of becoming an agile organization is an agile top-management team, which carries out strategic portfolio management. Everything follows from here—lead by example.