Two Approaches for Solving Dependency
In the recent email exchanges, one topic came up as whether introducing more coordination meetings and roles actually solves dependency problem or just "shifts the burden".
Shifting the burden is one common system archetype, which consists of two balancing loops and one reinforcing loop. For the topic of dependency, I draw the below CLD (Causal Loop Diagram).
Two balancing (B) loops
Two balancing loops illustrate two approaches for solving dependency problem. In scaling environment with multiple teams, the dependency across teams often slows down the development, and poses big challenge for Agile at scale. There are a few scaling frameworks, and they address various scaling challenges differently. For this specific challenge, the two approaches (two balancing loops in CLD) actually represent SAFe way and LeSS way of solving dependency problem.
SAFe tries to manage dependencies. One essential activity in SAFe is PI planning, where dependencies are identified and coordination is fostered. SAFe's focus is on PI (Program Increment), consisting of a few Sprints. Where you have component teams, it is still possible to synchronize all relevant parts into the same PI, but it would be impossible to always synchronize those into the same Sprint. So, it helps to certain extent.
LeSS tries to remove dependencies. One key element in LeSS is feature team, which means to design team structure so that the cross-team planning dependencies are avoided. LeSS's focus is on Sprint, same as Scrum, which makes it critical to adopt feature teams. Feature team adoption addresses the root cause of dependency problem, but as it requires organization redesign, it is more disruptive and needs stronger motivation.
One reinforcing (R) loop
This is the addictive loop. Would the adoption of SAFe reduce the chance for deeper organizational change promoted in LeSS? Once SAFe solves the dependency problem to some extent, the feeling of control goes up, thus the motivation for deeper change goes down. That creates the reinforcing loop to favor the approach of managing rather than removing dependencies. Whether does this addictive loop exist? It depends on whether it is seen good enough to deliver in PI, and whether PI planning is seen effective in solving dependencies.
In my recent experience, the organization I worked with adopted SAFe before moving towards feature teams. They did not see that PI planning was sufficient in solving dependencies, "especially when there is change, which is inevitable in their environment". That makes me wonder that the pace of change is another variable affecting the dynamic.
The focus on PI, rather than Sprint, reduces the ability to respond to change. The assumption to make PI planning somewhat effective is that PI content is relatively stable during PI. Change is very disruptive to PI plan.
Therefore, I could imagine that "shifting the burden" dynamic exists when focus on PI is good enough and there is little change during PI, because then dependencies are seen well managed, so that the motivation for organizational change towards feature teams would be low.
