2 edited body
source | link

First off, the "waterfall" model was always a straw man describing how NOT to run a software development project. Look it up.

Anyhow, most "waterfall" SDLC projects entail a "Change Management" process, for when people discover that the assumptions that were written into the specifications are no longer valid (and this always happens on large complex projects). Unfortunately, the change management process is built as an exception handling measure, and is stupidly expensive, meaning the project will end up late, or of poor quality.

The idea behind Agile methodologies is that change is a given--it will happen. Therefore, you must make "change management" standard operation rather than exception handling. This isn't easy, but folks have found that if you use a lot of good design practices, you can do it.

Another major problem with front loaded design is that (most often) so much time is spent in requirements gathering and design, development and testing time suffers. Also, if testing is the last phase, and a serious problem is discovered, it is highly unlikely to get fixed within your time frame.

Perhaps one of the best features of an Agile approach is that isit demands continued interaction (that is, real communication) between the team developing the solution, and the customer who needs it. Priorities are made, so that the highest priority items are done first (and if time runs out, it's the low priority items that are cut). Feedback comes quickly.

Going beckback to the question of dramatic changes--you really need to use methods that mitigate changes. Good SOLID OO principals can play a good part of this, as can building solid automated test suites so that you can regression test your software. You should do these things regardless of your methodology, but they become truly essential if you are trying to be agile.

First off, the "waterfall" model was always a straw man describing how NOT to run a software development project. Look it up.

Anyhow, most "waterfall" SDLC projects entail a "Change Management" process, for when people discover that the assumptions that were written into the specifications are no longer valid (and this always happens on large complex projects). Unfortunately, the change management process is built as an exception handling measure, and is stupidly expensive, meaning the project will end up late, or of poor quality.

The idea behind Agile methodologies is that change is a given--it will happen. Therefore, you must make "change management" standard operation rather than exception handling. This isn't easy, but folks have found that if you use a lot of good design practices, you can do it.

Another major problem with front loaded design is that (most often) so much time is spent in requirements gathering and design, development and testing time suffers. Also, if testing is the last phase, and a serious problem is discovered, it is highly unlikely to get fixed within your time frame.

Perhaps one of the best features of an Agile approach is that is demands continued interaction (that is, real communication) between the team developing the solution, and the customer who needs it. Priorities are made, so that the highest priority items are done first (and if time runs out, it's the low priority items that are cut). Feedback comes quickly.

Going beck to the question of dramatic changes--you really need to use methods that mitigate changes. Good SOLID OO principals can play a good part of this, as can building solid automated test suites so that you can regression test your software. You should do these things regardless of your methodology, but they become truly essential if you are trying to be agile.

First off, the "waterfall" model was always a straw man describing how NOT to run a software development project. Look it up.

Anyhow, most "waterfall" SDLC projects entail a "Change Management" process, for when people discover that the assumptions that were written into the specifications are no longer valid (and this always happens on large complex projects). Unfortunately, the change management process is built as an exception handling measure, and is stupidly expensive, meaning the project will end up late, or of poor quality.

The idea behind Agile methodologies is that change is a given--it will happen. Therefore, you must make "change management" standard operation rather than exception handling. This isn't easy, but folks have found that if you use a lot of good design practices, you can do it.

Another major problem with front loaded design is that (most often) so much time is spent in requirements gathering and design, development and testing time suffers. Also, if testing is the last phase, and a serious problem is discovered, it is highly unlikely to get fixed within your time frame.

Perhaps one of the best features of an Agile approach is that it demands continued interaction (that is, real communication) between the team developing the solution, and the customer who needs it. Priorities are made, so that the highest priority items are done first (and if time runs out, it's the low priority items that are cut). Feedback comes quickly.

Going back to the question of dramatic changes--you really need to use methods that mitigate changes. Good SOLID OO principals can play a good part of this, as can building solid automated test suites so that you can regression test your software. You should do these things regardless of your methodology, but they become truly essential if you are trying to be agile.

1
source | link

First off, the "waterfall" model was always a straw man describing how NOT to run a software development project. Look it up.

Anyhow, most "waterfall" SDLC projects entail a "Change Management" process, for when people discover that the assumptions that were written into the specifications are no longer valid (and this always happens on large complex projects). Unfortunately, the change management process is built as an exception handling measure, and is stupidly expensive, meaning the project will end up late, or of poor quality.

The idea behind Agile methodologies is that change is a given--it will happen. Therefore, you must make "change management" standard operation rather than exception handling. This isn't easy, but folks have found that if you use a lot of good design practices, you can do it.

Another major problem with front loaded design is that (most often) so much time is spent in requirements gathering and design, development and testing time suffers. Also, if testing is the last phase, and a serious problem is discovered, it is highly unlikely to get fixed within your time frame.

Perhaps one of the best features of an Agile approach is that is demands continued interaction (that is, real communication) between the team developing the solution, and the customer who needs it. Priorities are made, so that the highest priority items are done first (and if time runs out, it's the low priority items that are cut). Feedback comes quickly.

Going beck to the question of dramatic changes--you really need to use methods that mitigate changes. Good SOLID OO principals can play a good part of this, as can building solid automated test suites so that you can regression test your software. You should do these things regardless of your methodology, but they become truly essential if you are trying to be agile.