Mustafa Ozdeser said:

Agile methodologies, such as Scrum or Kanban, enable quick adjustments and continuous collaboration, enhancing adaptability and responsiveness. Conversely, traditional methodologies like Waterfall may hinder the team's ability to respond promptly to evolving project needs, potentially causing delays or inefficiencies.

Yes. And conversely waterfall methodologies can ensure that there is a clear structured approach which precisely meets the input requirements and doesn't go off-piste which can happen with agile / scrum. There is loads and loads to be said about this. There are no magic bullets, all solutions have advantages and disadvantages.

My particular interest is in innovation in safety critical systems, which really highlights the challenges - waterfall techniques don't promote innovation, agile / scrum don't promote assurance of safety / reliability. A few years ago I had the opportunity to do a research Master's on this issue which unfortunately concluded that actually it needed several PhD's to be done on this as the answer was both far from clear and remarkably little work had then (circa 2010) been done on it. Since then there has been some more research done, but I've yet to see clear processes / recommendations coming out of it (if anyone has I'd be delighted to know). I have my own opinions and experience, but that would take for too long to include in a forum post!

So the title of this thread would make a good basis for a conference, or several conferences, and indeed probably has...but very briefly: waterfall can cope with changing project requirements if the project team know what they are doing, oddly agile / scum can sometimes be less good in practice on this aspect (what they are very good at is responding to new possibilities in the system, which is slightly different), but again it very much depends on the expertise of the team. It can seem appealing to apply agile / scrum with the argument that it will positively impact the adaptability and responsiveness of a development team in the face of changing project requirements, but be careful that this is genuinely the reason and that it's not trying to justify the fact that the team just want to apply agile / scrum (they are much more fun than waterfall!). No techniques will solve problems unless the technique is managed in a way to make sure that it does solve those problems.

It is a good question!

Thanks,

Andy

Mustafa Ozdeser said:

Agile methodologies, such as Scrum or Kanban, enable quick adjustments and continuous collaboration, enhancing adaptability and responsiveness. Conversely, traditional methodologies like Waterfall may hinder the team's ability to respond promptly to evolving project needs, potentially causing delays or inefficiencies.

Yes. And conversely waterfall methodologies can ensure that there is a clear structured approach which precisely meets the input requirements and doesn't go off-piste which can happen with agile / scrum. There is loads and loads to be said about this. There are no magic bullets, all solutions have advantages and disadvantages.

My particular interest is in innovation in safety critical systems, which really highlights the challenges - waterfall techniques don't promote innovation, agile / scrum don't promote assurance of safety / reliability. A few years ago I had the opportunity to do a research Master's on this issue which unfortunately concluded that actually it needed several PhD's to be done on this as the answer was both far from clear and remarkably little work had then (circa 2010) been done on it. Since then there has been some more research done, but I've yet to see clear processes / recommendations coming out of it (if anyone has I'd be delighted to know). I have my own opinions and experience, but that would take for too long to include in a forum post!

So the title of this thread would make a good basis for a conference, or several conferences, and indeed probably has...but very briefly: waterfall can cope with changing project requirements if the project team know what they are doing, oddly agile / scum can sometimes be less good in practice on this aspect (what they are very good at is responding to new possibilities in the system, which is slightly different), but again it very much depends on the expertise of the team. It can seem appealing to apply agile / scrum with the argument that it will positively impact the adaptability and responsiveness of a development team in the face of changing project requirements, but be careful that this is genuinely the reason and that it's not trying to justify the fact that the team just want to apply agile / scrum (they are much more fun than waterfall!). No techniques will solve problems unless the technique is managed in a way to make sure that it does solve those problems.

It is a good question!

Thanks,

Andy