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).


Solve Dependency in English.jpg


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.


About this Entry

This page contains a single entry by Lv Yi published on March 24, 2016 2:50 PM.

Revisit feature team was the previous entry in this blog.

Create Discomfort for Continuous Improvement is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.