Dependency Management: Spot and Track Blockers Early

Dependency Management: Spot and Track Blockers Early

One task can't start until another finishes. This chain exists in every project. The problem isn't the chain — it's the chain being invisible.

Frontend is waiting on the API. The API is waiting on a third-party service. The third-party service is in an approval process. If this dependency chain is written nowhere, Friday brings the surprise "this didn't finish." But if it had been visible on Monday, a three-day recovery window would have opened.

Blocker management starts with spotting early. Spotting early means being able to look at the system.

Why Blockers Get Noticed Late

There are three core reasons blockers show up late.

Dependencies aren't written down. The knowledge that "B can't start until A finishes" lives in the developer's head. It wasn't said during sprint planning, no note was added to the task. When A is delayed, the fact that B will also be delayed is only understood when A's deadline passes.

There's no WAITING status. Most teams don't use a status between In Progress and Done. But a significant portion of tasks aren't actively being worked on — something is being waited on. This waiting gets hidden under the "In Progress" label. Work appears to be continuing; in reality, waiting is happening.

Reporting a blocker feels costly. Saying "I'm blocked" feels like weakness or like it's creating unnecessary alarm. The developer waits while dealing with other things, doesn't report the blocker. The team lead learns about the blocker at week's end.

WAITING Status: Making the Wait Visible

The center of dependency management in Alios is the WAITING status. Added to the standard flow, this status means "not actively working, something is being waited on."

🔄 IN PROGRESS  → actively being worked on
⏳ WAITING      → something is being waited on, can't progress
👀 REVIEW       → complete, awaiting approval
✅ DONE         → closed

The difference between WAITING and REVIEW is critical. In REVIEW, work is complete and someone else's approval is being waited on. In WAITING, work needs an external input to continue — and because of this wait, the task can't progress.

When Moving to WAITING

When a task moves to WAITING, a single-line note isn't enough. The following information gets added to the node description:

⏳ WAITING — [Date / Time]

What is being waited on:
[Specific — not "API documentation" but
"Payment service API key and endpoint list"]

Who it's being waited on from:
[Name or team — internal / external]

When it's expected to arrive:
[Date or "unclear"]

What happens if it doesn't arrive:
[This task's deadline: X — if WAITING lasts N+
days, the sprint goal comes at risk]

Is there an alternative:
[ ] Yes — [Description: can proceed with mock data etc.]
[ ] No — fully blocked

These five fields make the blocker manageable. "What's being waited on, from whom, by when, is there an alternative?" are answered in the node. The team lead can see the situation instantly and intervene.

Writing the Dependency Chain into Nodes

During sprint planning, dependencies get written as notes into the task. This note serves as a reference throughout the sprint.

📌 Frontend — Payment History Page
Status: IN PROGRESS
Owner: Mehmet
Deadline: Thursday

Dependencies:
→ WAITING ON: "Payment API — Ali" — deadline: Tuesday noon
→ WAITING ON: "Design approval — Zeynep" — deadline: Monday EOD

Note: If API doesn't arrive by Tuesday noon, this task
moves to WAITING and Thursday deadline comes at risk.

When the dependency chain is written this way, two things happen: Mehmet knows what he's waiting for and when he needs to raise the alarm. The team lead knows they need to check in by Tuesday noon.

Dependency Chain Example

📁 SPRINT 11 — Payment Module

📌 Stripe API Integration
Owner: Ali — Deadline: Tuesday
Dependency: External → Stripe API key approval (Monday)
Status: WAITING → moves to IN PROGRESS when API key arrives

     ↓ can start when complete

📌 Payment History Backend
Owner: Ali — Deadline: Wednesday
Dependency: Internal → "Stripe API Integration" — must be DONE
Status: NOT STARTED

     ↓ can start when complete

📌 Payment History Frontend
Owner: Mehmet — Deadline: Thursday
Dependency: Internal → "Payment History Backend" — must be DONE
Status: NOT STARTED

     ↓ can start when complete

📌 Payment Module QA
Owner: Zeynep — Deadline: Friday noon
Dependency: Internal → "Payment History Frontend" — must be DONE
Status: NOT STARTED

When this chain is visible, a calculation becomes possible: if the Stripe API key doesn't arrive Monday, the entire chain slips and Friday's QA is in danger. If this calculation is done Monday, there's no need to wait until Tuesday — by Monday evening the alternative plan kicks in.

Weekly Risk Control Routine

Writing dependencies isn't enough. Without regular review, the written information stays static and doesn't become a dynamic management tool.

Twice a week, 20 minutes total:

📋 MONDAY MORNING — 10 MINUTES

Question 1: How many nodes are in WAITING this week?
→ For each WAITING node:
  • What is being waited on, by when?
  • If time has passed: why is it still waiting?
  • Has the person to follow up with been identified?

Question 2: Do nodes with a deadline this week
have dependencies?
→ Was the dependency completed, or still waiting?
→ If not completed: is the deadline at risk?

Question 3: Are there new blocker signals?
→ Were vague responses like "I'll look into it"
  or "I'll let you know" converted to WAITING?
→ If not: node gets updated today

📋 WEDNESDAY NOON — 10 MINUTES

Question 1: Were Monday's WAITING nodes resolved?
→ If resolved: did they move to IN PROGRESS?
→ If not resolved: is the sprint goal affected?

Question 2: Were new WAITINGs opened this week?
→ Is there an alternative plan for new blockers?
→ Is something now visible that won't make it to Friday?

Question 3: Is there drift in the dependency chain?
→ If the first link in the chain was delayed,
  were the following links updated?

The Wednesday check is critical. Instead of saying "this didn't finish" on Friday, saying "this might not make it" on Wednesday opens a two-day intervention window. In this window either the blocker gets resolved, or scope gets reduced, or the task gets consciously moved to the next sprint.

WAITING Node Aging Rule

An aging rule applies to nodes staying in WAITING:

WAITING 1 day:   Normal — being tracked
WAITING 2 days:  Yellow alarm — active follow-up
WAITING 3 days:  Red — escalation needed
WAITING 5+ days: Sprint goal at risk — alternative
                 plan kicks in

This rule eliminates subjective judgment. When the "more than 3 days in WAITING" filter runs, nodes requiring escalation appear automatically.

Blocker Reporting Culture

No matter how well the system is built, if reporting a blocker isn't normalized, the WAITING status doesn't get used.

Three rules that build a blocker reporting culture:

Rule 1: Blocker = information, not failure. Saying "I'm blocked" doesn't mean "I can't do it" — it means "I need this information." The team lead explicitly stating this distinction and recognizing early blocker reporters builds the culture.

Rule 2: No permission needed to report WAITING. When a developer is waiting, they move the node to WAITING themselves. They don't wait for approval, don't wait for a meeting. The node update happens immediately.

Rule 3: Late-reported blockers are evaluated, not judged. The question "why didn't you say this sooner?" prevents earlier reporting next time. Instead, focusing on solutions with "what can we do now?" keeps the energy on resolution.

Final Thought

Dependency management and blocker tracking prevent surprises at sprint end. The path to preventing surprises is making the wait visible.

WAITING status, dependency notes, and the weekly risk routine in Alios build this visibility. The blocker appears Monday, not Friday. A visible blocker is a manageable blocker.

Keeping the first domino upright before the chain falls is possible — but only if you can see that it's wobbling.