,
40 tweets,
15 min read
Read on Twitter
In 2011 I was faced with the situation that I had to introduce #Kanban to a customer with about 300 teams. I started to count the billable days and before falling asleep I already thought about which color my new Porsche should have.
From the POV of a consultant, it is of course very lucrative to agilize 300 teams. From a company's POV, however, it is complete madness. You invest a lot of money, frustrate people, and the bottom line is that it's a big #suboptimization that won't lead to success.
That's when the keyboard metaphor was born: Let's say our org is a keyboard, each team operates a key, and we have to write a letter. High-performance teams don't finish the letter faster! We have to make sure that the right team is working on the right job at the right time 
The keyboard metaphor convinced that local team optimization does not optimize the entire org. We introduced Kanban across teams and I still don't have a Porsche. Since 2011, the keyboard metaphor has helped to convince orgs to optimize value delivery and not org structures
In 2011 my world was 100% #Kanban. Whenever it came to introducing Kanban, I tried to convince people to do it across teams. It is important for me to mention that it is still very valuable to help teams. However, an organization is not the sum of its teams.
After realizing that #Kanban works at team level and across teams, I tried to formalize it. The #FlightLevels were born: you see different things depending on how high you fly. When you fly low, you see many details but not much area, when you fly high it's the other way round
Flying high or flying low is not a judgement. If I want to cross the ocean quickly, I'll probably fly high in a fast plane. If I want to enjoy the landscape from above, I will rather fly quite low with a helicopter #FlightLevels
A high #FlightLevel does not mean that it is better than a low Flight Level - it addresses a different problem.
Originally there were only 2 #FlightLevels: FL1=Team (press key) and FL2=several teams/value stream (write letter). However, it soon turned out that companies don't just write one letter. So the logical consequence was FL3=Portfolio (multiple letters).
Keyboard metaphor and #FlightLevels are connected like this: FL1 = press a key. FL2 = write letter. FL3 = what letters should be written.
By the way, in the beginning there were 4 #FlightLevels. I have differentiated FL1 into teams with coordinated input and teams without coordinated input. Since I worked a lot with teams in 2011/12, this distinction was important to me.
Actually, the distinction between input coordination at team level is completely irrelevant, because as soon as there is a #FlightLevel 2, the input is coordinated. So the strategy must be to establish Flight Level 2 systems
By the way, the shipbuilding experiment can also be translated to #FlightLevels. FL1: one team completes a folding step, FL2: several teams work on one ship. Clearly knowledge work is more complex but that's why there's an extensive debriefing ;-) leanability.com/en/blog-en/201…
More and more organizations have asked for the introduction of #FlightLevels. That was really great! But many of them already had Scrum in use on the team level. It wasn't politically always easy to introduce *Kanban* flight levels - it was seen as competition to Scrum.
Scrum and #FlightLevels were never in competition! Scrum is useful for many teams in certain contexts. Nevertheless, it makes sense for these teams to coordinate if they have dependencies. The same applies for any other teams. This is exactly what a Flight Level 2 system does.
When I built the first #FlightLevel 2 systems, I was fully convinced that they had to be "real" Kanban systems. We need to see columns on the board, flow, classes of service, WIP limits, etc. The more experience I gained with FL2, the less important these qualities became.
Effective Flight Level 2 systems are often relatively simple in practice and often do not meet the definition provided by Lean Kanban University (LKU) for Kanban systems. FL2 systems are often rather shallow Kanban - but it doesn't need any more. For FL3 this is even more true.
My friend @kluak110 said something very beautiful yesterday at dinner: "Flight Level 2 and 3 is not about the board. The systems are communication points." I can only emphasize that. You should also have great respect for implementing these systems in organizations!
There are a number of nice examples that show that you can have respect when using the idea of #flightlevels in your org: leanability.com/de/video-blog/… via @EmpoweringTeam leanability.com/de/video-blog/… via @Kath_Schh and @dread71 leanability.com/de/video-blog/… via @SchimeraD to name only a few
Since about 2014 I don't say Kanban Flight Levels anymore but only Flight Levels. Main reasons: FLs are more common outside the Kanban community than within. FLs are also used more often in non-Kanban environments to coordinate the work of teams - no matter which method teams use
There's one more thing I want to clarify in this thread: Until 2015/16 was FL3 = portfolio (all letters we write). Since ~2016 is FL3 = strategic portfolio (which letters should we write) and FL2 = value stream (one letter) and operational portfolio (all letters we write). Why?
I actually assumed that companies had good reasons to work on initiatives - a strategy. The idea was that the strategy would be made explicit on the FL3 board and the work on the board would be aligned with the strategy. As @MatthiasPatzak explains here: leanability.com/de/video-blog/…
It was about 2015 when I was supposed to implement flight level 3 at a 100% IT subsidiary of a bank. There were loads of projects in their portfolio and of course I asked why they were working on these things - in other words which strategic aspects they covered.
The answer was: "We don't know any strategy. We get the projects assigned by the bank. That gave me food for thought. From the bank's point of view, the IT subsidiary was purely a cost center. The bank probably had a strategy, but the IT subsidiary just had to deliver.
Don't think, deliver :) Now you can say, this is evil and they will all go broke anyway and management has to be kicked out, all power to the developers, bla bla bla bla #unworldly #boring
I also like to dream of the optimal world and of course you can argue that the companies have to be merged, cross-functional teams have to be formed together with business, and so on. It just doesn't usually help the customer when you're faced with concrete problems.
As a small side note: That is also a little bit the problem I have with many do-gooders. The whole system has to change and if everything around me has changed then it's good. We need these visionaries, not an issue, they just aren't good consultants for concrete problems
I hope that the word "do-gooder" is appropriate in this context. Sorry for the lack of my English skills...
So, the bank's IT subsidiary, a lot of operational business, no strategy. I realized that there wasn't just one portfolio - there seemed to be one operational and one strategic portfolio. This is still my latest state of misunderstanding...
Since the primary goal of the operational portfolio is to coordinate that the right team is working on the right initiative at the right time, this would be a classic #FlightLevel 2 (coordination). We have to work on our operational stuff and we've to coordinate how to do it
I have also seen FL2 operational portfolio in eg agencies. There are a lot of customer projects that we just have to do to earn money. Of course or hopefully people are also working on strategic topics for the future, but the operational work dominates and needs to be done.
Assuming that initiatives are not to be found at the far right on a Wardley map, there are better ways of coordination than project plans. You could use agile practices and coordinate with a FL2 op portfolio that the right teams are working on the right stuff at the right time
So, my current state of error is the following: When it comes to (operational) implementation of initiatives, it is #FlightLevel 2 and when it comes to strategy and alignment of work with strategy, it is Flight Level 3.
To make matters worse, in practice the #FlightLevels are rarely separated cleanly. FL2+3 and FL1+2 are often mixed or exist on one board. That's why I always start by creating a flight level architecture (I don't like the name) to find out which boards have to be built at all.
Speaking of Flight Level architecture - This would be the best moment to advertise my Flight Level classes but unfortunately it doesn't help because all dates until summer are sold out. However, autumn/winter will come again and then there will be new dates ;-)
These are some examples of Flight Level architectures
The topic #FlightLevels is of course not "finished". Currently I'm thinking about a situation which we discussed in the previous Enterprise Kanban Coach #EKC. In a large organization a FL2 board was introduced for coordination in the test department, which has a lot of teams.
Is it #FlightLevel 2 when several specialist teams (e.g. test teams) coordinate their work across teams on one board? Phew, that smells a lot like local optimization, but there are still many teams.
#FlightLevel 2 is end-to-end coordination of value creation. But many companies are not that far yet. We often see end-to-end coordination of software development that is set up according to Scrum or something like that. But an organization is usually much more than sw dev.
For my client in Bangkok, agile SW development would certainly be seen as local optimization. We created a #FlightLevel architecture yesterday and SW dev was just a post-it called "IT". There are ~1000 people behind it but for the company it is not enough to just agilize this box
