Waterfall is famous for projects failing to deliver anything at all. Been on a few projects that, after months of analysis work, failed to even reach the coding stage.
Waterfall can work well when requirements are static and the process to fulfill them is consistent with previous projects.
Agile is about embracing change, delivering (or failing) something fast, and learning from feedback. Can't complain about about that.
Agile doesn't promise to complete faster than waterfall but incremental delivery does at least result in you devivering something.
In waterfall, you fix the requirements and keep going until completion. Choose Scrum as an alternative and you can choose fix time instead and give incremental deliveries of features in priority order until the time runs out.
Requirements can be made clear and precise if you do a thorough investigation of user's workflow before jumping on to coding the solution. In the waterfall model, the user "signs off" saying "these are my required features and functionality", so there remains little doubt about what is to be developed.
In the agile way, many times the coder may jump on to programming directly with unclear or only half understanding of what to develop. This isn't the problem of "changing requirements" but that of half-baked understanding of the project. Why do you think the Accenture's project failed recently?
Its not as if the nature of work or the user's workflow changes each day during the course of the project, what changes is the dev's understanding which improves as one gets closer to the final product. Even with the waterfall model, there are variants called "prototype" or "iterative development" models where the whole process (design, coding, testing, deployment) is repeated in multiple cycles and each developed prototype is an evolved successor of its predecessor. This used to happen since decades before agile and scrum became buzzwords.
The mystery and magic surrounding these buzzwords isn't good, they are creating an elitist attitude in certain managers who are starting to think that others are inferior to them.
The point is that development isn't agile Vs waterfall. It is about choosing the correct tool for the job.
Waterfall works well when requirements are clearly known and reasonably fixed.
Agile is about adapting your processes, learning from feedback, and accepting that requirements may change as development progresses.
Mass production of a single car model as an example can work with a waterfall style approach (but keep in mind that Kanban and some other agile concepts came from Toyota). A formula one car on the other hand would never work in waterfall.
I don't think you'd pick Agile to write a complex accountancy package. If it were done in Agile, it would be like:
User: "OK, we'll need to post to the office ledger, so code for that."
Developer:
User, later: "Right, so now we need to take care of the nominal ledders"
Developer: "So there's more than one type of ledger?"
I'd be interested in discussing that further, particularly how large-scale, multi-release features are planned in, using the example of multiple types of ledgers, perhaps. Thank you.
Looking for the humour in this.
Waterfall is famous for projects failing to deliver anything at all. Been on a few projects that, after months of analysis work, failed to even reach the coding stage.
Waterfall can work well when requirements are static and the process to fulfill them is consistent with previous projects.
Agile is about embracing change, delivering (or failing) something fast, and learning from feedback. Can't complain about about that.
Agile doesn't promise to complete faster than waterfall but incremental delivery does at least result in you devivering something.
In waterfall, you fix the requirements and keep going until completion. Choose Scrum as an alternative and you can choose fix time instead and give incremental deliveries of features in priority order until the time runs out.
beza1e1.tuxen.de/waterfall.html
Please read that link BK Lau posted. I believe the original article here made quite a few presumptions and was poorly researched unfortunately.
Good read. Thank you.
Requirements can be made clear and precise if you do a thorough investigation of user's workflow before jumping on to coding the solution. In the waterfall model, the user "signs off" saying "these are my required features and functionality", so there remains little doubt about what is to be developed.
In the agile way, many times the coder may jump on to programming directly with unclear or only half understanding of what to develop. This isn't the problem of "changing requirements" but that of half-baked understanding of the project. Why do you think the Accenture's project failed recently?
Its not as if the nature of work or the user's workflow changes each day during the course of the project, what changes is the dev's understanding which improves as one gets closer to the final product. Even with the waterfall model, there are variants called "prototype" or "iterative development" models where the whole process (design, coding, testing, deployment) is repeated in multiple cycles and each developed prototype is an evolved successor of its predecessor. This used to happen since decades before agile and scrum became buzzwords.
The mystery and magic surrounding these buzzwords isn't good, they are creating an elitist attitude in certain managers who are starting to think that others are inferior to them.
The point is that development isn't agile Vs waterfall. It is about choosing the correct tool for the job.
Waterfall works well when requirements are clearly known and reasonably fixed.
Agile is about adapting your processes, learning from feedback, and accepting that requirements may change as development progresses.
Mass production of a single car model as an example can work with a waterfall style approach (but keep in mind that Kanban and some other agile concepts came from Toyota). A formula one car on the other hand would never work in waterfall.
I don't think you'd pick Agile to write a complex accountancy package. If it were done in Agile, it would be like:
User: "OK, we'll need to post to the office ledger, so code for that."
Developer:
User, later: "Right, so now we need to take care of the nominal ledders"
Developer: "So there's more than one type of ledger?"
Funnily enough that's actually what I do and have been doing successful via some form of Agile for 15 years now, seems to work fine.
I'd be interested in discussing that further, particularly how large-scale, multi-release features are planned in, using the example of multiple types of ledgers, perhaps. Thank you.
Happy to discuss further @greigtaylor on twitter.