Case Study - Agile without Scrum

Agile Without Scrum

Stabilized delivery in a complex healthcare program by replacing rigid Scrum with Kanban to match dependency-heavy, flow-based work.

Context and Background

As part of a large data transformation initiative for a US-based healthcare and health insurance enterprise, the program focused on migrating critical capabilities from legacy systems to modern platforms across Claims Management and Utilization Management. The program operated within a SAFe Agile framework and involved complex integrations, heavy testing (TOCSA), and multiple release pipelines.

The delivery environment was unusually complex:

  • A multi-vendor setup involving client teams and multiple system integrators
  • A large, distributed scrum team of ~25 members across onshore and offshore locations
  • Strong dependencies on upstream and downstream teams for story readiness and execution
  • A technology stack including Java, Kafka, Informatica, and KSQL

Despite being labelled as an “Agile” program, the ground reality reflected fragmented processes, unclear ownership, inconsistent communication, and low confidence in Agile practices among key stakeholders.

Problem Statement

The team was formally operating under Scrum, but several structural constraints made Scrum ineffective:

  • Work items were highly dependency-driven, arriving unpredictably from upstream teams
  • There was no stable or groomed backlog available ahead of sprints
  • Sprint commitments were frequently disrupted due to external blockers
  • Traditional Scrum metrics like velocity were being misapplied to judge team performance
  • Release processes were complex and compliance-heavy, adding further unpredictability

This resulted in:

  • Missed sprint goals
  • Poor visibility into actual progress
  • Frustration among team members
  • Erosion of client trust in Agile delivery

The core challenge was not execution capability, but a mismatch between the delivery framework and the nature of work.

Product and Delivery Insight

Instead of forcing Scrum ceremonies and metrics, I approached the problem as a delivery-system design challenge—similar to optimizing a product for its real usage patterns rather than intended ones.

Through observation and discussions with developers, client stakeholders, the Agile Coach, and Release Management teams, it became clear that:

  • The work was continuous, flow-based, and dependency-heavy
  • Predictability was more important than sprint commitments
  • Visibility into blockers, capacity, and handoffs mattered more than velocity

Based on this insight, I proposed transitioning the team from Scrum to Kanban, while still aligning with the broader SAFe framework.

Execution and Implementation

The transition was implemented incrementally to minimize resistance and risk.

Key execution steps included:

  • Introducing Kanban boards in the client’s Agility tool with clearly defined states and WIP limits
  • Redefining Definition of Ready (DoR) and Definition of Done (DoD) to suit flow-based work
  • Implementing a Daily Status Tracker to capture issues, blockers, capacity utilization, and dependencies
  • Creating dedicated trackers for release readiness, compliance checks, and Enov8 updates
  • Establishing a clear communication protocol and escalation matrix for faster resolution of cross-team dependencies

Sprint velocity was consciously de-emphasized, and stakeholders were aligned on using cycle time, throughput, and flow stability as better indicators of performance. Capacity tracking was introduced to provide transparency rather than enforce artificial commitments.

The Agile Coach from the client side played a key role in reinforcing the rationale and helping socialize the change across stakeholders.

Stakeholder Management and Change Adoption

One of the biggest challenges was managing conflicting expectations:

  • A Product Owner skeptical of Agile feasibility
  • RTEs and leadership accustomed to Scrum metrics
  • Developers fatigued by repeated plan failures

Consistent communication, data-backed reasoning, and incremental improvements helped build confidence. Rather than positioning Kanban as a deviation, it was framed as a pragmatic adaptation to improve delivery outcomes.

Over time, the team and stakeholders began to see:

  • Improved predictability
  • Better utilization visibility
  • Reduced friction in releases
  • More transparent risk management

Outcomes and Impact

  • Stabilized delivery in a previously chaotic environment
  • Improved sync between onshore and offshore teams
  • Clear visibility into blockers, dependencies, and release readiness
  • Increased trust from client stakeholders through transparency and consistency
  • Demonstrated that Agile success depends on contextual application, not rigid adherence

Key Learnings

  • Agile frameworks must serve the work, not the other way around
  • Product thinking applies equally to delivery systems as it does to user-facing features
  • Change adoption is as much about trust and communication as it is about process design
  • Incremental, data-backed change is more effective than top-down transformation