13 min read • Guide 27 of 877
Managing Dependencies Between Development Teams
Multi-team projects fail when dependencies aren't managed properly. One team waits while another finishes, deadlines slip, and frustration builds. GitScrum provides dependency tracking, cross-team visibility, and coordination tools that help teams identify blockers early, plan work sequences intelligently, and maintain velocity even with complex inter-team relationships.
The Cross-Team Dependency Problem
Unmanaged dependencies cause:
- Blocked work — Teams idle waiting for other teams
- Hidden bottlenecks — Dependencies discovered too late
- Cascading delays — One slip affects multiple teams
- Duplicated effort — Teams build similar solutions independently
- Integration nightmares — Incompatible implementations
- Blame games — Finger-pointing when things go wrong
GitScrum Dependency Management
Tools for cross-team coordination:
Dependency Features
| Feature | Purpose |
|---|---|
| Task linking | Connect dependent tasks across projects |
| Blocker tracking | Highlight blocked work visually |
| Cross-project views | See dependencies across teams |
| Milestone sync | Align team milestones and deadlines |
| Notifications | Alert when blockers cleared |
| Dependency reports | Analyze dependency patterns |
Dependency Types and Mapping
Understanding Dependency Types
Dependency Classifications:
1. FINISH-TO-START (FS) - Most Common
───────────────────────────────────
Team A must FINISH before Team B can START
Example:
[API Team: Build Auth Endpoints] ──FS──→ [Frontend: Implement Login]
Frontend cannot start login until API endpoints exist
2. START-TO-START (SS)
────────────────────
Team B can START when Team A STARTS
Example:
[Backend: Start Database Schema] ──SS──→ [Frontend: Start Mockups]
Both can begin in parallel once requirements clear
3. FINISH-TO-FINISH (FF)
──────────────────────
Team B must FINISH when Team A FINISHES
Example:
[Feature Dev: Complete Features] ──FF──→ [QA: Complete Testing]
Testing finishes when all features tested
4. START-TO-FINISH (SF) - Rare
────────────────────────────
Team B cannot FINISH until Team A STARTS
Example:
[New System: Go Live] ──SF──→ [Old System: Decommission]
Can't decommission old until new starts
Dependency Mapping Template:
────────────────────────────
Task A: _______________
Task B: _______________
Type: [ ] FS [ ] SS [ ] FF [ ] SF
Critical Path: [ ] Yes [ ] No
Lag/Lead Time: ___ days
Notes: _______________
Dependency Matrix
Creating a Dependency Matrix:
Team Dependencies for Q4 Release:
─────────────────────────────────
│ Platform │ API │ Frontend │ Mobile │ QA
──────────┼──────────┼────────┼──────────┼─────────┼────────
Platform │ - │ FS(2) │ SS(1) │ SS(1) │ FF(0)
API │ - │ - │ FS(3) │ FS(3) │ FS(1)
Frontend │ - │ - │ - │ SS(0) │ FS(2)
Mobile │ - │ - │ - │ - │ FS(2)
QA │ - │ - │ - │ - │ -
Legend:
├── FS(n) = Finish-to-Start, n days lag
├── SS(n) = Start-to-Start, n days lag
├── FF(n) = Finish-to-Finish, n days lag
└── - = No dependency
Reading: Row depends on Column
Example: API row, Platform column = FS(2)
API depends on Platform finishing, 2 day lag
Critical Dependencies (must track closely):
├── Platform → API (2 days lag)
├── API → Frontend (3 days lag)
├── API → Mobile (3 days lag)
└── Frontend → QA (2 days lag)
Cross-Team Visibility
Multi-Project Dashboard
Cross-Team Dependency Dashboard:
Sprint 15 Status Overview:
──────────────────────────
Platform Team API Team Frontend Team
───────────────── ────────────── ─────────────────
[■■■■■■■■░░] 80% [■■■■■■░░░░] 60% [■■■■░░░░░░] 40%
│ │
├──────────────────────┘
↓
Waiting for API-234 ⚠️
Blocked Work:
┌────────────────────────────────────────────────────────────┐
│ BLOCKERS (3 items affecting 2 teams) │
├────────────────────────────────────────────────────────────┤
│ 🔴 API-234: Auth token refresh │
│ └── Blocking: FE-156, FE-157, MOB-089 │
│ └── Owner: @alice (API Team) │
│ └── Days blocked: 3 │
│ │
│ 🟡 PLAT-156: Database migration │
│ └── Blocking: API-240, API-241 │
│ └── Owner: @bob (Platform Team) │
│ └── Days blocked: 1 │
│ │
│ 🟡 FE-160: Design review pending │
│ └── Blocking: FE-161, FE-162 │
│ └── Owner: @carol (Design) │
│ └── Days blocked: 2 │
└────────────────────────────────────────────────────────────┘
Upcoming Dependencies (next 5 days):
├── Day 1: PLAT-160 needed by API-245
├── Day 2: API-238 needed by FE-165
├── Day 3: API-239 needed by MOB-092
├── Day 4: FE-168 needed by QA-200
└── Day 5: Design specs needed by FE-170
Cross-Project Task Links
Linking Tasks Across Projects:
Task: FE-156 "Implement SSO Login Button"
───────────────────────────────────────────
Dependencies:
┌─────────────────────────────────────────────────────────┐
│ BLOCKED BY (must complete before this task): │
├─────────────────────────────────────────────────────────┤
│ 🔴 API-234: Auth token refresh endpoint │
│ Status: In Progress (75%) │
│ ETA: 2 days │
│ Owner: @alice │
│ │
│ ✅ PLAT-148: SSO provider configuration │
│ Status: Done │
│ Completed: Jan 15, 2024 │
│ │
│ ✅ DESIGN-089: SSO login mockups │
│ Status: Done │
│ Completed: Jan 12, 2024 │
└─────────────────────────────────────────────────────────┘
│ BLOCKS (waiting for this task): │
├─────────────────────────────────────────────────────────┤
│ ⏳ FE-170: Complete authentication flow │
│ Status: Waiting │
│ Owner: @david │
│ │
│ ⏳ QA-210: SSO login test suite │
│ Status: Waiting │
│ Owner: @emma │
└─────────────────────────────────────────────────────────┘
Related (informational, no blocking):
├── DOC-056: SSO integration guide
├── FE-158: SSO error handling
└── API-236: SSO audit logging
Blocker Management
Blocker Workflow
Blocker Lifecycle:
1. IDENTIFICATION
──────────────
Developer discovers dependency not ready:
├── Mark task as "Blocked"
├── Link to blocking task
├── Add blocker label
├── Notify blocking team
└── Document in task notes
GitScrum Auto-Actions:
├── Task card turns red/orange
├── Blocker added to cross-team view
└── Slack notification to blocking team
2. ESCALATION (if unresolved >24h)
────────────────────────────────
├── Auto-escalate to team leads
├── Add to daily standup agenda
├── Trigger escalation workflow
└── Create dependency resolution meeting if needed
3. RESOLUTION
───────────
Blocking team completes work:
├── Mark blocking task complete
├── GitScrum auto-notifies blocked tasks
├── Blocked team pulls task from backlog
└── Metrics track resolution time
4. REVIEW
──────
Weekly dependency review:
├── Analyze blockers resolved
├── Identify patterns
├── Improve processes
└── Update dependency maps
Blocker Metrics Dashboard:
─────────────────────────
This Sprint:
├── Total Blockers Created: 12
├── Blockers Resolved: 9
├── Average Resolution Time: 1.8 days
├── Currently Blocked Tasks: 3
└── Teams Most Affected: Frontend (5), Mobile (4)
Blocking Sources:
├── API Team: 6 blockers created
├── Platform: 3 blockers created
├── External (Design): 2 blockers created
└── Infrastructure: 1 blocker created
Blocker Prevention
Preventing Dependency Blockers:
Pre-Sprint Dependency Check:
────────────────────────────
Before sprint planning, each team:
1. List Planned Work
├── Identify all stories/tasks for sprint
└── Note expected dependencies
2. Dependency Analysis
├── What do we need from other teams?
├── What are we providing to other teams?
├── When do we need it?
└── When can we provide it?
3. Cross-Team Sync (30 min meeting)
├── Share dependency lists
├── Identify conflicts
├── Negotiate timing
└── Document commitments
4. Sprint Backlog Adjustment
├── Reorder based on dependencies
├── Add buffer for uncertainty
├── Create placeholder tasks
└── Set up linking in GitScrum
Dependency Commitment Template:
───────────────────────────────
From: [Team Name]
To: [Requesting Team]
We commit to deliver:
├── Item: _______________________
├── Description: ________________
├── Delivery Date: ______________
├── Definition of Done: _________
└── Contact: ____________________
Risk Factors:
├── ____________________________
└── Mitigation: _________________
Acknowledged by: _______________
Date: _________________________
Coordination Patterns
Handoff Protocols
Team-to-Team Handoff Process:
HANDOFF CHECKLIST
─────────────────
Providing Team (e.g., API Team):
├── □ Work completed and tested
├── □ Documentation updated
│ ├── API documentation
│ ├── Usage examples
│ └── Known limitations
├── □ Environment ready
│ ├── Deployed to staging
│ ├── Feature flags configured
│ └── Test data available
├── □ Communication
│ ├── Notify receiving team
│ ├── Schedule sync if needed
│ └── Update task status in GitScrum
└── □ Support commitment
├── Available for questions
├── Quick response time agreed
└── Escalation path documented
Receiving Team (e.g., Frontend Team):
├── □ Verify handoff complete
├── □ Test integration
│ ├── Smoke test API endpoints
│ ├── Verify data formats
│ └── Check error handling
├── □ Begin dependent work
├── □ Provide feedback
│ ├── Issues found
│ ├── Missing items
│ └── Suggestions
└── □ Update task links in GitScrum
Handoff Meeting Agenda (15 min):
────────────────────────────────
├── 5 min: Demo what's delivered
├── 5 min: Walk through documentation
├── 3 min: Environment access verification
└── 2 min: Questions and support plan
Integration Points
Managing Integration Points:
Shared Integration Points:
──────────────────────────
1. API CONTRACTS
─────────────
Definition: [API Team owns, others consume]
Contract Management:
├── OpenAPI specs in shared repo
├── Version control all changes
├── Breaking changes require notice
└── Consumer teams approve changes
GitScrum Tracking:
├── Label: integration/api-contract
├── Any change triggers notification
└── Review required from consumers
2. DATABASE SCHEMAS
────────────────
Definition: [Platform Team owns]
Schema Management:
├── Migration scripts versioned
├── Impact analysis required
├── Rollback plan documented
└── All teams notified of changes
GitScrum Tracking:
├── Label: integration/database
├── Link schema changes to dependent features
└── Review required from API team
3. SHARED COMPONENTS
─────────────────
Definition: [Frontend owns, Mobile consumes]
Component Management:
├── Shared design system repo
├── Semantic versioning
├── Breaking change communication
└── Migration guides provided
GitScrum Tracking:
├── Label: integration/components
└── Link component updates to feature work
Integration Calendar:
─────────────────────
Mon Tue Wed Thu Fri
────── ────── ────── ────── ──────
AM │ API │ │ Schema │ │ Component
│ Contract │ │ Review │ │ Release
│ Review │ │ │ │
────┼──────────┼──────────┼──────────┼──────────┼──────────
PM │ │ Cross- │ │ Int. │
│ │ Team │ │ Test │
│ │ Standup │ │ │
Milestone Synchronization
Aligned Milestones
Cross-Team Milestone Planning:
Q1 Release Milestone Map:
─────────────────────────
Week 1 (Jan 1-5)
├── Platform: Database schema finalized
├── Design: All mockups delivered
└── Dependencies: None (parallel start)
Week 2 (Jan 8-12)
├── API: Core endpoints ready
├── Platform: Infrastructure complete
└── Dependencies: Platform → API
Week 3 (Jan 15-19)
├── Frontend: Core UI components
├── Mobile: Core screens
└── Dependencies: API → Frontend, API → Mobile
Week 4 (Jan 22-26)
├── Frontend: Integration complete
├── Mobile: Integration complete
└── Dependencies: Frontend ∥ Mobile (parallel)
Week 5 (Jan 29 - Feb 2)
├── QA: Testing complete
├── All: Bug fixes
└── Dependencies: Frontend → QA, Mobile → QA
Week 6 (Feb 5-9)
├── All: Release prep
└── Release date: Feb 9
Visual Timeline:
────────────────
W1 W2 W3 W4 W5 W6
├──────┼──────┼──────┼──────┼──────┤
Platform ████████░░░░░░░░░░░░░░░░░░░░░░░░
API ░░░░░░████████░░░░░░░░░░░░░░░░░░
Frontend ░░░░░░░░░░░░████████████░░░░░░░
Mobile ░░░░░░░░░░░░████████████░░░░░░░
QA ░░░░░░░░░░░░░░░░░░░░████████░░░
Release ▲
│
Feb 9
█ = Active work
░ = Waiting or not started
Milestone Dependencies
Milestone Dependency Tracking:
Milestone: "Q1 API Complete"
────────────────────────────
Depends On (must complete first):
├── ✅ M: Database Schema Finalized
│ └── Completed: Jan 4
├── ✅ M: Infrastructure Ready
│ └── Completed: Jan 10
└── 🟡 M: Auth Provider Integration
└── Status: In Progress (90%)
└── ETA: Jan 12
Blocks (waiting for this milestone):
├── ⏳ M: Frontend Integration Start
│ └── Planned: Jan 15
│ └── Can slip to: Jan 17 (2-day buffer)
├── ⏳ M: Mobile Integration Start
│ └── Planned: Jan 15
│ └── Can slip to: Jan 17 (2-day buffer)
└── ⏳ M: QA Test Environment Ready
└── Planned: Jan 18
└── Can slip to: Jan 22 (4-day buffer)
Risk Assessment:
├── Current Status: On Track ✓
├── Confidence: 85%
├── Buffer Available: 2 days
├── Critical Path: Yes
└── Mitigation: Daily check-ins until complete
Milestone Sync Meeting Agenda:
──────────────────────────────
├── Each team: 2 min status update
├── Blocker review: 5 min
├── Risk discussion: 5 min
├── Adjustment decisions: 3 min
└── Total: 15-20 min weekly
Communication Workflows
Cross-Team Standup
Multi-Team Standup Format:
When: Tuesday/Thursday, 15 minutes
Who: One representative from each team
Goal: Surface cross-team dependencies and blockers
Format:
───────
1. Round Robin (8 min)
Each rep answers:
├── "We're providing [X] to [Team] by [date]"
├── "We're waiting on [Y] from [Team]"
└── "We have [blockers/no blockers] to report"
2. Blocker Deep-Dive (5 min)
├── Top 2-3 blockers by impact
├── Owner commits to resolution date
└── Escalation if needed
3. Lookahead (2 min)
├── Dependencies due in next 3 days
└── Heads up on upcoming needs
Standup Board:
──────────────
┌────────────────────────────────────────────────────────┐
│ CROSS-TEAM STANDUP - Jan 16 │
├──────────────┬──────────────┬──────────────────────────┤
│ Providing │ Waiting On │ Blockers │
├──────────────┼──────────────┼──────────────────────────┤
│ API→FE: │ FE←API: │ 🔴 API-234 (3 days) │
│ Auth ready │ User mgmt │ Needs: Senior dev │
│ Jan 17 │ Jan 17 │ Owner: @alice │
├──────────────┼──────────────┼──────────────────────────┤
│ Plat→API: │ API←Plat: │ 🟡 PLAT-156 (1 day) │
│ DB migrated │ Schema done │ Needs: Testing │
│ Jan 18 │ Jan 18 │ Owner: @bob │
└──────────────┴──────────────┴──────────────────────────┘
Dependency Notifications
Notification Configuration:
Auto-Notify When:
─────────────────
1. Blocker Created
→ Notify: Blocking team lead
→ Channel: Team Slack + GitScrum notification
→ Include: Task details, impact, urgency
2. Blocker Resolved
→ Notify: All blocked task owners
→ Channel: Individual Slack DM
→ Include: Confirmation, any notes
3. Dependency Due Soon (3 days)
→ Notify: Both team leads
→ Channel: Email digest
→ Include: Dependency list, status check
4. Dependency Missed
→ Notify: All stakeholders + PM
→ Channel: Escalation Slack channel
→ Include: Impact analysis, request for plan
5. Milestone at Risk
→ Notify: Project leadership
→ Channel: Executive dashboard alert
→ Include: Risk summary, mitigation options
Notification Template:
──────────────────────
🚨 Dependency Alert: [Type]
Task: [Task ID - Task Name]
Team: [Affected Team]
Status: [Current Status]
Impact: [What's blocked]
Due: [Expected date]
Owner: [@owner]
Action Required: [Specific ask]
[View in GitScrum] | [View Dependency Graph]
Best Practices
For Individual Contributors
- Link early — Add dependencies when creating tasks
- Communicate proactively — Alert blockers before they become critical
- Document handoffs — Make transitions smooth
- Attend cross-team sync — Stay informed
- Update status daily — Keep dependency info current
For Team Leads
- Map dependencies weekly — Maintain current view
- Buffer for uncertainty — Plan slack in schedules
- Escalate early — Don't let blockers fester
- Build relationships — Cross-team trust speeds resolution
- Review patterns — Identify recurring dependency issues
For Program Managers
- Create dependency culture — Make tracking normal
- Provide tools — Ensure GitScrum is configured properly
- Run cross-team ceremonies — Facilitate coordination
- Track metrics — Measure dependency health
- Remove systemic blockers — Address organizational issues