Agile in Healthcare: Why Your Epic Team Is Still Running on Waterfall Time

Walk into almost any health system’s Epic program office and you will find a project plan that would look familiar to a 2005 software development team. Requirements gathering. Design. Build. Test. Train. Go-live. A freeze window. A hypercare period. Repeat in twelve to eighteen months.

The terminology has updated — sprints appear on Jira boards, retrospectives appear on calendars — but the underlying operating model has not. Teams still treat each Epic upgrade as a bounded project with a defined end. They still concentrate training in the weeks before a cutover. They still measure progress by tasks completed rather than by value delivered to clinicians.

This gap between agile language and waterfall practice is the reason so many health systems are perpetually running two, three, or four versions behind a platform they have already paid for.

What waterfall actually costs an Epic program

The cost is rarely visible in a single budget cycle. It accumulates.

When an upgrade is treated as an event rather than a cadence, three compounding problems emerge:

• Feature debt builds invisibly. Each release Epic ships contains functionality that patients and clinicians could benefit from today. Under a big-bang model, that value sits inert until the team accumulates enough changes to justify another upgrade event. A health system running quarterly releases on an annual cycle is carrying roughly nine months of unactivated, paid-for capability at any given time.
• Upgrade risk grows with size. A small change is easy to test and easy to roll back. A change that bundles eight months of platform updates, configuration changes, and workflow redesigns is inherently harder to validate and almost impossible to decompose if something goes wrong after go-live.
• Clinical adoption erodes. Training that happens weeks before a cutover is forgotten by the time the new workflows land. Studies on EHR adoption consistently show that knowledge decay is steep and fast. Refreshing training at the point of delivery — not weeks before — is what produces lasting behavior change.

What agile in healthcare actually requires

Agile is not a meeting cadence. It is not a backlog in a ticket system. For an Epic program, genuine agile delivery requires four structural commitments.

Cross-functional product teams, not functional departments. A waterfall Epic program sequences work through siloed teams: analysts build, trainers train, testers test. Agile programs organize around what they are delivering: a stable team of analysts, clinical subject-matter experts, and training specialists who own a feature domain end-to-end across every sprint.

A prioritized, outcome-linked backlog. The unit of work is not a ticket or a configuration task. It is a user story linked to a measurable clinical or operational outcome. A well-run Epic backlog distinguishes between “configure SmartForm X” and “reduce chart time for nursing staff in the ED by reducing documentation steps.” The outcome determines priority; the task is the mechanism.

Rolling validation and training. Features are validated with end users during the sprint that builds them, not in a staged UAT phase six weeks later. Training is delivered at activation, not at go-live. Super users are maintained as a live capability, not deployed for a cutover and then reassigned.

Lightweight, risk-based change control. This is the point where most healthcare agile programs stall. Change advisory boards designed for quarterly big-bang cycles become blockers when the team tries to ship incrementally. The solution is not to abandon change control — it is to redesign it for continuous delivery. Risk classification determines the rigor of the review, not the calendar.

The question is not whether agile can work in a regulated healthcare environment. It can. The question is whether your change-control governance was designed for the delivery model you want to run — or the one you inherited.

The honest challenge

Shifting from waterfall to agile delivery inside a health system is not primarily a technical challenge. Epic’s platform supports continuous feature activation. The tooling exists. What does not always exist is the organizational permission to operate differently.

Clinical governance structures, budget cycles, and project management offices were designed for a world where EHR delivery was episodic. Adapting them requires explicit sponsorship from the CIO and CMIO, not just bottom-up enthusiasm from the program office.

That sponsorship is most effectively built by running a controlled pilot: one team, one feature domain, one release cycle. Show the outcome data — time-to-activation, adoption rate, training-to-performance interval — and the argument for broader change tends to make itself.

Starting points that work

For health systems looking to close the gap between their stated agile practice and their actual operating model, the highest-leverage changes are usually:

• Eliminating feature queues that wait for upgrade windows; instead triage each Epic release into independently activatable items
• Establishing a dedicated capacity for Epic product work outside the break-fix queue
• Redesigning at least one change-control path to accommodate lower-risk quarterly activations without full CAB review

None of these require a transformation program to start. They require a decision.

The teams that sustain continuous Epic adoption are not exceptional. They simply operate as though keeping current is part of the job — because it is.