Realistic Waterfall to Agile: "Evolution, not Revolution"

Realistic Waterfall to Agile:

We can all imagine it. The idyllic depiction of a pristine SDLC environment with well-oiled processes and teams, built by a smooth and efficient transition of methodologies and tools, supported by immediate and sustained ROI. One where business, quality, IT and validation teams all work together in harmony. It sounds great, doesn’t it?

While I do believe that this concept is attainable, the version of the scene depicted above is generally one created of an ideal, marketing-based scenario of the perfect implementation yielding perfect results. However, this may not be the case for many organizations, nor is it a one-size-fits-all solution.

The reality is that there are a lot of variables in real life and certainly so when it comes to shifting from waterfall-based tools and methodologies to those that are agile-based in a regulated environment. Rarely does that full, picturesque transition occur across the enterprise over a single rollout, and, for many teams, arriving at a pure-agile endpoint is not necessarily a required or even a desired state.

Let’s ignore, for a moment, the marketing drafted, whitepaper-based roadmap narrative filled with simplified adoption messaging, and favorable metrics. You know, the one that is littered with pictures of pristine forest trails and mountain passes that lead to stunning vistas. Instead, let’s just take a look at what a realistic “waterfall to agile” transformation can or should look like for most teams operating under FDA requirements. 

The truth is, the execution of a waterfall to agile transformation is not always as simple as a white paper lays out and that a white paper roadmap followed in its entirety isn’t necessarily for every organization, but that’s ok. They are more meant to be a general guidance document describing what’s possible and the associated benefits at a high level, but organizations still need to dive deeper on their own to take into account their own business requirements, objectives, and strategy.

While a full agile endpoint may not be the ultimate goal of every organization, there are, at the very least, pieces of that transformation that would benefit any team working in software development, software quality, testing, and validation - which in turn will have a very positive impact on Business and IT teams.

When looking at a waterfall to agile transition for many organizations, I sometimes think of it more in terms of a Porsche motto I once heard, “evolution, not revolution”. Technology changes, technology improves, and competition improves. This all has to be taken into account and incorporated effectively in order to stay not only relevant but at the top. 

Did Porsche feel they needed to re-tool their 911 platform from the ground up and come out with a drastic new redesign with every model refresh? Of course not. And why would they? Much of what they had in place worked well from a performance, mechanical, and aesthetic standpoint, but that doesn’t mean they didn’t recognize the need for improvement.

They keep what works, but push forward by implementing new technology enhancements to increase speed, tighten up handling, and improve braking. They reshape the lines of the body just enough. They use the best of what’s new and better to improve upon the previous generation. They understand that you can’t stay stuck in time, but also that a complete overhaul is costly and potentially fraught with risk if the execution does not match the vision. Instead, keep the vision in the realm of what is working, and evolve it appropriately.

Okay, that’s enough of the car analogy since I’m not really even a car guy (which I’ve probably exposed through my half-baked metaphor). The point is, teams do not necessarily need to try to undertake a full revolution of current processes and methodologies. A full waterfall to agile transformation might not make sense in all areas of the SDLC. The reality is that in some areas, what is in place may work just fine, but there are also areas that could certainly use improvement.

Evaluate those areas. Look to see where modern tools might enhance how things are currently being done. Find what aspects of modern methodologies can be adopted to make processes more efficient, or where they can help reduce risk. Hell, maybe there are some areas where a full agile adoption makes sense. If that’s the case, then, by all means, that is what should be planned and achieved.

For many teams, landing in a somewhat hybrid framework is what is going to make the most sense. Keeping what works and taking the new to replace the outdated in an effective and pragmatic fashion is a recipe that conforms much more nicely with the practical, real-world scenario of most teams operating in a regulated environment. 

We will soon be coming out with some additional content on this theme (most likely minus the car analogy), so stay tuned for some new collateral where we will dive a little deeper on various aspects of modernization in a regulated environment.

In the meantime, here’s a great piece of supporting collateral. Abbvie’s/Allergan’s Executive Director of IT Systems Assurance and Compliance, Raechell Raimondo, and Tx3’s own CEO, Jason Tepfenhardt recently presented a webinar on “Standardizing Compliance to Achieve SDLC Modernization”, and I would highly recommend taking some time to view it when you are able.



Share to: