When a Dependency Breaks Mid-PI
In a previous article, I argued that dependencies are rarely the real blocker at scale. What tends to slow execution is not the existence of a dependency, but the moment when a trade-off surfaces and the system is not yet ready to decide.
This article looks at a very concrete execution situation where that dynamic becomes visible: a dependency that changes mid-PI.
Not because planning was wrong. Not because teams failed to coordinate. Simply because reality introduced a constraint that was not present when commitments were made.
What follows is an observation of how delivery systems behave in that moment.
The disruption
Imagine a dependency between two teams that was identified and discussed during PI Planning. Capacity was available, priorities were aligned, and the dependency was considered manageable within the PI.
Halfway through execution, the context shifts. One of the teams loses capacity due to unplanned work. An incident, a remediation effort, or an urgent external request absorbs people who were originally allocated to planned delivery. The dependency itself has not changed, but the conditions that made it safe have.
The work is still relevant and still expected. No one declares it blocked. However, the buffer that allowed teams to absorb uncertainty is gone. What was previously a manageable coordination point now requires an explicit adjustment somewhere in the system.
This is usually the moment when the dependency becomes visible again, not because it is new, but because the system can no longer absorb it silently.
The system reacts
The reaction is generally reasonable and well intentioned. Teams and stakeholders try to understand the impact of the change before acting.
Additional synchronization meetings are scheduled. Impact is assessed across objectives and milestones. People try to clarify what can still be delivered as planned, what might need to move, and what should be protected at all costs.
Several options start to emerge during these conversations. Some suggest reallocating capacity to preserve delivery. Others propose reducing scope to keep flow stable. Some consider pushing part of the work later in the PI to avoid overloading teams.
Get Robert Saliba’s stories in your inbox
Join Medium for free to get updates from this writer.
At this stage, the system is active and engaged. A lot of energy is spent aligning perspectives and rebuilding a shared understanding of the situation.
The inflection point
Execution slows not because the system lacks options, but because it has too many acceptable ones.
Each option comes with trade-offs that are difficult to evaluate in isolation. Reallocating capacity solves one problem while creating pressure elsewhere. Reducing scope protects flow but impacts value. Delaying work maintains balance but challenges commitments.
None of these options are clearly wrong. None are clearly dominant either. Choosing one means accepting consequences that extend beyond a single team or dependency.
Until that choice is made, teams tend to proceed cautiously. They avoid committing fully to a path that might soon be reversed. Work continues, but without the confidence that comes from clear direction.
The system is not blocked. It is waiting for a decision it knows matters.
Waiting without a blocker
From the outside, nothing looks obviously wrong. Work items still move on boards. Meetings are happening. There is no explicit blocker to escalate.
Yet delivery starts to feel heavier. Coordination takes more time than expected. Progress becomes incremental rather than decisive. People hold back just enough to avoid rework if the direction changes.
This kind of waiting rarely shows up in metrics or tooling. It is not a hard stop, but a gradual loss of momentum caused by uncertainty around which trade-off the system is willing to accept.
The dependency did not stop execution. The lack of a decision changed how confidently the system could move forward.
One closing insight
The dependency didn’t block delivery.
What slowed execution was the time the system spent navigating the decision space it had just entered.
In the next article, I will look more closely at that moment: not the dependency itself, but how decision-making behaves when trade-offs surface during execution.
What the system is really doing at this stage is trying to rebuild coherence after a change it did not plan for.
