Agile vs. Waterfall – what is the big deal?
January 24, 2013 13 Comments
I have been working in companies the last 5 years where we have followed the agile methodology in product development. Shorter sprints, faster releases as opposed to month long development cycles that were common in waterfall.
Here is a guest blog post written by Mike Cudemo of Sparta Systems that explains the differences between Agile and Waterfall product development methodologies in a very simple way. He also explains the benefits of doing agile as a way of increasing the success rate of IT projects.
Seeing is believing. Agile methodologies are not perfect, but they are three times more successful than traditional waterfall methodologies (source: Standish Group). Agile methodologies allow end users and stakeholders to visualize their requirements faster and catch errors earlier in the development process.
A waterfall process can be likened to building a house. An architect translates your requirements into blueprints which only an architect can visualize. Your first glimpse into reality occurs after the foundation is poured and the walls are erected. While things can be changed, it is more expensive to change. Most people struggle to catch problems until the drywall is up and the ductwork and plumbing are in place. Again, you can make changes if there are issues, however, now it is even more expensive to address. The waterfall process attempts to “freeze the requirements” after the blueprints are designed. As you can imagine, this is not reality. The later you catch a requirements problem (e.g. I want a larger master bedroom closet), the more expensive it is to fix. In some cases, it is impossible to fix. You can have the closet, but little Timmy needs to sleep on the roof!
The Agile Method does not attempt to “nail and freeze the requirements” all up front at one time. It assumes that the requirements will evolve and change as the customer begins to visualize their own requirements. The Agile Method attempts to build the house by first creating a visual 3D representation of the outside of the house. This is how it is going to look when you come home from a long day at work. After the outside look and feel is developed, you attempt to construct the house one to two rooms at a time. The Agile Method attempts to focus the requirements, design, code and test into iterative smaller development phases. Essentially, the Agile Method is a series of smaller contained waterfalls. End users and business stakeholders get to see and experience the system as it unfolds. Course corrections become more apparent and easier to navigate.
Waterfall processes attempt to minimize and control change. Agile processes accept the inevitable need to accommodate learning about the real requirements. End users think in broad strokes; however, we all know the devil truly lies in the details. Skilled Agile development teams have a clear methodology to guide the process most effectively. They will select the plot and then develop the look and feel of the outside of the house. Next, they will focus on the 1st floor, and then move to the second floor. The finished basement will be last, because as we all know, we’ve run out of money by that time.
We find ourselves in the worst economy since the Great Depression. Many CFOs find themselves in a complex juggling act of cutting operational costs and making technology investments. CFOs are forcing their CIOs to come up with plans to leverage existing investments, yet develop the capabilities to rapidly respond to both economic growth and competitive changes. Project failure is really not an option, yet according to the statistics, waterfall approaches waste 60% of a company’s IT project budget.
Over 20 years ago, 90% of IT projects failed or under-delivered on functionality. Today, depending on your source for statistics, IT projects fail or under-deliver between 30-70% of the time. It is better, but far from perfect. It is clear, that Agile methodologies are at least 3x more likely to succeed.
Agile methodologies are iterative. Understanding is paramount to containing change. Systems unfold one functional area and set of screens at a time. An Agile Methodology will not fix a bad project vision, an impossible task, or a lack of skilled personnel. Properly applied, an Agile approach will catch the poor vision, unattainable goals, or lack of resources early. IT and application departments must learn that cancelling a project early is actually a win. Broken processes should be fixed first before they become institutionalized with software or a system.
Companies that employ Agile methodologies and cancel unattainable projects early will thrive. Their IT success rates will exceed 85%. Most importantly, they will have more working capital to drive growth, innovate, and increase productivity.
About Mike Cudemo
Mike Cudemo runs the Customer Success Program at Sparta Systems. The program accelerates knowledge transfer of best practices to our customers to enhance overall business performance. Mike spent over 12 years integrating manufacturing operations with ERP and value chain systems at Fortune 100 clients, utilizing his expertise in value chain, quality, manufacturing execution and process automation systems. Trained as a systems engineer to analyze and simplify computer systems, Mike has spent a career helping clients understand their core business drivers, simplify the underlying processes, and automate the repetitive, non-value-added tasks which introduce defects and waste.