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

Hi Andy,

You have highlighted some excellent points, particularly about the trade-offs between methodologies in safety-critical systems. I agree with your observation that there are no magic bullets, every methodology has its strengths and limitations depending on the context and, importantly, the expertise of the team implementing it.

Your point about Agile/Scrum being good at responding to new possibilities in a system, but sometimes struggling with handling changing requirements, is really insightful. It’s easy to see how the flexibility and iterative nature of Agile might lead teams to focus more on possibilities than on disciplined responses to evolving needs.

The challenge you mentioned with innovation in safety-critical systems resonates deeply. Balancing the need for innovation with the assurance of safety and reliability is a complex issue. It’s fascinating (and a bit daunting) to hear that even after your research Master's and subsequent studies, the field still lacks clear processes or recommendations. It speaks to the depth of the challenge and the need for continued research.

I also appreciated your note about being cautious when choosing a methodology. Agile or Scrum can sometimes be adopted for the wrong reasons, like being “fun” or trendy, rather than as a deliberate response to project requirements. It is a great reminder that methodologies are tools, and their effectiveness depends on how they are managed and aligned with the team’s objectives.

Your suggestion that this topic could fuel a conference (or several!) is spot on. It’s clearly a nuanced issue that sparks great discussions and differing viewpoints.

Thanks again for sharing your insights.

Best regards,

Mustafa

Hi Andy,

You have highlighted some excellent points, particularly about the trade-offs between methodologies in safety-critical systems. I agree with your observation that there are no magic bullets, every methodology has its strengths and limitations depending on the context and, importantly, the expertise of the team implementing it.

Your point about Agile/Scrum being good at responding to new possibilities in a system, but sometimes struggling with handling changing requirements, is really insightful. It’s easy to see how the flexibility and iterative nature of Agile might lead teams to focus more on possibilities than on disciplined responses to evolving needs.

The challenge you mentioned with innovation in safety-critical systems resonates deeply. Balancing the need for innovation with the assurance of safety and reliability is a complex issue. It’s fascinating (and a bit daunting) to hear that even after your research Master's and subsequent studies, the field still lacks clear processes or recommendations. It speaks to the depth of the challenge and the need for continued research.

I also appreciated your note about being cautious when choosing a methodology. Agile or Scrum can sometimes be adopted for the wrong reasons, like being “fun” or trendy, rather than as a deliberate response to project requirements. It is a great reminder that methodologies are tools, and their effectiveness depends on how they are managed and aligned with the team’s objectives.

Your suggestion that this topic could fuel a conference (or several!) is spot on. It’s clearly a nuanced issue that sparks great discussions and differing viewpoints.

Thanks again for sharing your insights.

Best regards,

Mustafa