The delivery aspects of waterfall usually means it is a rigid and structured organization with people in rigid and structured roles that have defined responsibi

The delivery aspects of waterfall usually means it is a rigid and structured organization with people in rigid and structured roles that have defined responsibilities. This can drive bad behavior, pitting teams like requirements analysis, design, development and test against each other since they sometimes have competing interests. In a larger organization, competing interests emerge since these teams are often managed by separate people who manage and measure their people with objectives that are for the role. People who write requirements get focused on common ways to document requirements, templates, etc. A rigid organization using waterfall tends to have very structured, approval oriented deployment processes which leads to things like only having project launches 3 times per year. A weekend launch starting with a backup of the system on Friday in case they need to restore Sunday night if the long sequence of 300 deploy steps is somehow botched. I went from organizations like above into one that uses a Continuous Delivery model. This means we deploy every day, multiple times a day if needed - to production. Small changes that are testable with builds being tested continuously, operations of the environment heavily monitored and developers own their changes into production.