Knowledge Base

Case Studies

Real-world stories from complex delivery challenges. Each case includes the problem, approach, execution, outcome, and key takeaways.

Turning Around a Failing Delivery Team

How a 12-person team went from 40% sprint completion to 92% in 3 quarters

Fintech 9 months 12 engineers

Problem

A cross-functional team of 12 engineers was consistently missing sprint commitments, delivering only 40% of committed work. Stakeholder trust was eroding, morale was low, and leadership was considering restructuring the team. Sprint spillover was the norm, with an average of 60% of stories carrying over. The team had no Definition of Done, unclear priorities, and sprint planning was a formality rather than a deliberate exercise.

Approach

Instead of restructuring, I proposed a 90-day delivery improvement program focused on process fundamentals: 1. Week 1-2: Diagnostic phase — shadowed all ceremonies, interviewed every team member, analyzed 6 months of Jira data 2. Week 3-4: Introduced capacity-based sprint planning (replaced gut-feel estimation) 3. Month 2: Established WIP limits (max 2 items per developer), created a clear Definition of Done 4. Month 3: Reformed retrospectives with tracked action items, introduced sprint goals 5. Ongoing: Weekly 1:1s with tech leads, biweekly stakeholder updates with transparent metrics

Execution

The first sprint under the new process was intentionally conservative — we committed to 60% of typical volume. The team delivered 100% for the first time in 8 months. This quick win was transformative for morale. Key execution details: - Reduced average story size by 40% (large stories were the primary spillover culprit) - Moved from 'assigned work' to 'pulled work' model — developers chose their next story - Introduced pairing for complex stories, reducing rework by 35% - Created a 'sprint health' dashboard visible to the entire team - Eliminated mid-sprint scope additions (except P0 production issues)

Outcome

Sprint completion rate: 40% → 92% (over 3 quarters) Sprint spillover: 60% → 8% Cycle time: 12 days → 4.5 days Defect escape rate: 15% → 3% Team eNPS: 12 → 67 Stakeholder confidence: Restored (team moved from 'watch list' to 'model team')

Lessons Learned

  • 1Start with quick wins. The first successful sprint changed the team's self-perception.
  • 2Smaller stories are more predictable. A story that can't be completed in 2 days should be split.
  • 3WIP limits are transformative. Counter-intuitive but incredibly effective.
  • 4Process changes must be co-created with the team, not imposed on them.
  • 5Metrics should be visible to the team, not just management.

Delivering a Trading Platform Under Regulatory Pressure

Launching a compliant OMS in 6 months with zero regulatory findings

Capital Markets 6 months 20+ engineers

Problem

A trading firm needed to launch a new Order Management System (OMS) within 6 months to comply with updated regulatory requirements. Failure to launch on time would result in trading restrictions and significant financial penalties. The existing system couldn't be patched — it needed a rebuild. The team had no prior experience building compliant systems, and the regulatory requirements were ambiguous in several areas.

Approach

I structured the program around three parallel workstreams with clear handoff points: 1. Regulatory Clarity Stream: Embedded a compliance analyst in the team. Created a requirements traceability matrix mapping every regulatory clause to a user story. 2. Core Engineering Stream: Broke the OMS into 4 independently deployable modules — Order Entry, Execution, Compliance Checks, and Reporting. Each module had its own 2-person team. 3. Validation Stream: Built automated compliance test suites from Day 1, running against every PR. No code merged without passing compliance checks. Risk management was elevated to a daily activity. I maintained a risk register with 47 items, reviewed weekly with leadership.

Execution

Sprint structure was modified for the regulatory context: - 1-week sprints (faster feedback loop given tight timeline) - Every sprint had a compliance review gate - Feature flags enabled progressive rollout without regulatory risk - Weekly regulatory checkpoint with legal counsel Key decisions: - Chose to over-document rather than under-document for audit trail - Built a custom audit logging system (regulatory requirement) - Negotiated scope with regulators — focused on Day 1 requirements vs. 'nice to have' interpretations - Parallel testing with production data in an isolated environment

Outcome

System launched on time — 2 days ahead of regulatory deadline Zero regulatory findings during first audit 4 independently deployable modules (future maintainability) 98.7% uptime in first 6 months Audit preparation time: 3 weeks → 2 days (thanks to traceability matrix) Team retained 100% (despite high-pressure timeline)

Lessons Learned

  • 1Regulatory requirements are negotiable — engage early with regulators to distinguish must-haves from interpretations.
  • 2Traceability matrices are worth the investment. They saved weeks during the audit.
  • 31-week sprints create urgency and faster course-correction in time-critical projects.
  • 4Feature flags are essential for compliant progressive delivery.
  • 5Over-communication with stakeholders reduces anxiety and builds trust during high-pressure programs.

Scaling Agile Across 5 Teams Without Losing Speed

Implementing a lightweight scaling framework that preserved team autonomy

SaaS 12 months 5 teams, 40 people

Problem

A fast-growing SaaS company had expanded from 1 Scrum team to 5 teams within 18 months. Each team ran their own version of Agile — different ceremonies, different tools, different definitions of done. Cross-team dependencies were causing delays, and there was no visibility into the combined delivery roadmap. Leadership wanted to implement SAFe; the teams feared bureaucracy.

Approach

I rejected a full SAFe implementation as too heavyweight for the organization's size and culture. Instead, I designed a lightweight scaling approach I called 'Aligned Autonomy': 1. Shared cadence: All teams aligned on the same 2-week sprint cycle (start/end on the same days) 2. Cross-team sync: 30-minute weekly sync with one representative per team (not a status meeting — dependency management only) 3. Unified backlog visibility: All teams used the same Jira project with team-specific boards but a shared epic structure 4. Quarterly planning: 1-day planning event every quarter to align on objectives and identify cross-team dependencies 5. Shared Definition of Done: Created a company-wide DoD with team-specific extensions

Execution

Rollout was phased over 3 months: Month 1: Sprint alignment. Moved all teams to the same sprint calendar. Minimal disruption. Month 2: Dependency management. Introduced cross-team sync meetings. Created a dependency board in Jira. Each dependency had an owner, a target sprint, and a status. Month 3: Quarterly planning. Ran the first quarterly planning session. Each team presented their objectives, and we collectively identified and resolved dependencies. Ongoing: Monthly retrospective across all teams (rotating hosts). Shared metrics dashboard showing delivery trends across the organization. Key cultural elements: - Teams retained full autonomy over how they work (ceremonies, estimation, workflow) - Only alignment requirements: sprint cadence, dependency communication, shared DoD - No new roles created (avoided 'Release Train Engineer' overhead) - PM team facilitated cross-team coordination, not dictated it

Outcome

Cross-team blocking time: 5 days average → 1.2 days Dependency-related sprint failures: 35% → 7% Time to market for cross-team features: 40% reduction Team satisfaction with process: 3.2/5 → 4.4/5 Quarterly planning accuracy: 55% → 82% Zero teams requested return to old process

Lessons Learned

  • 1Scaling frameworks should be as lightweight as possible. Add process only where coordination pain exists.
  • 2Sprint alignment is the single highest-ROI change for multi-team coordination.
  • 3Dependency boards are more useful than dependency tracking in individual tickets.
  • 4Quarterly planning creates shared understanding that no amount of async communication can replace.
  • 5Autonomy and alignment are not opposites — they're both required for scaling successfully.
Back to Frameworks