Case Studies
Named clients. Scoped numbers.
Every metric below belongs to one engagement and keeps the scoping it was measured with. Where an engagement produced designs rather than measured deltas, it says so.
Relaunching a Multi-Team Agile Release Train
An enterprise client. Client name confidential under consulting agreement. Engagement details available in de-identified form, and references, on request.
The Challenge
The Agile Release Train had come off its planning cadence while a programme of platform migrations ran concurrently. The teams kept executing independently throughout, so the problem was not a cold start. It was re-convergence: Scrum Masters and Product Owners had each adapted their own way of working, and coordination had drifted into several overlapping meetings that covered much of the same ground.
The Approach
- 1Authored the ART relaunch readiness diagnostic: 25+ working sessions plus 1:1s with every Scrum Master on the train, producing seven prioritized findings, an eight-item go/no-go readiness checklist, and a quantified PI baseline.
- 2Authored the relaunch and PI planning design as a finding-by-finding response, consolidating overlapping coordination meetings into a single async-first sync, adding a planning retrospective, and keeping what already worked.
- 3Designed a Jira-native risk and dependency mechanism with client-side leads: risk-to-objective linking, a ROAM-complete workflow, and portfolio-consumable reporting, piloted by agreement rather than mandate.
- 4Coached the Scrum Masters, the interim RTE, and process leads through the relaunch.
The Results
- A readiness diagnostic the client can re-run before any future relaunch: seven prioritized findings and an eight-item go/no-go checklist, so the decision rests on readiness rather than a date
- A relaunch and PI planning design that responds to each prioritized finding, with a planning retrospective built into the cadence
- A Jira-native risk and dependency mechanism connecting agile delivery to portfolio governance
- Scrum Masters, the interim RTE, and process leads coached through the change
Engagement in progress. This page describes work delivered to date and will be updated as the engagement continues. This engagement has produced designs and mechanisms, not measured deltas. No outcome metrics are claimed.
Tools & Methods
How CPower Cut Cycle Time 42%
The Challenge
The software development organization at CPower was struggling with unpredictable delivery timelines. This engagement began with a Value Stream Mapping session that revealed the real bottleneck was not the team’s capacity, it was an upstream dependency queue that had never been made visible. Once visualized, the solution was straightforward. Work items routinely took 3–4x longer than estimated. Management lacked visibility into where work was stuck, and teams were context-switching between too many priorities simultaneously. The organization had tried Scrum but found the meeting and ceremony overhead did not fit their maintenance-heavy workflow mix of planned features, production support, and regulatory compliance work.
The Approach
- 1Introduced Kanban as the primary delivery framework and facilitated value stream mapping workshops to visualize the full workflow from request to production.
- 2Established explicit WIP limits at each workflow stage, not arbitrary caps, but calculated from historical throughput data, to surface bottlenecks and reduce context-switching.
- 3Built delivery dashboards connected to the team's work tracking system to visualize cycle time, throughput, and aging work in real time.
- 4Introduced periodic flow review meetings where teams analysed their own metrics, replacing top-down status reporting with data-driven self-management.
- 5Implemented Service Level Expectations set from the team's own cycle time distribution.
- 6Introduced Monte Carlo forecasting so delivery dates carried confidence intervals instead of single-point estimates.
The Results
- 42% reduction in 85th-percentile cycle times (from 62 days to 36 days)
- 59% increase in team throughput, items delivered per month
- Average WIP cut from 14 items per team to 5 via throughput-calculated WIP limits
- Service Level Expectations implemented and used for commitments
Measured using flow analytics from the team's work tracking system over a six-month engagement. Cycle time was tracked from commitment point to delivery.
Key Results
42%
Cycle Time Reduction
85th-percentile: 62 → 36 days
59%
Throughput Improvement
Items delivered per sprint
Tools & Methods
Flow Efficiency From 15.86% to 32.8% at NRG Energy
The Challenge
A technology squad at NRG Energy was operating with minimal coordination and no shared measurement framework. Flow efficiency, the percentage of total cycle time spent in active work versus waiting, was measured at 15.86%, meaning work items were spending the majority of their lifecycle sitting in queues, not being worked on. The team was busy but delivery was slow. This squad had no visibility into its own bottlenecks, and there was no cross-team mechanism for identifying shared impediments or building collective capability.
The Approach
- 1Conducted value stream mapping workshops with the squad to visualize current-state workflow and identify where work spent the most time waiting rather than being actively worked.
- 2Designed and facilitated structured coaching using a sprint-over-sprint tracking framework measuring five dimensions: Value Delivery, Output, Flow, Morale, and Quality, giving the squad and Scrum Master a repeatable improvement lens.
- 3Introduced defense/offense standup formats that separated reactive work from proactive work, making the planned vs. unplanned work split visible and manageable at the daily level.
- 4Introduced Kanban across two portfolios covering 50+ members, and aligned OKRs with Directors and VPs.
The Results
- Flow efficiency more than doubled on the measured team, from 15.86% to 32.8%, work items spent significantly less time waiting and more time being actively worked
- Cycle time reduced 57% on a DevOps team serving a portfolio of teams
- Cycle time reduced 24% on an SAP team
- Skills and capacity mapping identified and addressed critical single-points-of-failure in the squad
- Sprint-over-sprint coaching tracker was adopted by additional teams after the initial squad results
Flow efficiency was measured from the team's work-tracking analytics over a six-month period, calculated as active work time divided by total cycle time. The 15.86% to 32.8% figure describes one measured team, not the portfolio.
Key Results
33%
Flow Efficiency
One measured team: 15.86% → 32.8%
57%
DevOps Cycle Time Cut
DevOps team serving a portfolio
Tools & Methods
PI Planning at 100+: One Team of Teams at ExxonMobil
The Challenge
A single Agile Release Train at ExxonMobil brought more than 100 people into the same planning cycle. At that size the hard part is not the event itself. It is everything around it: whether teams arrive with work that is ready to plan, whether dependencies between them are known before the room fills, and whether the commitments made in the room survive contact with the next ten weeks.
The Approach
- 1Facilitated SAFe PI Planning for 100+ team members on a single Agile Release Train, including preparation with teams before the event and follow-through afterward.
- 2Facilitated System Demos, giving the train a regular integration point where progress was shown rather than reported.
- 3Facilitated Inspect & Adapt, turning the train's own data into the next round of improvement items.
- 4Ran cross-team dependency management and program-level risk handling across the train.
- 5Argued, alongside others, for a continuous planning model: PI Planning used for synchronizing the train, and lighter engagement for teams with nothing to synchronize. Evolutionary change, built by consensus rather than mandate.
The Results
- SAFe PI Planning, System Demos, and Inspect & Adapt facilitated for 100+ team members on a single Agile Release Train
- RTE-level responsibilities carried under a Senior Scrum Master title
- Cross-team dependencies and program-level risks managed as a standing cadence rather than an escalation path
- A case made, with others, for ceremony load following dependency structure rather than the org chart
No outcome metrics are claimed for this engagement. What is claimed is facilitation, scale, and a case argued alongside others.
Tools & Methods
Flow Metrics, Monte Carlo, and an AI Coaching Tool at Hilton Grand Vacations
The Challenge
Seven teams at Hilton Grand Vacations spanned Sales, Analytics, Data Science, and AI. That mix is harder to measure than it looks: on exploratory machine learning work, done is ambiguous, and estimation-based scheduling quietly turns that ambiguity into missed dates. Leadership needed a way to talk about delivery that survived the difference between a sales integration and a model experiment.
The Approach
- 1Ran a Flow-Based Metrics briefing series for Senior Directors, framing delivery in flow terms rather than estimate accuracy.
- 2Replaced estimation-based scheduling with Monte Carlo forecasting, so dates came with confidence intervals instead of single points.
- 3Delivered Scrum Master cohort training across the seven teams.
- 4Built and piloted an AI-assisted coaching tool that turned Azure DevOps flow data into retrospective prep and executive-ready narratives.
The Results
- Monte Carlo forecasting replaced estimation-based scheduling
- Flow-Based Metrics briefing series delivered to Senior Directors
- Scrum Master cohort training delivered across seven teams (40+ members)
- The AI coaching tool was piloted with the Scrum Master cohort and gained traction up the leadership chain
No outcome metrics are claimed for this engagement. Adoption is described as it happened: a pilot that spread.
Tools & Methods
Dev Team Flow Optimization
The Challenge
A dev team supporting critical energy infrastructure was drowning in unplanned work. Production incidents consumed ~60% of their capacity, leaving planned improvements perpetually delayed. The team operated in a reactive mode with no clear prioritisation framework. Lead times for planned work were highly inconsistent, and the team had no visibility into their own bottlenecks.
The Approach
- 1Implemented a dual-track Kanban system: one swim lane for production support (WIP limit: 3) and one for planned engineering work, making the capacity split explicit and visible to leadership for the first time.
- 2Allocated 40% capacity to unplanned work and 60% to planned engineering, turning an invisible trade-off into a deliberate, measurable policy.
- 3Built cumulative flow diagrams in a delivery dashboard to identify bottlenecks across the development workflow stages and guide root cause analysis sessions.
The Results
- 16% reduction in average cycle time for planned work (50 days to 42 days)
- Unplanned work ratio dropped from ~60% to ~30% through structured root cause analysis
Metrics were tracked using the team's delivery workflow tooling and flow dashboards over a four-month engagement.
Key Result
30%
Unplanned Work Reduction
Reactive incidents: ~60% of capacity → ~30%
Tools & Methods
Let’s Talk
Ready to see similar results with your team?
Want to talk through what your own delivery data shows? Send a message.