Agile Versus Waterfall For eCommerce Web Design & Software Development
Having built many websites and software projects in my career, I have seen both waterfall and agile project management in various forms. At a high level, I think there are advantages to both methods and understanding them might help you decide which way to manage your project.
However, in the real world, you will likely end up in some sort of hybrid model. Personally I think a hybrid is great, but figuring out which way you might lean in terms of focusing more on agile versus more on waterfall will help you set clear goals for managing the project.
Waterfall project management was the original process of managing projects. In the past, it was important to get all the requirements upfront then build the entire application because it was not easy to execute or see iterative changes. The concept behind waterfall is that you get all the details ironed out upfront and then like a waterfall you execute on them all at once. This is opposed to agile which would be to do some work before the entire scope is finalized in an iterative manner.
Agile project management came around in popularity as software and the web evolved. With modern web browsers and coding languages its possible to quickly launch new features and improvements to the software in weeks, not months or years. Therefore it started to make more sense to many companies to move in an agile fashion and quickly add new features based on customer feedback or theories to test the market more quickly.
Traditionally agile has been built around the idea of using project management software to breakdown a project into two-week sprints and execute on a new launch or set of tasks every two weeks.
Which Is Better?
I think it’s unfair to say that one is better than the other. However, I personally think that companies that are stuck more in the waterfall mindset will fall behind and not be competitive in the future.
My personal feeling is that using a hybrid approach is best, but moving towards a more agile execution style is ideal. So, in other words, spending time up front in a waterfall fashion to generate as much high-level requirements and then moving forward on any clear cut actionable tasks in a first sprint (agile) to make progress will move you forward the fastest.
For instance, if you know you need to transfer your data to a new eCommerce platform you could do this immediately and start this task before the design is complete. The goal of agile should be to move faster and identify risks sooner. Companies stuck in waterfall assume it mitigates risk when I would actually argue that spending a bit of time on the key tasks to better understand them is actually a better way to mitigate risk.
What’s Stopping Agile?
The key problem stopping companies from going more agile in my opinion is budgeting constraints. Companies are stuck in an I have x budget for this project as if they are building a house. eCommerce is much more like building an on going house that is never complete and must adapt to market demands.
I would recommend that companies move to an x budget per month mindset to tackle x things. Of course this can be problematic for a few reasons, such as projects can drag on too long and they can go over budget by dragging on. My recommendation would be to try and budget a slightly higher amount for months with bigger projects and work closely with the execution team to ensure that the project is on track on a weekly / monthly basis.
It should be fairly obvious on an agile basis if the project is slipping behind if there is some upfront waterfall requirements gathering. You can also decide to launch an MVP approach and move features to post-launch as needed.
In conclusion, I think the biggest problem companies face is that they don’t understand their requirements well for eCommerce but yet want a defined waterfall-like project. If you want to do waterfall you really need to have very detailed requirements or you might as well go agile and adjust as you tackle certain tasks. Also by trying to do waterfall without super defined requirements, you are slowing down a process that could be done much faster via agile.