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.
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.