Agile software deployments are becoming very popular in the digital transformation space. They are meant to be a significant improvement over traditional waterfall deployments. But what exactly is the difference between agile and waterfall, and more importantly, how do you determine which path is right for you? That's what we want to talk about here today.
We find that, more often than not, software vendors lead with an agile mindset or an agile implementation mindset. Most software vendors now have agile components and philosophies incorporated into their proposals and implementation plans, as do the system integrators and technical implementers of the world. However, the software deployment industry is built on a concept called waterfall. But the question we often get is, what's the difference between the two? Do we really need or want agile or waterfall? Or is there some sort of hybrid that might make sense for us? So, today, we want to talk about the difference between agile and waterfall and ultimately help you understand which path is right for you depending on your goals and objectives.
To help understand the difference, I'm going to dive into what waterfall is first. Waterfall is a methodology that historically and traditionally was used almost exclusively as a way to deploy new technologies until recently. Essentially, waterfall is a sequential series of steps that require you to get entirely through a phase of a project and get sign-off and approval before you move on to the next phase.
Software vendors often start with a phase called requirements gathering, where they understand the client's business needs and what needs to be built into the software. Then, you would have the design of the software, the build phase, the test phase, and ultimately your go-live phase. The difference between waterfall and agile is that we're not moving past any one of these phases until we've finished the first phase.
For example, if you're going through a global ERP or enterprise technology rollout, you're going to define your global requirements and how you're going to change your business and what you want that future state to look like before you ever start designing and building and testing software and then ultimately going live.
This has been one of the problems with waterfall and why waterfall has such a bad wrap today because organizations oftentimes got stuck in one or more of these phases. For example, requirements gathering for a global complex organization could sometimes take several months or over a year just to define your requirements, and you end up spending a lot of time and money here before you ever get any sort of value out of the investment in the technology.
What agile does is it tries to attack that vulnerability and give us an alternative to that problem or that situation. So ultimately, you will finish your requirements definition, then you lock down your requirements gathering, and once you've done that, you've gotten sign-off and approvals and moved on through the stage gate.
Then you move on to the next phase, where you start designing the software, sign off on design, go through the stage gate review here, then you start building the software, same thing, stage gate before you move on. Then you move on to the test stage gate, where you make sure you've tested everything, done user acceptance testing, all that stuff, and then you go live.
As you can see, if we have disruptions along the way, it pushes everything out because everything's sequential, and that's intentional. It was meant to create software that's standardized, well thought out, well-designed, and all that good stuff. However, with failure rates of over 80 percent, enterprise technology and digital transformations needed an alternate answer to address some of the problems that were being experienced by waterfall deployments.
Next, I'll talk about how agile is different from waterfall.
So, this brings us to Agile. Agile is a different approach, and what I'm going to do is just whiteboard and sketch out how Agile looks different.
To recap, waterfall requires that we go through each of these phases sequentially before we ever get to testing and going live with new technology. Agile, on the other hand, seeks to compress these timelines into a series of sprints that are meant to get technology out to be tested and used by end users as quickly as possible. Then, we can get feedback from those end users to come back and pivot and adjust our deployment and learn from those mistakes and lessons that went well along the way.
Instead of having sequential steps like this, you would have more sprint-based approaches. So, it's a series of sprints that would still go through these different things, but you're doing it a lot faster and in more bite-sized chunks. That's an important piece of it too, as they're smaller bite-sized chunks of work.
The key here is really to get technology into the end user's hands as quickly as possible so they can start using the software. And if there are adjustments that need to be made or problems with the way it's deployed, there's a feedback loop back to the project team to then make adjustments, learn from that, and then move on to the later stages.
The key here is fast tech deployment, trying to get technology out as quickly as we can. Now, in theory, this sounds great. It sounds like this is probably going to solve the problem we had up here, which is high dollars, high time, and delayed ROI. Some of the challenges with waterfall take a lot of time and a lot of money before you ever get business value. So, Agile comes along, and this whole movement comes along and says, "Hey, you don't need to do this. We'll come out and provide a methodology that allows you to do sprints, and you can have business value right away or very quickly, a lot less than it might take to go through an entire sequential process like this."
That is true to some degree, but what we found is that a lot of organizations miss out on the value of waterfall by going too far down the path of Agile. Let me explain what I mean by this. When you have an Agile deployment, you're not spending the time upfront to define your requirements enterprise-wide in a great amount of detail. You might focus on a small subset of your requirements, build and test the software quickly, and get it out in the hands of end users to get their feedback. But you're not doing it all for the entire organization across the entire enterprise.
Generally speaking, the problem with using a waterfall approach, as good as it may sound on the surface, is that if you are a global organization trying to standardize business processes and be deliberate about your future operating model, you may end up overlooking important details in the name of being agile and getting technology out quickly. This constant race to deploy new technology without having a clear overarching strategy can make it difficult to act like one company, which is why many organizations undergo digital transformations in the first place. While agile can help resolve certain problems that waterfall cannot, it also creates a new subset of problems. Therefore, agile is not a silver bullet that can fix all your problems, and there are risks associated with both agile and waterfall deployments, such as high costs and delayed ROI. The best approach is often a hybrid model, where you take a waterfall approach to requirements and take the time upfront to ensure you have a clear vision, but then shift into an agile mindset when it comes time to design, build, and test. Breaking the technology stack into smaller chunks and incrementally deploying technology can help you leverage the best of both worlds and balance the pros and cons of each approach, although this does not mitigate all the risks.
The question is: which is better - agile, waterfall, or some sort of hybrid? The answer I often give to many different questions is, "It depends." It depends on what you're trying to accomplish as an organization, who you are now as an organization, and where you're headed with your digital transformation. I'll give you two examples. If you're a large global organization that has grown through acquisition or organically, with disparate operations throughout the world, and you're trying to use your digital transformation as a way to consolidate and standardize your business processes to start acting and functioning like one company to give you the scale you need to continue to grow, then a waterfall approach or leaning more towards the waterfall approach can actually help you in that regard. Now, you do have to manage risks with higher investments and time and money up front, but there is definite value in these cases in leaning towards a waterfall approach.
On the other hand, if you're a younger, smaller, more nimble organization - maybe it's entrepreneurial, high growth, and you're moving very quickly - you haven't been around for a long time, so you don't have a lot of baggage or a lot of disparate ways of doing business. Then a more agile approach is probably going to make a lot of sense. If you're entrepreneurial, moving fast, this fits your culture, your model, and your profile and tolerance for risk. It just matches the overall pace that you move as an organization.
And then of course, there's that in-between middle ground that ends up applying to a lot of organizations. But the key here is to think of this as a sort of a spectrum. You've got two extremes - fully agile deployment methodologies and fully waterfall - and then there are some hybrids in the middle. So the key is to figure out who you are as an organization, which one best aligns with your needs, and ultimately no matter what path you choose, you just need to make sure you've got strong program management and project governance, as well as risk management and risk mitigation mechanisms in place to make sure that you've managed the downside risk of whichever path you choose.
So now the question becomes, how do we incorporate this concept in this decision process into our digital strategy? First and foremost, I would say before you ever start contacting software vendors and system integrators, I would challenge you to figure out where you think you fall on the spectrum. The reason I say that is that if you go to system integrators and software vendors, chances are fairly high that you're going to get a very biased view of agile-centric methodologies. I'm not saying there's anything wrong with agile, but it's not a one-size-fits-all answer, even though software vendors and system integrators are treating it as a one-size-fits-all answer, largely because it's a great marketing message for software vendors to be able to say that we take an agile approach. We're nimble. We're flexible. We're going to fix these problems here of time, cost, and delayed ROI. You're going to get immediate business value. But again, we're creating a set of problems that organizations realize as they get into agile deployment. So you just want to make sure you know up front what direction you want to go and then ultimately recognize that you're the customer, you're the company that has to live with whatever deployment happens within your organization. So you want to make sure you have the right digital strategy and overall methodology that fits your business, who you are today, and where you're headed in the future.
If you are looking to strategize an upcoming transformation or are looking at selecting an ERP system, we would love to give you some insights. Please contact me for more information eric.kimberling@thirdstage-consulting.com