Agile vs waterfall vs spiral vs V-model vs big bang

Ok. So maybe not all of those. But definitely agile and waterfall.

I’ve been thinking about this a lot lately.  See a lot of social media chatter about processes and one recently got me to thinking.   I’ve worked on projects that have used all of these methodologies, and I’ve seen firsthand how they can impact the success of a project.

Waterfall fails because it is rigid. It assumes that all requirements can be gathered upfront and that they will not change. This is rarely the case in real-world projects. As a result, waterfall projects often end up with a product that does not meet the needs of the users.

Agile attempted to address this by being more flexible and allowing for changes throughout the development process. However, agile can also fail if it is not implemented correctly. And the primary failure point is the same as waterfall: design. Many who strictly interpret agile will complain about doing architecture and requirements definitions. And, I think we see this today with the lack of architecture roles in an organization.

As long as I have been working, I have seen this resistence to upfront design and evaluating changes according to the longer view plan--and related, keeping that plan up-to-date when changes predicate a change to the future needs. I think it is because people are afraid of being wrong. They don’t want to commit to a design because they are afraid that it will change later--and they do not want to change a plan because it implies they got it wrong the first time. But, the reality is that all designs will change. The key is to have a good design process that allows for changes and iterations. This is where I think agile can be successful. If you have a good design process that allows for changes, then you can be agile and still work against a longer-term plan.

I think the key to success is to start with stepping away from the dogmatic viewpoints that process has to be one or the other. Let your process allow for changes, while measuring the impact of those changes against a long view plan. Having someone in the official role as architect helps the organization balance changing needs against a long term view. The entire team needs to be involved in the design process and understand the long-term vision for the project and the architect is the evangelist of this view. This way, when changes are proposed, everyone can evaluate them against the long-term plan and make informed decisions.