In the iconic movie, The Princess Bride – one of my family's favorite movies – Vizzini keeps using the word "inconceivable." Finally, Inigo Montoya responds with, "You keep using that word; I don't think it means what you think it means." Well in my experience, one of the most overused, least understood, and least well-implemented concepts in Health IT is the word Agile. What makes that fact sad is that agility is exactly what our organizations need most from us today.
Health IT delivers software and solutions regularly. A shop need not be the actual developer of the software in order to adopt agile methodologies.
In fact, one need to read only a few lines from the Agile Manifesto to appreciate why this methodology has gained favor.
Manifesto for Agile Software Development
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.
Simplicity is beautiful when you see it. The four lines in the middle of the manifesto are so powerful. These lines flew in the face of a culture that created strategies in secret, and developed massive software projects that follow a rigid plan to get a project done.
These projects led to massive cost overruns for solutions that were never fully implemented, as well as highly-frustrated consumers and users of technology. What arose in response was an approach that valued software designed by (and for) the end users of the product. A process that welcomed change and valued interruption, when it came from a user whose idea made a better overall product. A process that valued small, quick wins – as measured by the software user's productivity and satisfaction – and not a product's project plan.
A Health IT system that lives by these principles will be at the center of an organization's success.
My premise, though, is that Agile is not the norm in Health IT organizations. However, it sure is talked about a lot. I'm going to touch on five areas that I believe demonstrate this: organization charts, walls, budgets, application sprawl, and pace of change.
Before we delve into those five areas, I would like to share the twelve principles of Agile, as envisioned by the authors of the manifesto.
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Good stuff, right? If this describes the work within your health system, I want to speak with you.
To be fair, there are pockets of this being done well in the industry, and you can probably rattle off the names as well as I can. You recognize them because you see announcements of new solutions that feature customer successes more frequently than most. These articles don't just note a product being rolled out into the market, either. Instead, they feature testimonials from the user community that helped to shape the product.
Providence St. Joseph Health developed an application for expectant mothers that was done in conjunction with cohorts of expectant mothers. This is an example of agile principles at work, but it doesn't necessarily mean that Agile has adoption across the entire IT organization. And it needs to.
Here is my anecdotal data to support the premise that Agile is not yet pervasive in Health IT.
Agile shops are loosely organized around products/experiences and not functions.
In my most recent CIO role, we productized our workstation solution. We had a product owner who was constantly talking to the end users to identify the product roadmap. We had pilots going for computerless patient rooms and using smartphones as the primary means of accessing the EHR. Non-agile shops are looking at better solutions as measured by what's currently there; agile shops are looking at doing better, based on the user's definition of "better."
Today's Health IT organizations are predominantly siloed. They are not conducive to cross-functional collaboration in pursuit of solving problems.
Wall space in the IT building should be scarce.
Our face-to-face meetings were always done in front of a scrum board. A scrum board answers the most relevant questions around every product you're working on. Remote workers are brought in via video conference. Now, I realize that this can be done electronically, but walls are public and accessible while electronic is hidden until you go looking for it.
When I see empty walls in an IT building I immediately know that daily standup meetings are likely not happening.
Our budgeting process in healthcare is not conducive to Agile. Budgeting typically starts six months before the start of the fiscal year, and budgets are finalized at least 30 days prior to the start of that year.
Now, let's imagine that your user community comes up with an idea mid-year that is 1,000 times better, but will take a budget adjustment of $150,000. In most organizations, this will kick off a process that will take months to get approval.
Each budget adjustment is a significant roadblock to agility and progress. The scale of this change is dramatic to demonstrate the point, but having some sort of flexible budgeting process is essential to fostering agile progress.
Applications, Not Platforms
Health IT often gets blamed for what is actually a decade's worth of unintended consequences, stemming from policy decisions at the federal and state level. I'm a firm believer that without Meaningful Use (MU), healthcare would still be on paper. Kudos for digitizing the medical record.
One of the unintended consequence of MU was that the EHR providers were given a significant amount of power and sway over the industry. A new set of benevolent masters. These systems cost hundreds of millions (and even into the billions!) to install, and will cost the same to replace. There is no real threat of replacement and therefore no real market threat to the major EHR providers.
With no real market threat, the EHR providers do not have to be responsive to the end user community. This leaves only one threat to their hold on healthcare: the federal government.
Sorry for that tangent, but it's important to understand why Agile does not thrive in healthcare.
Why Platforms Should Be Standard
Platforms are one of the hallmarks of agility. Platforms allow for the free flow of information over secure channels. They allow for mass customization through programmatic access via APIs, and non-programmatic through configuration and visual workflow tools.
Platforms allow for granular accounting, so the end user only pays for the amount of a product they use. Platforms allow for device agnostic access anywhere in the world. I'm writing this article on a platform right now with my office computer, but I could just as easily do it from my smartphone or from my laptop at 30,000ft in the air.
EHRs were designed as a series of applications that have been stitched together over time. They have a few characteristics of a platform, but they are NOT platforms.
If the EHR were a platform, every change to the system would not such be a major undertaking. We would be able to handle thousands of modifications a year without changing the underlying structure of the data. We would have highly-customized interfaces for each specialist, which provide only the data that's relevant to their practice.
These things are possible. However, in the non-platform world they typically take months, require programmers, and the cost is an order of magnitude higher. The result is less clinician satisfaction and one of the only industries where mass digitization of processes lead to productivity decline.
There are ways around this major roadblock to agile, but that will have to wait for another article.
Pace of change
Finally, if we had no other indicator than the pace at which change happens in Health IT, we would know enough to realize that Agile is not the predominant framework being practiced. Incremental improvements happen daily in an agile world.
I sat down with a CIO who practices Agile outside of healthcare, and they developed their own ERP solution. This was startling to me. Their brand is well-known, and their revenue places them at the top of their industry.
"Why would you ever do such a thing?" I asked. Competitive advantage was his answer.
They do hundreds of releases to production a week, with tiny incremental improvements that make a meaningful difference to the results of their business. Daily incremental improvements would have a significant impact on healthcare outcomes.
The next post will cover ways we can implement Agile in Health IT.