How to Assess the Design Quality of Agile@Scale or Project Management Frameworks? The 3 Layers of Scaling!

Project management and scaling agile methods often use a tri-layered structure in their frameworks. These layers encapsulate the breadth and depth of all organizational processes, from portfolio management to coordination, to team operations. Here, we explore the differentiating characteristics of these layers, their management methods, and their system characteristics to understand whether a framework is well-constructed or flawed.

The Three Layers: Unveiling the System Characteristics

The three layers in any project management framework are the portfolio, coordination, and team layers. Each layer carries out distinct functions and exhibits different system characteristics, thereby calling for diverse management methods.

1. The portfolio layer at the top ensures alignment of all projects or initiatives with the overarching strategy, determines the constraint and the sequence of actions, and checks whether the capacity is distributed appropriately to the most beneficial initiatives.
2. The team layer at the bottom focuses on maintaining optimal workflow and often manages the delivery of smaller parts or stories through a sequence of subtasks.
3. The coordination layer, sandwiched in the middle, handles dependencies and keeps deliveries on track.

It's interesting to note that the layers alternate between production/process and project characteristics. The portfolio and team layers align more closely with production or process, while the coordination layer, owing to its dependency-handling role, exhibits project characteristics. But Why production versus projects?

Production versus Projects ?- Understanding Metabolism of Organizations and the Nature of Work

In the context of organizational metabolism, the nature of work broadly falls into two categories:

1. Projects (aka initiatives, missions), characterized by strong internal and external dependencies. Here, the order of tasks is fixed.
2. Production (aka process or value stream), characterized by small, more or less equal tasks, which can be easily reordered.

For instance, on the team layer, production is evident in value streams and backlogs managed often by using Scrum (akin to Henry Ford's assembly line approach) or Kanban (akin to Toyota Production Control). On the other hand, the portfolio layer also exhibits production characteristics as it deals with numerous releases, initiatives, or projects, wherein the sequence can be altered.

The coordination layer, in contrast, presents a project-like nature due to its role in resolving dependencies. Effective management methods could be Critical Chain Project Management (CCPM) or Reliable Scrum for agile releases.

It’s essential to look at the characteristics of your value creation for each layer to use the most appropriate control mechanisms optimally.

Sidenote a Fractal Pattern: A Step Further in Layering

If we probe deeper, there exists a layer below the team layer responsible for processing subtasks for a story, characterized by strong dependencies, hence exhibiting project nature. Similarly, a layer above the portfolio layer deals with dependencies between programs or projects, again showing project characteristics. This presents an alternating fractal pattern of production and project characteristics.

Analyzing Framework Design: The Final Check

With a clear understanding of these layers and their characteristics, we can discern whether a project or agile management framework is well-designed or not. SAFe (Scaled Agile Framework) and Flight Levels, for example, utilize the same management approach for all three layers. SAFe leverages Scrum and Meetings, while Flight Levels typically uses Kanban boards. Yes, it works - but it's the "if you just have a hammer - all is a nail"-problem. You get the screw also into the wall with the hammer - but you need more force. What we see in SAFe(R) and Kanban/FlightLevels is that the coordination layer needs a lot of management energy to maintain - just because the chosen control methods don't fit the characteristics.

A simple and straightforward comparison table to visualize the management methods employed by SAFe, Kanban, and TOC in each layer:

SAFe, although popular, seem to fall short in their design as they use the same management approach across all three layers. This doesn't take into account the different system characteristics each layer possesses.

[2027-07-27 Klaus Leopold the driver behind the Flight Levels gave the hint in the comment "Kanban is one of many methods organizations use on FL1. Sometimes a kind of Kanban can make sense on FL2 (depending on the area of application) and Kanban doesn’t make sense on FL3." So I changed the design rating to "Let's have a look!"]

However, a more nuanced framework, such as the Theory of Constraints (TOC), employs Drum-Buffer-Rope (DBR) for managing the top (portfolio) and bottom (team) layers – both showcasing production character. For the middle (coordination) layer with project characteristics, it employs Critical Chain Project Management (CCPM). So every layer with an appropriate suiting mechanism.

Details of the Theory of Constraints elements

Depending on the situation, TOC provides different elements for optimal management - here, you can find details of the different elements that can be combined suitably in all three layers:

• Drum Buffer Rope (DBR) is the most effective process control s.
• Critical Chain “single” Project Management (CCPM)
• Critical Chain For Agile “Reliable-Scrum ”
• Simplified Drum-Buffer-Rope – Planning Phase (sDBR)
• Simplified Drum-Buffer-Rope – Execution Management (sDBR)
• agile Critical Chain Multi-Project Management
• the sDBR/sPM combination a details
• TameFlow Boards ?

These are just two examples of agile frameworks that can be combined out of the elements above:

• Full-scale agile Project and Product Framework - for more project-oriented environments like PEP of mechatronic products or special machinery and much more
• sDBR/PM Framework - for more value-stream-based production-oriented environments like in software/agile at scale environments

Conclusion

To sum up, a well-designed project management framework should embrace the distinct characteristics of each layer, applying diverse management methods to meet their unique needs.

The current agile@scale approaches do not distinguish and adapt different methods to the different characteristics of the layers - therefore, they are not optimally adapted. Sorry to say.

The Theory of Constraints (TOC) proves to be a more aptly designed framework. It recognizes the alternating fractal pattern and applies suitable management techniques at each layer, ensuring a more effective and streamlined project management process.

So just think about it.

p.s.: do you know about our special interest and expert GPT? It's like chatGPT but with all knowledge from the #BlueDolphin - DolphinGPT.ai

p.p.s.: more info on how to implement look at the #BlueDolphin community - Blue-Dolphin-World