One of the first decisions you need to make before starting a project implementation is: which development methodology should I use? There are different approaches to the software development process. Two of the most popular methods are Waterfall and Agile.
What is Waterfall?
Waterfall is a linear approach to software development. That means that project stages are executed sequentially, and no stage can begin before the previous one is finished. You receive your completed project, fully developed and tested, at the very end of the process.
Pros of Waterfall methodology:
- Simple and easy to understand and use
- Easy to manage due to the rigidity of the model
- Phases are processed and completed one at a time
- Works well for smaller projects where requirements are very well understood
Cons of Waterfall methodology:
- You cannot go back a step; if the design phase has gone wrong, things can get very complicated in the implementation phase
- High amounts of risk and uncertainty
- Not a good model for complex and object-oriented projects
- Poor model for long and on-going projects
- Not suitable for the projects where requirements are at a moderate to high risk of changing
What is Agile?
Agile development, as opposed to waterfall, focuses on building software iteratively. The project is divided into small modules and delivered in weekly or monthly sprints. During each sprint, a certain functional set of features is developed, tested, and delivered to you for evaluation. This approach emphasizes rapid delivery.
Pros of Agile methodology:
- Value is added every sprint
- Easier to add features that are up-to-date with the latest industry developments
- Project priorities are set before every sprint and evaluated after each sprint
- Customer feedback is allowed and will contribute to the final end product
- High level of customer involvement (strong sense of ownership)
- Short time to market: quickly produce a basic version of working software
- Transparency is high
Cons of Agile methodology:
- Projects can run longer than anticipated
- Requires high level commitment of time and energy from developers
- Expensive
What can we conclude from all this? Both methodologies have their own strengths and weaknesses. The choice of methodology really depends on the goals you want to achieve. The key to deciding which is right for you comes down to the context of the project. Is it going to be changing rapidly? If so, choose Agile. Do you know exactly what you need? Good. Then maybe Waterfall is the better option. Or better yet? Consider taking aspects of both methodologies and combining them in order to make the best possible software development process for your project.
Do you use the Waterfall or Agile methodology? Why? Have you ever tried combining the two? How did that work out? Please, tell us below.
Kate Kviatkovskaya
Business Development Manager
These are two very good methodologies which can be used in different spheres, not only IT. They help to structure the material and the whole process while working at the projects. So, thank you, Katerina, for useful promts!
I guess it is also possible for waterfall projects to run longer than anticipated.
Our survey last year shows it actually does not matter so much, choose the favorite of your team.
The simplification of the waterfall method has plagued its effective use.
If you look at the waterfall diagram above and think this is the method then you are mistaken. This diagram represents the concept of the method, not the method itself.
If you go to page 352 at
https://www.researchgate.net/publication/236170301_Cowboy_Cataloguer_Methodist_Magician_and_Master_Gestalts_of_Analysis_and_Design
you will see what is the waterfall method.
Because the misconception of the waterfall method has permeated the profession one could argue it is the method. However, just because an untruth has been repeated often does not make it true.
The use of “methodology” instead of “method”? Look it up in Wikipedia for starters. The understanding of the terms in a professional and technical sense is improved if they are not used interchangeably.
I agree with ndark, other research tends to support his point too.
The conclusion is valid, that is, do what works. I would add that it is better for analyst/designers to become masters at analysis/design than any one method.
Cheers
Waterfall for the high risky change , and it have the analysis document approved by the stakeholders ( stakeholders not available to open communication methodology) . Aglie is for low risky change and do with stakeholders who available for communication anytime
Both are actually the same, when intent of both are understood well. We at TejaSoft practice Agile Waterfall model with Weekly Iterations/Scopes. This way only at business level understanding is different but execution methodology remains same.
Hi,
I whole heartedly agree with nagkumar. Within Agile the V model is still executed but within a shorter timescale and within a smaller context. It was certainly an interesting revelation for a team I took on this journey – it’s lots of small Vs rather than one big one; ultimately the agility comes from the granularity and accepting change; not a fundamental shift to something new. To me, Agile is more akin to a risk driven incremental lifecycle which when you look at it incremental is a set of mid sized Vs!
The big challenge is getting Systems Engineers to work in the Agile context – historically SE is the big up front effort and getting the shift in mindset that actually “you don’t need to know everything before you build something” can be a challenge; but again I come back to, if you’ve worked incrementally the change is easier. I do believe in having a solution vision, a small effort to set the direction, but accepting this will change – herein comes the challenge with the Agile pure-ists!
My other main point, is the challenge Agile brings in reporting up the hierarchy within an organisation. Managers like a set of milestones and measurements against a set of estimated work packages – all this Agility cooks their heads. Getting managers trained first is really important so projects don’t end up wrestling with this. Getting a business and the customers into the mindset is as big a challenge as getting the engineers working Agile…In a product based business this is easier.
It’s a interesting discussion.
And of course, once you’ve decided on an agile approach you still need to decide what type of lifecycle to follow. The Disciplined Agile Delivery (DAD) framework supports four agile/lean lifecycles: 1. The Scrum-based Agile/Basic lifecycle; 2. The Kansan-Based Lean/Advanced lifecycle; 3. A continuous delivery lifecycle; or 4. A Lean-Startup-based Exploratory lifecycle.
when you look at waterfall projects, you will find, that no one really does it like that.
because:
– customer don’t know what they want
– developers have no idea how to build something need.
– everything changes along the way (like laws, economics etc etc, especially when it’s a large project)
We are a software consultancy and we use a hybrid approach. We think this works best for our clients, taking the best of both worlds.
@Shannon Lewis
I think that is excellent choice.
Hi Shannon, sounds interesting but what is your hybrid approach? Can you describe it in a few sentences?
In my experience it really depends on the availability of resources. Agile is great if you can get the people in a room at the same time for scheduled durations. I have found Waterfall works best if there is a disparate number of department contributing input and deliverables all with different schedules. Agile/hybrids have worked pretty good if the local people are available and there is an offshore or contracted contingent of contributors whom you as the PM doesn’t have direct control over. Part of the iteration deliverable might be to turn over tasks to such a group and a distant iteration to take delivery and continue the local work.
good insight Phillip!!!
that is very nice and well informed. A complete demonstration is given by you. One can find some more information Agile vs Waterfall Project Management