Program Management and Scaling Agile Across Teams Questions

How I would handle this case

First, I would confirm the dependency chain: Team A feeds Team B, and Team B feeds Team C, so the critical path is A -> B -> C. Since A slipped by one week, the question is whether that week can be absorbed by slack in B or C, or whether it directly moves the launch.

What I would check immediately

• Remaining duration and buffer in Team B and Team C
• Which parts of C are truly launch-blocking versus nice-to-have
• Whether C’s 60% capacity is on critical work or supporting work
• Any opportunities to parallelize post-stability work from A

Decision on buffers and scope

If Team B has any slack, I would let that absorb the slip first. If not, I would use C’s buffer very carefully and protect only the highest-value launch-readiness items: compliance, customer comms, and the final readiness gate. I would re-scope anything nonessential, especially work that is polish rather than launch-critical.

Acceleration options

I would ask whether A can provide a partial handoff earlier, whether B can start integration in a limited mode, or whether C can get temporary support for the compliance review and comms prep. I would not compress validation if it risks quality.

My goal would be to preserve the launch date if possible, but only by making explicit trade-offs and protecting the critical quality gates.

How I build and maintain a dependency map

For a 4-6 team program, I keep the map simple enough to maintain and rich enough to drive execution. The map should answer three questions: what depends on what, who owns it, and what happens if it slips.

Fields I track

• Dependency ID
• Upstream team and downstream team
• Deliverable or interface
• Owner on each side
• Target date and actual date
• Dependency type: code, review, data, legal, launch ops, etc.
• Status: not started, in progress, blocked, done
• Risk level and critical-path flag
• Slack or buffer remaining
• Blocker, assumption, and mitigation
• Next checkpoint and escalation path

How I keep it actionable

I review it in every execution meeting, not just during planning. I only keep dependencies that have an owner and a date; otherwise they are just noise. I also mark which dependencies are truly launch-critical so the team knows where to focus attention.

If a dependency changes, I update the map immediately and call out downstream impact. That turns the map from a spreadsheet into a live management tool for risk and decision-making.

How I identify what is truly on the critical path

I start by separating "slipping" from "schedule-impacting." A task is on the critical path if its delay moves the final launch date because it has little or no slack and sits on the longest dependency chain.

Data I use

• Baseline plan with dependencies and milestone dates
• Actual progress versus remaining work
• Owner estimates for finish dates
• Dependency handoff dates and gating criteria
• Blocker logs, defects, and capacity changes

Root-cause diagnosis

I look for patterns: is the delay caused by underestimation, unclear requirements, blocked reviews, cross-team handoffs, or resource contention? I compare the original estimate to actual throughput and check whether the work is late because of execution or because the plan was unrealistic.

Recovery actions

I focus only on the critical path first: re-sequence work, remove non-essential scope, move reviews earlier, or add focused support to the bottleneck. If I add people, I do it carefully because ramp-up can slow teams down. I also protect quality by keeping test and sign-off gates intact, and I protect burnout by time-boxing recovery work and making trade-offs explicit.

I would never treat every slip the same; I manage by impact, not by noise.

Situation

I inherited a program that was already slipping. The schedule looked healthy on paper, but dependencies were not being tracked tightly and stakeholders were getting inconsistent updates.

Task

I needed to stabilize execution, find the real causes of the delay, and rebuild confidence without blaming the teams already doing the work.

Action

I started with a quick reset: I reviewed the plan, interviewed each workstream owner, and rebuilt the dependency map from scratch. That surfaced three root causes: unclear ownership on handoffs, optimistic milestone dates, and weak escalation when blockers first appeared.

I changed the execution model by introducing a single source of truth, a weekly risk review, and a stricter definition of done for each milestone. I also shortened the feedback loop by asking for concise written updates instead of waiting for issues to show up in the next meeting.

To rebuild trust, I was transparent about what had changed, what was at risk, and what actions were already underway.

Result

The program became more predictable, issues surfaced earlier, and stakeholders had a much clearer view of progress. Confidence improved because the plan stopped being aspirational and started reflecting reality.

That experience reinforced that recovery starts with facts, not optimism.

Operating cadence I would set

For a 10-week launch with shared engineers, I would keep the cadence lightweight but very intentional:

• Weekly program review, 45-60 min: only the PMs, tech leads, and a decision-maker per team. Review milestones, dependency health, top risks, and decisions needed.
• Twice-weekly 15-min execution syncs for the shared engineers and directly coupled owners. This is where we unblock handoffs and confirm next steps.
• Async written update every 2-3 days in a standard template: status, progress since last update, next milestone, blockers, asks, and risk changes.
• Milestone reviews at each major gate: design complete, integration ready, launch readiness, go/no-go.

Escalation thresholds

I would escalate when a critical-path item slips by more than a day or two, a blocker is unchanged for 24-48 hours, or a resource conflict threatens a milestone. If a team needs more than a small share of a shared engineer for a sustained period, that also becomes an escalation.

The goal is to make issues visible early through async updates and exception-based meetings, so we spend time on decisions, not status repetition.