When Choosing Agile or Waterfall Development for Healthcare, Take a Pragmatic Approach

Agile in healthcareIt may not quite reach the epic rivalry proportions of Pepsi vs. Coke, the iPhone vs. Android, or even Chevy vs. Ford, but if you want to watch a group of developers (healthcare or otherwise) get intense, just bring up the topic of Waterfall vs. Agile development. Each side has its ardent advocates and evangelists, and as a rule they rarely, if ever, cross the aisle.

At Health Catalyst, we often find ourselves caught up in the same debate. A quick review of our Knowledge Center would have you believe that we want everyone to become Agile in healthcare. It’s what we talk about and promote the most, and for much of what we do for our clients, it is the superior choice. It also has the advantage of being the latest iteration, designed specifically to overcome issues in the Waterfall development that preceded it. Everyone loves the latest and greatest.

But like many things in life, it’s actually a little more complicated than that. The reality is Waterfall versus Agile isn’t an either/or, all-in choice. Both development methodologies have their benefits and drawbacks. What’s important is understanding the circumstances under which each works best and then applying the methodology that is most appropriate for the job at hand. In other words, understand the principles and be pragmatic in their application.

Churning Through the Whitewater of Waterfall

Waterfall works very well when there is a clear vision and understanding of what the end product should look like. It’s particularly well suited to projects where the organization follows a known path, and there is little need for variation or creative deviation from the plan. Perhaps it is in the implementation of a set of tasks that have been performed many times before. In these instances, there should be a solid understanding of what the dependencies are and what is needed to get from point A to point B.

Waterfall development is also valuable when the tolerance for imperfection is very low. In other words, it may be the preferred method when the benefit of risk mitigation justifies the cost of extensive upfront planning. In many ways it’s like performing surgery. If there ever was a time to measure twice and cut once, that would be it. It would not be practical to test hypotheses and iterate toward the ideal when someone’s life is hanging in the balance. You want to walk in the room already knowing exactly what you’ll be doing every step of the way to produce the desired outcome. The benefit of avoiding patient injury is clearly worth the upfront cost of planning with very prescriptive tasks and to-dos.

A great example of where this works well with the work we do at Health Catalyst is in the implementation of a Late-Binding™ enterprise data warehouse (EDW) for a healthcare organization. We have years of experience and a wealth of knowledge about what steps are needed to establish a robust and well-performing data warehouse. We understand the prerequisites, the key dependencies, and the desired end state. While there may be some minor adjustments, essentially the EDW is deployed using the same recommended hardware and software. It requires the same types of people, input, and expertise. If there is a problem, we have an existing checklist that will most likely contain the fix. There isn’t a lot of room—or need—for variation.

Once the EDW is installed, a core set of capabilities are available to an organization to maximize the value of the data assets in driving outcomes improvement. At this phase of our typical engagement, we are generally helping interdisciplinary teams of clinicians and technicians develop analytic solutions to create standards and best practices. In this scenario, the institution knows generally what the outcomes should be, but the pathway to get there is unknown. Thus, analytic solutions are best derived from an environment of iterative learning, which leads to early and frequent value. But Waterfall development requires that all contingencies be considered prior to beginning subsequent phases, so it is ill-suited for this type of work. In fact, it punishes deviations from the plan rather than rewarding them as an opportunity for learning. Additionally, Waterfall is heavy on documentation and planning, and can take a long time before the final product is created and the organization starts realizing value.

If it turns out that the conditions the organization planned for have changed, Waterfall development doesn’t allow the organization to go back and redefine the scope on the fly. The result is large-scale rework that creates delays and drives up costs.

Think of attempting to develop an analytics application to improve throughput in the emergency department (ED). No matter how hard the team works up front to determine all the steps that will be required, there will always be variances. One new regulation or software tool alone could disrupt the entire workflow. Waterfall methodologies, in this case, will likely lead to frustration and failure.

Getting Agile

Situations like the one described in the previous paragraph are why Agile methodologies were created. With Agile, the organization doesn’t need to know everything about everything up front. It just needs to have a general idea of where it wants to go and how it wants to get there. Some skeptics may argue that, with the Agile methodology, you’re starting the work before you even know what you are trying to solve. And some business intelligence groups believe that they can anticipate and plan the design specifications before they are even requested. Let it be known, that if clairvoyance is your strength, then definitely map out the design specs from beginning to end and deliver a nice, pristine, finished product in one fell swoop (but you probably knew I would say that). While there may be the rare circumstance where this is feasible, as mentioned earlier, most development initiatives occur with the only the next few steps illuminated on the path. Additionally, one unanticipated, but far more substantial, consequence of this thinking is that it completely underestimates the importance of front-line involvement in the successful adoption of the end product. When the intended users of the tool are engaged in the process of developing the tool, they are much more likely to own and defend it. Therefore, even if you could anticipate the design specs, it is far more effective to have those who are closest to the problem—business owners and end users, rather than just developers and project managers—provide constant feedback in iterative cycles to ensure that value is delivered frequently and on target. This methodology enables an organization to hypothesize solutions, develop them, test them, make adjustments, and continue forward in an iterative manner until it achieves the desired outcome of improvement rather than a misdirected desire for simply more products.

If the requirements change, or the organization decides to go in a different direction, development can quickly pivot to accommodate those factors. While all of this is occurring, users have applications in their hands that can start delivering immediate value rather than having to wait for the ultimate finished product to be created.

Here’s a good way to think of it. One of my coworkers was preparing to lead a group of young men, ages 14-18, on a five-day, fifty-mile wilderness adventure on the Appalachian Trail. In the planning process, he determined it would not be very effective to hold a series of meetings to discuss everything they would need to pack, and then send them on the trail for five days.

Instead, he would hold a meeting, discuss what was needed and then take the boys on an overnight camping trip. Afterward, they would meet again to discuss what they forgot as well as what they brought, but didn’t use. He did a series of these short meeting/trip combinations over the next four weeks. By the time they went on the long trip they knew from experience how to be prepared and be self-sufficient. Despite not knowing everything they needed to know in the beginning, the trip down the Appalachian Trail was a huge success and they attribute this success to the short preparatory camps where 1) they had a great time (quick time to value) and 2) valuable lessons were learned to move them in the direction of the ultimate experience on the trail (agile pivoting).

This sort of agility is important in any form of business intelligence. But in the rapidly-changing world of healthcare, where new discoveries are being made and introduced every day, and regulations are constantly shifting, it is absolutely critical. Most healthcare organizations don’t know what problems they’re going to have to solve when they begin a clinical, financial, or other improvement project. Rather than guessing, often the best approach is to use the technology to discover what problems are out there, and then develop specific solutions to address them.

While the perceived relative ease and the actual speed to value of Agile are attractive, it is not a panacea. One of the most common misperceptions is that Agile development doesn’t require documentation or advanced planning. That is simply not true. In fact, Alistair Cockburn, signer of the Agile Manifesto, has shared that the creators of the Manifesto did not want people to think that documentation in and of itself was unnecessary because they did believe it was important. Their intent was to call out exhaustive documentation as overkill. Regardless of the methodology, there must be a plan. But, instead of requiring comprehensive, up-front documentation and planning and then clinging tenaciously to the plan, the Agile methodology calls for documentation and planning in each iterative step to allow pivoting for customer success.

Quality control and all the other rigors of development must also be included if Agile is being applied properly. The difference is they occur in daily standups and two-week sprints focused on one small area, rather than being one massive, marathon development project. In a sense, the Agile development methodology incorporates the exact same steps and elements of the Waterfall methodology, it just applies them in small bite-size chunks.

Blending the Two Development Styles

In Health Catalyst’s experience, the best solution to a healthcare organization’s issues requires a blending of the two methodologies. We will use Waterfall to ensure rapid implementation of the EDW to aggregate data from all the disparate systems within the organization and create a single source of truth from which the analytics applications can draw.

We will then use Agile methodologies to create the analytics themselves. Going that route provides the flexibility and speed to value to help healthcare organizations use the data they have to begin making meaningful improvements quickly.

Replace “Sides” with Pragmatism

Clearly, what’s called for is a change in thinking. Rather than continuing the Holy War over which methodology works best, or being tied to any particular dogma, we believe pragmatism should rule the day. Rather than choosing sides and drawing lines in the sand, consider the objectives and the scenario at hand and take a pragmatic approach. At the end of the day, who cares what you call it as long as it is results driven and grounded in correct principles. Stop, think, and apply the right tools for the job.

By having both Waterfall and Agile available to them, organizations can take a best practices approach to everything they do and select the methodology that’s most appropriate for the challenge they’re facing.

PowerPoint Slides

Would you like to use or share these concepts?  Download this presentation highlighting the key main points.

Click Here to Download the Slides


Loading next article...