Delivery Manager

Delivery Manager

Delivery management skill covering execution through continuous improvement. Peer to project-manager -- neither contains the other. Routes all financial analysis to project-finance.

Intake Process

When a user brings a delivery management question, gather context first:

1. Delivery Context -- Team size? Single team or multi-team? Product type?
2. Framework -- What framework does the team use? Scrum, Kanban, SAFe, hybrid, or other?
3. Maturity -- How long has the team been using this framework? New, established, or experienced?
4. Domain -- Which delivery domain is needed? (planning, metrics, quality, dependencies, improvement, SLA)
5. Data -- Does the team have work item data (Jira export, CSV, etc.)?

Routing Detection

• If the request involves budget, variance, EVM, spend, or cost analysis --> route to project-finance. Tell the user: "I'll apply the project-finance patterns for this financial analysis."
• If the request involves WBS, governance, change control, stakeholders, RACI --> suggest project-manager. Tell the user: "This falls into project governance territory. The project-manager skill covers scope, risk, and governance."
• If the request involves status deck or presentation --> gather delivery metrics first, then apply presentation-builder patterns for the deck.

Routing Table

Domain Knowledge

Delivery Planning

Sprint Planning Approaches:

• Capacity-based: Calculate team capacity (available hours x focus factor), then pull stories until capacity is filled. Best for established teams with predictable availability.
• Velocity-based: Use average of last 3-5 sprints' velocity to set sprint scope. Best for stable teams with consistent velocity.
• Commitment-based: Team discusses each story and commits to what they believe they can deliver. Best for new teams or high-uncertainty work.

PI Planning (SAFe):

• Program board: visualize features, dependencies, and milestones across teams
• ROAM dependencies: Resolved, Owned, Accepted, Mitigated
• PI Objectives: business value, stretch vs committed, confidence vote
• Two-day event: vision, team breakouts, dependency management, plan review, confidence vote

Release Planning:

• Feature-based: release when a defined feature set is complete
• Date-based: release on a fixed date with whatever features are ready
• Release train: fixed-cadence releases (e.g., monthly) with feature toggles

Story Mapping:

• User activities (top row) --> User tasks (second row) --> User stories (detail rows)
• Walking skeleton: thin slice through all activities that proves the architecture works
• Prioritize by slice (horizontal cut across the map), not by individual story

Backlog Refinement:

• INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable
• Story splitting patterns: workflow steps, business rules, data variations, interface, spike
• Budget 10% of sprint capacity for refinement work

Agile Framework Selection

Read references/agile-frameworks.md for detailed comparison. Quick decision criteria:

Flow Metrics

Read references/flow-metrics.md for formulas and benchmarks.

Little's Law: Lead Time = WIP / Throughput

• This is fundamental. If you want shorter lead times, you must reduce WIP or increase throughput. Increasing WIP almost always increases lead time.

Cycle Time Analysis:

• Report percentiles: 50th (typical), 85th (most items finish by), 95th (nearly all items)
• Bi-modal detection: two distinct peaks in the cycle time distribution suggest two different types of work being mixed (e.g., bugs vs features)
• Trend over time: is cycle time improving, stable, or degrading?

CFD (Cumulative Flow Diagram) Reading:

• Band width = WIP in that state (wider = more WIP = likely bottleneck)
• Horizontal distance between bands = approximate lead time for that transition
• Vertical distance at any time point = throughput at that point
• Parallel bands = stable flow. Diverging bands = growing WIP (problem).

WIP Limit Setting:

• Start with current average WIP per state
• Reduce incrementally until queues form (expose bottlenecks)
• Common starting point: number of team members / 2

Flow Efficiency:

• Value-adding time / Total time x 100
• Typical for knowledge work: 15-40% (most time is spent waiting)
• Improving flow efficiency has more impact than improving speed

Monte Carlo Forecasting:

• When-will-it-be-done? Probabilistic answer using historical throughput
• Run N simulations using random samples from historical throughput
• Result: "There is an 85% chance we'll complete 30 items by March 15"
• Requires at least 10-15 data points for meaningful simulation

Quality

DoD Evolution:

• Start simple (code review + tests pass + deployed to staging)
• Add criteria as team matures (security scan, performance test, documentation)
• DoD at three levels: story (individual work), sprint (collection), release (production-ready)

Quality Gate Design:

• Dev: unit tests, code review, static analysis
• Test/QA: integration tests, regression suite, exploratory testing
• Staging: performance testing, security scan, UAT
• Production: smoke tests, monitoring confirmed, rollback plan ready

Tech Debt Management:

• Reserve 15-20% of sprint capacity for tech debt reduction
• Quadrant model: Reckless/Prudent x Deliberate/Inadvertent
• Track in a register: item, quadrant, impact, effort, priority
• Pay down high-impact debt first (affects delivery speed or reliability)

Defect Triage:

• Severity: Critical (system down) > Major (key feature broken) > Minor (workaround exists) > Cosmetic
• Escaped defect analysis: where in the pipeline should this have been caught?
• Defect trend: increasing escaped defects = quality process gap

Continuous Improvement

Retro Format Selection:

• Start/Stop/Continue: simple, good for new teams
• 4Ls (Liked, Learned, Lacked, Longed For): good for mature teams wanting depth
• Sailboat: good for stuck teams (anchors = what holds us back, wind = what helps)
• Timeline: good after incidents or challenging sprints
• Lean Coffee: good for teams with many diverse topics
• Mad/Sad/Glad: good for emotional processing after difficult periods

Improvement Backlog:

• Treat improvements as first-class work items (not "nice to haves")
• Each retro produces at most 3 specific, owned improvement actions
• Track completion of improvement actions in the next retro
• If improvements never get done, something is structurally wrong

Team Health Checks:

• Spotify model: dimensions like Delivering Value, Speed, Mission, Fun, Learning, Process, Support
• Score each dimension 1-5 with trend arrows (improving, stable, declining)
• Focus on the declining dimensions, not just the low-scoring ones

Value Stream Mapping:

• Map the flow from idea to production
• Measure time spent in each step vs time spent waiting between steps
• Identify bottlenecks (longest wait times, not longest processing times)
• Typical waste: handoffs, approvals, context switching, rework

SLA/SLO

Read references/sla-slo-reference.md for templates and calculations.

SLI/SLO/SLA Hierarchy:

• SLI (Service Level Indicator): the metric you measure (e.g., p99 latency, error rate)
• SLO (Service Level Objective): the target for the SLI (e.g., p99 < 200ms, error rate < 0.1%)
• SLA (Service Level Agreement): the contractual commitment with consequences (e.g., SLO + refund policy)

Error Budget:

• Error budget = 1 - SLO target (e.g., if SLO is 99.9%, error budget is 0.1%)
• When error budget is exhausted: freeze feature releases, focus on reliability
• Error budget policy: define what happens at 100%, 75%, 50% budget remaining

Incident Impact on Delivery:

• Calculate capacity lost to incident response
• Adjust sprint scope to account for incident time
• Track incident rate trend as a delivery health metric

Integration Points

• project-finance -- for delivery cost analysis
• presentation-builder -- for delivery status decks
• large-file-analysis -- for analyzing Jira exports, work item data
• project-manager -- cross-reference for planning and governance artifacts

Anti-Patterns

When NOT to Use This Skill

Reference Files

Read these on demand when the user's request falls into the relevant domain:

• ~/.claude/skills/delivery-manager/references/agile-frameworks.md -- Scrum/Kanban/SAFe/hybrid comparison, selection criteria, event cheat sheets
• ~/.claude/skills/delivery-manager/references/flow-metrics.md -- cycle time, lead time, throughput, WIP, CFD, Little's Law, Monte Carlo
• ~/.claude/skills/delivery-manager/references/ceremony-playbooks.md -- stand-up, planning, review, retro, refinement agendas and facilitation tips
• ~/.claude/skills/delivery-manager/references/quality-templates.md -- DoD, acceptance criteria, quality gates, tech debt register
• ~/.claude/skills/delivery-manager/references/sla-slo-reference.md -- SLI/SLO/SLA hierarchy, error budgets, availability nines, operational readiness