Agile or Waterfall...which is right for you?
ROBERT SIEGER
Transformative CIO | ERP & Cloud SaaS Expert | Team Builder | Innovation & Change Driver | ???????????????????????? teams into ???????? ???????????????????? with ?????????????? ????????????????????
I have been asked this question a lot: What is the difference between the Waterfall Methodology of development and the Agile Methodology of development? Both have the advantages as well as disadvantages, so it is important to understand (basically) how each works and at the end of the day, the best method really is based on the needs of the business.
So first, let’s discuss just what is the Waterfall Methodology of Development?
The Waterfall Methodology is a sequential design process, think in terms of automobile manufacturing. The building of an auto happens in a very precise and set sequence, you cannot install the exterior doors without the interior completed. The Waterfall Methodology has eight stages:
- Conception
- Initiation
- Analysis
- Design
- Construction/Development
- Testing
- Implementation
- Maintenance
As this method is sequential the developers can’t go move on until the step is completed, subsequently, they cannot go back to a previous step – not without dumping the entire project and starting from the beginning. With the Waterfall Method, there is no room for error or change, so every step must be thought out completely and then every step must be meticulously performed.
What are the advantages of the Waterfall Methodology?
- The Waterfall Methodology stresses documentation, detailed documentation on each and everything done. Detailed documentation allows for future development as well as a clear upgrade path. It also helps with the technical documentation as the development team evolves.
- With the Waterfall Methodology, the business process owners, the clients, the end users know what to expect. The size, cost, timeline and expectations have been set in great detail. Before the project even begins they understand and know what the program will do.
What are the disadvantages of the Waterfall Methodology?
- Once a step has been completed, developers can’t go back to a previous stage and make changes. They have to move forward. This means if the business process owners/users decide to change what is required, they either have to start over or live with what was scoped.
- The Waterfall Methodology is dependent on the initial requirements. If the requirements change, or worse still, if they were not captured correctly, the project will fail.
- With the Waterfall Methodology the developed application is not tested until the end, so if the earliest written code has bugs, it may impact code that was written later, potentially creating a technical slew of fixes later.
- The Waterfall Method does NOT take into account the evolution of a business, the business model as well as the business process. A business process owner will ALWAYS realize they need something more or different, this will ultimately impact the cost, schedule and finish time of a project.
When should you use Waterfall Methodology?
- Only when there is a clear, set in stone picture of what the final solution should be.
- Only when the business process owners are required to NOT change the requirements once they have been scoped out.
- Only when the defined project is more important than the speed to get it done. Definition/Scope is everything
So, now what is the Agile Methodology?
The Agile Methodology was developed as an answer to the disadvantages of the Waterfall Methodology. Rather than following a strict sequential process, the Agile Methodology follows an incremental approach to development, developing in ‘Sprints’.
The Business Process Owners AND the Developers start off with a very simple project design, and while it may be simple, the entire team knows what the ultimate end goal it. The Developers begin to work on small modules within the project; the work on these modules is done in weekly or monthly ‘Sprints’ and at the end of each ‘Sprint’, the project is evaluated with the Business Process Owners as well as tested. This allows for the evolution of the business process, changes in the business process as well as capturing any ‘Ah-Ha’ moments generated by experiencing the development. Since development is done in ‘Sprints’, changes and bug fixes are relatively painless in the sense impact is minimal.
With the Agile Methodology the temptation can be to ignore the initial design. I want to stress here that while it is not sequential in nature, having an initial design will help the process along. The biggest benefit is the collaborative nature of the Agile Method, the Business Process Owners are committed as well as involved, and they have a stake in the game.
What are the advantages of the Agile Methodology?
- The Agile Methodology is flexible and allows for changes to be made after the initial planning. Changes to the business process, the evolution of the business and those pesky ‘Ah-Ha’ moments are expected.
- Changes are expected, so it is easier to add or modify features or processes. Additionally, the Agile Methodology will help you keep up with changes within the particular industry you are working.
- Since you are working as a team with the Business Process Owners, you are getting feedback at the end of each ‘Sprint’ and the Business Process Owners will ultimately get the product they envision/want. Additionally, testing at the end of each ‘Sprint’ (UAT and otherwise), bugs are caught and fixed immediately rather than later.
Yeah – yeah, so what are the disadvantages of the Agile Methodology?
- With a weak Project Manager, the ‘Sprints’ can become a series of changes and business process modifications. This will lead to cost overruns as well as the project coming in seriously late.
- If you don’t take the time to define the initial plan, the final product may be vastly different than what was imagined.
When should you use the Agile Methodology?
- When speed is more important than definition and when the Business Process is influx or evolving.
- When the Business Process Owner is simply unsure of what the final outcome should be or if they are hoping to clean up their business process with an application thus assuming many changes.
- When you have a strong Project Manager who can push back to the Business Process Owners and strong developers who have a keen business sense and can make assumptions during the development process.
Both methods have the strengths and weaknesses. What it really comes down to is the needs of the Business over the needs of technology. Remember, the needs of the business must always drive technology and not the other way around. If you are working in a business that has had the same business process for years and is not apt to change, the Waterfall Methodology would probably work well. If you are in a business that is screaming for change or is evolving, the Agile Methodology is probably going to work well. At the end of the day, the business will drive it.
Business Operations Excellence & AI-Ready: Transforming Organizations from Data-Driven to Knowledge-Powered with Knowledge Graphs, Analytics, and Decision Intelligence
8 å¹´Thank you Robert :) Yes, every project needs its own approach and it's important to discuss pluses and minuses for different cases. About Waterfall: it's not frozen approach, it's changed a lot and adopted to new reality in development. So now it's actually Iterative Waterfall with feedback loops, iterations and different length of each phase depend of iteration. For me right waterfall diagram looks more like this https://ow.ly/RNbi3020FTY.
Chief Information Officer
8 年Websites, blogs, social networks are full of people disserting for years about this subject. I always see the same exaggerations depending whether the writer is a pro or con of Agile or Waterfall. But the rate of failed projects shows no change over ages. There is certainly a lot in each approach to be implemented depending on the team, the company’s culture, the nature of the project, the level of risks, your own feeling of what you are comfortable to work with, etc… Instead of thinking like a Project Manager, try to put your feet in the CEO’s shoes. The CEO wants Directors to improve the company’s overall situation toward strategy. Then, each project has to deliver a determined business value against a cost and delay counterpart. A Director who wants to initiate a project has to define the business value. Then he/she has to question the IT Dept (if it is an IT project) about the cost and delay needed to deliver the product, which in turn, will deliver the desired outcome. Businesses have a tendency to overestimate the promised value (in order to gain the acceptance of the board) when IT suppliers have a tendency to underestimate the cost and delay (in order to be chosen among competitors for the realization of the project). This is why so much projects fail. When the project has been accepted and started, each change in the scope of the project is going to impact (most of the case negatively) the delivered business value. Changing the scope in due course needs to be possible (and this is the case also in the waterfall approach with variation orders and change management processes) because a mistake in the initial assumptions is in human nature. But changes in the scope have not to become the new normal. Otherwise, it looks like the Director is working without thinking enough about what he really needs to reach objectives.
CIO at City of Virginia Beach
8 å¹´Good article and explanation of the two processes. To sum up, one size does not fit all.
Senior Technology Leader | Head of PMO & Strategic Programs | Digital Transformation | Big Data & Cloud Migration | Service Management & IT Ops | BI & Analytics | Banking & Finance | PDD IESE | Ex-Barclays #AI
8 å¹´Good article. As a PM tear hace been working with both methodologies or frameworks I have to say that on top of what's been said, the key disadvantage of agile for meis the lack of personal development and appraisal of teams members. It is very difficult performing this in an environment where all members don't have hierarchycal relationships and there is low interaction with people from outside. This is currently a strong issue for large corporations using this framework. Thanks
CDC & ATSDR Accessibility (508/504) Program Director
8 å¹´Hi Robert, excellent discussion! There are a number of other considerations to throw in the mix: Waterfall can work better in a stovepiped environs, where cross-functional participation is not a given and often must be scheduled and issues resolved through meetings and negotiation. Agile is better when one business unit can drive decisionmaking. D itto for a larger governance environs: if the governance is local, agile works very well. if the governance is enterprise, getting the right people in the right room to make an informed decision on a sprint-by-sprint basis can be next to impossible, and waterfall stage gating makes sense. Finally, you point out, correctly, that waterfall is document-centric. this can be a an overlooked advantage: I've seen a number of agile development projects fail AFTER the fact, because the dearth of documentation made the system unsupportable or unable to be changed after the project completed. Your last point is the most important: the business needs and enterprise culture drives the choice, not the vendor/programming teams' preference. Again, excellent discussion!