What are the most common myths about waterfall development?

In my experience, although my previous work applied the waterfall development method. Several times, we had to pivot or make changes due to timing, development issues, or lack of resources. We even went as far as implementing something that could add much value for the company and customer. Waterfall works best when you have the right people in place who are ready to problem-solve.

The commonly observed perception of Waterfall's sluggishness can often be attributed to a deficiency in the initial planning phase, especially when defining project requirements at the project's inception. This is a scenario I've encountered frequently. In such situations, individual team members play a pivotal role by ensuring that the team is well-informed about potential risks and by offering actionable steps for possible mitigation. It is essential to encourage proactive communication, rather than assuming that others share the same perspective.

It is the complexity between organizations and work that best leverages waterfall, and the identification of downstream dependencies can augment agile development in a complex operating environment.

Myth: You must choose one methodology, either Waterfall or Agile. A common misconception is only one methodology can be used at one time. However, a hybrid approach can be successful. Stakeholders that lean toward the traditional approach with formal approval gates and longer cycle times would benefit from the familiarity of waterfall. However, DevOps can use Agile methodology where sprints are short term and iterative with validation from stakeholders throughout the product development cycle. Using both methodologies provides a versatile approach that can benefit organizations that have different project management frameworks.

If i ask whats better agile or waterfall? 9 out of 10 people will immediately say Agile. It's a trick question - The right answer is 'it depends' on what you're building. Context matters. Take infrastructure for example. Strict, high fixed cost and time with low or no customer involvement needed. Theres nothing agile about building bridges and tunnels nor there should be. It's true in todays digital product world, Agile is far better suited and rightly the preferred product development methodology. Focusing on maximising value and reducing time. But, I have helped more then a few clients to product success with Wagile, a combination of waterfall and agile. A amazonian take on dev: Rigid on the structure but flexible on the details.

There isn't always one perfect answer, the situation should determine the development methodology. Some products and projects lend themselves well to agile or other iterative development methodologies, where rapid deployment is key. Smaller projects tend to fall into this category. Larger, more tiered and complex projects require a varied attack; Agile on some parts of the project which can be built in modular fashion, incrementally. Some parts of the project requiring hardware or extensive regression testing lend themselves better to the structure of Waterfall development.