Agile vs. Waterfall (Part 5 of 5). Which method is then better?Digital Project Management
Welcome back to part 5 of Agile vs. Waterfall, this is the last part in the series. Our first part introduced the Waterfall model, our second part introduced the agile Scrum model and our third part described the relationship between cost, functionality and time. The fourth part made a direct comparison of the two approaches and suggested when to choose which. In this last part I will give our insights into what model works better and how to combine the best of both worlds.
If you have not read part 1 it can be found here.
If you have not read part 2 it can be found here.
If you have not read part 3 it can be found here.
If you have not read part 4 it can be found here.
No more doodling about, let’s get to the conclusion!
Which method is then better?
As agile has become increasingly popular and organizations all over the world are scrambling to adopt this paradigm, mainly in the form of Scrum, there have also been realizations where using agile has proven to make the projects more expensive/take longer/have less features than if a sequential model like Waterfall had been chosen.
When it comes down to it, neither the agile Scrum method nor the Waterfall method is inherently better than the other. That being said, each method does have its merits. Waterfall tends to be best for projects where it is not likely that many changes will be made throughout the development process or projects that cannot afford mistakes. Scrum tends to be a better option for smaller projects where changes are either rapid or likely to be made during the design process or with projects that can be modularized.
In Scrum, scope creep is not a problem because it is all about getting functionality out the door, in the right order, based on business needs. But in practice, Scrum can become disjointed and directionless, an excuse for absence of internal processes and organizational chaos. Scrum is often assumed to not need a strategic view, which is a complete and utter misconception.
If project teams are located across sites and timezones, coordination of work needs to be relatively detailed to avoid confusion and wasted time. In this instance Waterfall is likely to be the most appropriate method, offering clear deliverables and project milestones and dependencies.
When projects require unique specialist skills and these resources are not immediately available, good planning is required. If this is costly or difficult to organize, it’s important to ensure that the resource is fully utilised during its scheduled usage. For this Waterfall is a better approach, as planning is much more reliable, to ensure maximum efficiency of use.
While each model has its strengths and shortcomings, misconceptions reign over both. It is either disorganization due to a lack of discipline or unnecessary complexity rooted in an irrational belief that one can eliminate risk. Efficient and mature enterprises understand when to apply each of these methods. In practice, organizations with successful development cycles appear to employ a hybrid approach, taking a little bit from each methodology.
The best of both worlds
The hybrid approach could be conceived as a Waterfall type analysis and design, initially, but then switching to Scrum as production method. It gives you an overview of the complete project, but allows development with constant feedback based on the requirements of the users. It allows team to gain insight into the large picture with up front analysis and design while permitting incremental changes during the development and implementation phases. The team can deliver complete, but focused functionality which comprises a small part of the whole. This will keep the business engaged and responsive, while at the same time ensuring that the BA and tester team(s) have a better feeling with the progress of the project as well. This ensures that proper planning can be done and realistic estimates set for the entire project.
Adoption of an overall architecture approach to minimize requirement gaps and to eliminate solution gaps is required. Solution workshops are to be conducted with all stakeholders e.g. business, marketing, IT, to ensure congruence in the actual requirements and final solution.
Change control and risk has to be strictly enforced, in order to control and manage scope creep. Major changes changes have to be taken to a review board with key stakeholders, especially for large or transformational projects.
And finally, executive sponsorship has to be strong for all but the smallest projects to succeed!
Really, when it comes to choosing a method there is not a right or wrong choice. You just need to understand which method is better suited to your project and your needs, being it Waterfall, Scrum or the hybrid approach.
Different situations obviously call for different approaches. But one thing that is for certain is that using either methodology vastly will increase success compared to not following a process at all or just going ad-hoc.
This was the final part in the Agile vs. Waterfall (5 part) series. I hope it has shed some light, been useful and informative for you to read.
After reading this series you should now have an sound and objective opinion on both models (pros and cons) and not let yourself sway by "experts" biased to either side, which often can muddle the picture a great deal. As you can see Waterfall is not all bad and Scrum is not all good. We, at Forecast.it, are proponents of all three models depending on what you want to achieve.
Photo by The Chef!