In this month’s article, Mike makes barbeque out of the biggest sacred cow of all: That Agile is something special and that it has been implemented properly in the world of Health IT. Read time: 8 minutes. Suggested drink pairing: Torres 5G Cinco Garnachas.
Sprint Retro-Spective
It seems like 80’s retro style is everywhere these days. Donald Trump made good on a 1988 comment about running for President. Stranger Things and soft reboots of 80’s movies like Ghostbusters or The Thing are highly popular. Musically, 80’s-style Synthwave is quite popular among the avocado toast crowd. Continuing the retro trend, the English band GUNSHIP even got John Carpenter himself to provide vocals for “Tech Noir.”
http://https://www.youtube.com/watch?v=-nC5TBv3sfU
Content warning: Graphic Claymation violence; literally every 80’s action movie reference; RoboCop; unsafe operation of a Claymation motorcycle; not being kind and rewinding.
Along with the repackaging of 80’s pop culture, we are seeing a repackaging of 80’s development methodologies. Spiral Development, first conceptualized in 1986, is being repackaged and sold to Federal Health IT stakeholders as Agile. We’re going to explore this a bit more in part two of our ongoing series:
THE MEANINGLESS USE
SNIFF TEST
Agile versus Spiral: A Primer
Waterfall doesn’t scale and IT experts have bought into iterative development. Today, the flavor of iterative development we all know is Agile, which has a variety of toppings: Scrum, Scaled, etc.
Back in the 80’s and 90’s, it was called Spiral. Here is Spiral in a nutshell:
“Why isn’t it a Fibonacci Spiral? WHY ISN’T IT A FIBONACCI SPIRAL? WHY!!???” – Mike’s OCD
Most “Agile” in Federal Health IT is actually Spiral. This is because Government is inherently risk-averse. The Government is the steward of taxpayer money, and in many cases, Government IT systems oversee life or death decisions. There’s a strong emphasis on planning and risk management and critical documentation.
True Agile, on the other hand, was pioneered by the video game development industry; a place where it is “easier to ask forgiveness than permission,” and where there was more value in a constant value stream of delivery than in correctness. Risks were encouraged if they could lead to increased marketshare. Who cares if you have a clipping error? Fix it in the next patch release.
I want to make this clear: There is no inherent “betterness” between Agile and Spiral. Each methodology is suited for different tasks. Overall, true Agile is better for things that require continual delivery and do not have significant risks associated with them. Websites (yes, including patient portals) are perfect for an Agile development methodology. Enterprise Resource Planning (ERP) systems, shared services, messaging buses, anything cybersecurity related, and similarly risk-laden projects are probably better suited to Spiral.
Here’s a quick run down of the differences between the two:
| True Agile | Spiral (AKA “Federal Agile”) |
| Increased risk of maintenance and sustainability issues, lending itself to low-impact items and small projects. | Emphasis on risk management and mitigation. Useful for high-impact items and large, interconnected projects. Not suitable for small or low risk projects. |
| Emphasis on minimal work and minimally viable product means easily created documentation; documentation is created as late as possible (“Agile-Late.”) for accuracy. Useful for self-contained applications. | Emphasis on intermediate states leads to significant documentation, which increases auditability and accountability but requires more work to curate and update. A hell of a lift, but useful for systems of systems, as well as interconnected systems. |
| Little or no planning required. Useful for projects where it’s less costly to fix something on the fly than to do the planning up front. | Significant planning is required. Useful for projects tied to a budget and appropriations cycle, or projects where it is more costly to fix on the fly than to do it right the first time. |
| Management is simple. However, it depends heavily on a customer who knows what they want and is proactive. Useful for projects where the stakeholders are unified and have similar understanding of the problem. | Management is more complex, but is requirements driven and does not require continual interaction from a customer. Useful for Government situations where the requirements generator, contract officer and PM are separate entities. |
| Partial working solutions are delivered early. Useful for standards and toolkits-based approaches like Websites or Mobile apps. Works well for a customer base that is focused on satisfying a personal need. | The project end may not be known and depends on prototyping. Useful for custom or Enterprise projects where a partial solution will not suffice. Works well for a customer base that is focused on satisfying a group mission. |
Federal Health IT practitioners: Which of the above columns looks like the real world systems you maintain? In my experience, at least 80% needed a Spiral methodology with a lot of emphasis on risk management. Health IT systems tend to be more conservative in their requirements because patient safety must come first. However, they are also older and require significant modernization. In addition, years of legacy data may be inaccurate, duplicate, or corrupt. Health IT modernization and sustainment naturally lends itself to Spirals.
Spiral, uh, Circle the Wagons
Health IT is frontier living, pure and simple. Visualize yourself in a dilapidated cabin. In the center of the cabin is a bassinet with a sleeping baby: Patient Safety. You look around at the walls and frown. The timbers are rotting and falling apart. The walls won’t stand for long. You hear a sound and stoop down. Looking between the cracked posts, you see snarling wolves. Each of them has a name: Cybersecurity threats, tech stack end of life, UI/UX trends, accessibility legislation. They want to eat that baby. They come more and more frequently. You need to patch these walls now.
You send someone out back to chop a tree, only to find everything is sitting on a shifting, quaking pile of bad data. At any point a tremor might bring the walls down on top of the baby. Now you’re screwed. In addition to having to chop a tree and patch the walls, you need to send someone to dig into the bad data, reinforcing the cracks and hauling out the bad bits. Anything might trigger a disaster. Doing nothing isn’t an option. Those wolves are hungry.
Now, maybe you’re the type of Federal Health IT practitioner that decides to Ted Nugent their way out of that with two crossbows and a machine gun, but most of us would treat this as a risky scenario. We would apply significant thought to reducing risks and making the best of whatever we can do. We would still move in small discrete steps. We would test the waters. We would make incremental corrections. But we would be sure to measure and track risks. It seems like fighting the Health IT modernization wolves would lend itself to Spiral.
And it does! Everyone’s heard “oh, it’s not really Agile, it’s water-Scrum-fall” at some point. That phrase is used often to describe Agile implementations in the Federal Health IT community. And so it is – “water-Scrum-fall” appears to be what the avocado toast crowd calls Spiral.
And Here’s the Problem
The Federal Health IT community can have its own little private lie that Spiral, or Spiral crossed with (Scaled) Agile is Agile, and I’m okay with that. It can be our own little secret-society shibboleth that lets us know we are all members of the Spiraling Order of Patient Safety. Yet we do have a problem.
When Federal Health IT contractors push Spiral as Agile, the Federal Government looks for Agile branding and certifications. This will lead to Federal Health IT vendors hiring subject matter experts and process coaches that “speak Agile.” Unfortunately, to “Speak Agile” means holding fundamental principles a Government contractor cannot put first. True Agile SMEs are indoctrinated in accordance with the Agile Manifesto, which clearly states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
“Individuals and interactions over processes and tools?” “Customer collaboration over contract negotiation?” In Federal contracting? Are you kidding me? When the value stream hits the fan, collaborating outside of the scope of the contract will send you to prison. Health IT is highly visible because of the emphasis on patient safety and PHI/data security. The contract is the only thing that can save you … or ruin you. Put simply, the contract is the law and the lash.
A typical KO during task order kickoff. Source: Achewood, November 17, 2004.
Again, I want to stress, there is nothing inherently good or bad about Agile or Spiral. Each is a different take on iterative development that meets different needs. Yet if the Government needs iterative development with a more process-based, risk-averse approach, they need to ask for it by name. Instead, by asking for Agile, we are repeating the same problems we see with PMBOK/PMPs.
Experienced professionals know how real-world Government contracting works. However, they need a certification. They take a class where they learn complete bullshit in the form of a perfectly idealized world where everything is a frictionless sphere and people are flawless robots. They are told, to pass the test, that they must fight the urge to give the real-world answer. “Give the PMBOK world answer,” they are told. The poor PMPs-in-training regurgitate the myth, pass the test, get their PMP and promptly go back to the real world.
In the end, nothing was taught, nothing was learned, and PMI made some cash. What a racket. Do we want our development to work the same way? Especially when a clash of organizational cultures can lead to delays or software quality issues that affect patient safety?
You Spin Me Round (Like a Spiral)
I’m normally not picky about terminology. My wife can tell you that I usually refer to the kitchen implements, pets, most historical events after 1994 and every political ideology as “that thing that does the thing.”
This Smurf smurfs it. Smurf: Smurf.
When dealing with any software related to patient safety, population health readiness, or PHI, however, it is important to be specific. I’ve cribbed nearly 90% of my viewpoint from this excellent article comparing and contrasting Waterfall, Spiral and Agile development. I strongly recommend you read it.
The bottom line is, Spiral is best used for medium to high risk projects, which every Health IT portfolio contains. Spiral is best suited when risk evaluation and costs are important, which fits every Federal IT project. Spiral is most needed when significant changes are expected and users are not 100% certain of their needs, which fits every modernization initiative.
If we are going to ride the 80’s nostalgia train, let’s bring back Spiral, in name and in fact, for Federal Health IT modernization. We’re going to need it.
And that’s all. GUNSHIP, play us out with 80’s sax so smooth it can sous-vide your soul to fork tenderness:
Content warning (absolutely all of this is real): Graphic anime violence; literally every 80’s vampire movie reference; the actual saxophonist from the Lost Boys; codpiece-based derringers; sax appeal; unsafe operation of a Yautja self-destruct device; real-world tomato juice wet T-shirt contest.
Next Time on The Meaningless Use Bull-HIT Sniff Test
Selfish Genomics: With due respect to Richard Dawkins, we will explore how the promise of precision medicine has been blown out of proportion. Spoiler alert: It’s grant money.
“We’ve sequenced your DNA and you still have metabolic syndrome? Must be, uh, epigenetics. Yeah, that’s the ticket.”
