Impact of Flight Levels on Scrum Teams, particularly at scale
I've been hearing a bit about Flight Levels lately, but I'd like to hear if anyone from this community could share their perspective, before I decide whether to dive down the rabbit hole, and invest time into learning more about it, or potentially introduce the concept to my colleagues. I'm a novice in this subject, so I welcome a range of perspectives, and even critical feedback if you think my way of looking at it can be problematic.
As I understand, it's about trying to visualize the transfer of information at an operational level (level 1), at a strategic level (level 3) and a co-ordination level between them (level 2), and that a disconnect between levels 1 and 3 is a fairly common pattern that a lot of organizations experience.
Instinctively, Flight Levels feels like an approach that would become increasingly relevant for larger organizations, and so I'm wondering what insights people have about when to apply it, or what indicators to watch for, that something like this might be useful.
My biggest unvalidated concern is that it could lead to a layer of processes or people at level 2, which may (implicitly or explicitly) encourage Scrum Teams or some of their members to stay at level 1.
When might level 2 not be needed? Or at least, when might level 2 best be kept to an as-thin-as-possible, informal lens of inspection?
Could the relevance of Flight Levels be reduced or eliminated if each team has a well-defined product that it can independently map back to the organizational strategy?
What other alternatives might there be?
They sound like constraint levels to me, and an alternative I'd choose might be to recognize them as such. The acknowledgment of a frozen middle or a management bubble can sometimes help with transparency for example.
I'd suggest that flight level might be a sugar term used to coat organizational gravity, and that it normalizes hierarchical dysfunction, and the disempowerment of agile teams. Certain inspect-and-adapt decisions may thus be kept above your team's flight level. It also neatly explains why you're in coach class while the higher-ups must have a private jet and concierge service.
My understanding of flight levels is different than yours, if I'm understanding. It's not about a way to visualize the transfer of information, but it's about sharing information at the right level of abstraction.
For example, in a large organization with multiple business units where each business unit has at least one portfolio of products, the people in charge of the organization or business unit don't care about each individual Product Backlog Item of a Scrum Team working on a product. The Product Owner may care about PBIs, but as you move up in the organization, they may care about groups of PBIs that represent features, for example. In a very large organization, the people at the top may only care about the high level view into what is happening across the whole portfolio and not necessarily individual products. These levels of abstraction are the flight levels.
I'm not a huge fan of the terminology or all of the associated concepts, but this maps to the idea of Story, Feature, Capability, and Epic in SAFe. Story is something that a single team works on. A Feature is a more complete stakeholder need and is made up of Stories. A Capability is made up of Features. An Epic is Capabilities. There may be some very important Stories or Features or Capabilities that do rise up a level of two because of their importance or criticality, but people can get the information they need and prioritize at their level, while deferring more tactical decisions to the people closer to the work.
Based on how I've seen flight levels used, you can't really eliminate them, especially in a large organization with different business units, departments, or products. However, how you generate the levels of abstraction may vary with your context. It's a matter of figuring out what stakeholders at different levels need and giving it to them.
This is a great question and one I've had as well. I have seen Flight Levels defined as all 3 of the above which has led me to believe that, like most things in the agile world, there is no definition.
I understand the concept and need for different levels of abstraction based upon the role of the information receiver. But I also fear the layers of process that could be introduced. I have experienced both but I actually fear the process most because I have experienced that in not so helpful ways. I see this as an opportunity for the Scrum Master to help the organization understand the Scrum Framework and how their interactions are helpful or distracting from the benefits.
I honestly think the terminology of "Flight Levels" is very similar to the way that "Agile" happened after the manifesto for agile software development was released. It is a marketing term for someone to sell a book or courses on how to deal with it. I think it is worth reading about because it is an actual thing that happens in some shape or form. As the levels of the organization changes, the level of important information changes. As agile practitioners, that is important to us because of the transparency, trust and responsibility for all levels of an agile organization that is needed in order to be successful.