I totally get what you're saying. After working with so many different methodologies over the years, they all start to feel pretty similar. They’re often pitched as groundbreaking, but when you look closely, they’re mostly just small tweaks to the same core process.

I couldn’t agree more on the importance of having the right people who really understand the system and the users. When you give them the freedom to choose what works best for them, things tend to run much more smoothly. It’s all about trust and letting the team do their thing, rather than forcing a rigid process on them.

it’s fascinating to hear about the diverse methodologies you’ve encountered throughout your career. Your reflections on the reverence given to methodologies are particularly thought-provoking. As you’ve rightly pointed out, it is easy for the process itself to overshadow the project’s core objectives, with the emphasis on compliance to methodology often taking precedence over actual project needs. The example you provided regarding the 6,000 page functional specification is a stark reminder of how excessive documentation can detract from clarity and focus.

I wholeheartedly agree with your observation that the success of a project is more often driven by the commitment, expertise, and collaboration of a small, well-aligned team, rather than the specific methodology employed. The ability of team members to navigate the complexities of organizational dynamics and manage internal politics is crucial to a project’s success. In such cases, the methodology becomes secondary to the people and the leadership involved.

Additionally, your point about the importance of data and entity relationship modeling as a foundational element for successful projects resonates deeply. Establishing a solid data structure from the outset certainly makes it easier to accommodate changes in process or scope, regardless of the methodology in use. This emphasis on getting the fundamentals right is something that is often overlooked in favor of the latest trending methodologies.

Mark, I agree with your take that waterfall and agile aren’t mutually exclusive. There’s definitely room to blend elements of both, depending on the needs of the project. As you rightly mentioned, even within an agile sprint, there’s often a level of iterative refinement and testing, which is quite similar to a mini-waterfall process. This shows that agile and waterfall are more complementary than many assume, and the key is using them for the right reasons rather than forcing a “wagile” approach.

Andy, I also appreciate your comment about the evolving standards in the safety-critical space. It's reassuring to hear that the industry is catching up and recognizing the need for iterative models, even in traditionally waterfall environments. The EN50716 standard seems like a step in the right direction. As you noted, it’s encouraging to see that safety-critical software and systems are starting to embrace iterative and incremental models rather than sticking strictly to waterfall. It’s clear that innovation and sound engineering need to coexist, especially in such high-risk environments.

I completely agree with both of you regarding the measurement of success. While speed of change is important, the real value lies in how well time, cost, quality, and responsiveness to change are balanced. In safety-critical sectors, particularly, the ability to respond to changes whether it’s new technologies or evolving requirements, should be measured alongside the more traditional KPIs. Being too risk-averse, as you pointed out, can sometimes prevent opportunities for improvement, and that’s something to watch out for.

I think this blending of methodologies with the right approach is where a lot of successful outcomes will come from.

Strict waterfall is not suitable for projects where requirements are subject to change. In today’s fast-paced environment, flexibility is crucial. While waterfall has its strengths, particularly when the requirements are well understood upfront and unlikely to evolve, it struggles in large projects with shifting demands.

The Rational Unified Process (RUP) exemplifies how methodologies have evolved to address this issue. By incorporating iterations, it allows for more flexibility in responding to changes and addressing issues early in development. However, RUP also brings its own challenges, such as potential overhead in documentation and managing multiple iterations. It provides a structured approach while allowing teams to adapt, making it more effective in dynamic environments compared to strict waterfall.

The key takeaway is that no single methodology is a one-size-fits-all solution. Each has its place, but what truly drives success is blending the best practices from different approaches to fit the specific needs of the project. A hybrid approach, combining the structure of waterfall with the flexibility of iterative models, might provide the right balance depending on the project’s nature and the team’s experience.

Ultimately, the goal should always be to deliver value while staying on track with time, cost, and quality targets, and being able to adapt to changes without getting bogged down by process for process’s sake.

The choice of programming language and platform plays a critical role in how software evolves and scales, often more so than the development methodology itself. While Agile or Waterfall provide frameworks for managing the project, it's the underlying technology stack that dictates how flexible and maintainable the software will be in the long run. For instance, the needs of web-based applications, often built with dynamic languages like JavaScript, differ greatly from those of complex, industrial-strength systems, which may rely on compiled languages for efficiency and stability. Therefore, making the right technical decisions early on is crucial, as it sets the foundation for how the software will grow and adapt over time, regardless of the methodology used.