Waterfall methodologies

- [Narrator] The waterfall methodology is the tried and true process of taking a product from concept to market. It follows a serial process with gates, keeping the product from moving forward, unless specific objectives are completed. The team formulates an idea, tests out concepts, creates a prototype, builds upon that prototype. And when it's close to being a product, it enters a test, it's a serial process ensuring that the last gate is closed before opening the next, the waterfall method has had great longevity because it aligns perfectly with the software development lifecycle or SDLC, planning, analysis, design, implementation, test, release and maintenance encompass the entire life cycle of a product. It makes sense that the process for development and testing should align with it. In some ways, waterfall is effective because it ensures the teams are focused on driving and delivering the best possible product. If something leaves any stage early, it's because it may not be ready for the next. In concept, this means that the operational integrity of the process directly aligns with the overall quality of the product. The waterfall method is still widely used in the industry. However, waterfall has several key flaws that have driven most organizations to reassess whether it's the most effective approach to delivering products. Developers in the waterfall model focus so exclusively on delivering their best work, they fear that issues could have the software back on their desk. In this design, a product can't move past the next gate unless it's ready. This readiness is the first of many sticking points about waterfall. Getting something into quality means meaning key benchmarks and baselines to ensure that the product is viable. As the product grows in maturity, complexity and size, changes aren't as simple and issues become more difficult to address. Developers are obligated to either make the fix, delay the project or force someone to accept the issue with a promise of a fix later. This constant back and forth means waterfall is slow. The consecutive design of the method means that at any given time, one team is completely focused on the product, while the other teams sit and wait. This drains resources and inhibits the ability of teams to commit to new projects until each stage is complete. Any misstep along the way could send the product back to the prior stage. Worse, development is often unwilling to return to the project and the issues get pushed out in the release. Teams spend countless hours trying to get everything right. And when issues are discovered during quality testing, they feel a bit burned and often burned out. This model is frustrating and ultimately forces many companies to make uncomfortable and even poor decisions. Products often have a very narrow window for launch to ensure it hits the market at the right time. Think about something needing to be ready for Christmas, or maybe making a big splash in the press during an event. In waterfall, everything must be aligned perfectly, or you may miss that window. Teams working in a waterfall methodology see them as overly managed with way too much emphasis on planning. You'd think these were good things, but when you are trying to align various organizations with different objectives and timelines, what seemed well organized becomes cumbersome and competitive. Collaboration often suffers in lieu of process. And this can get ugly. There can be a lot of finger pointing in the waterfall process. Each team sees the other as an obstacle to delivering a product. Development sees quality as being to resolute, quality sees everyone else as being too aggressive. Management's pushing for release to hit important windows, teams force quality testing to walk a tight rope. On one side, you have the development team, marketing partners and others invested in the process watching closely, waiting to see the results, closely watching the clock. on the other, you have customers, eager to get your new product free of bugs and easy to use. This creates a lot of unnecessary and unfair pressure. If everything works effectively, waterfall processes can deliver good products. However, even the perfect projects rarely deliver them quickly and rarely without some compromise, it almost invites bad choices in favor of a schedule. For this, the methodology is a solid and proven practice burdened by its slow nature and serial design. Because these key flaws can't be overlooked by development teams trying to remain competitive, waterfall has slowly been augmented or even replaced by newer and more innovative processes. Technology just moves too fast and investing in a more flexible, even agile approach is where most programs are moving.