By Jerry Helms

I recently attended a three-day training class on Agile Project Management. The instructor in the class compared and contrasted Agile Software Development to Waterfall Software Development. I started asking myself when was the last time I ever worked on a project that used the waterfall approach? I really could not remember a project that I could associate with the strictest interpretation of what the waterfall approach means.

As I continued to think about the issue, I came to the realization that comparing Agile to Waterfall using the "strict" definition is primarily a teaching metaphor. The "blinding flash of the obvious" was that Agile focuses on continuous team improvement and new techniques have been developed to focus on improving performance.

Waterfall Software Development

If you have made it to this page and are actually reading the blog, then you know what waterfall software development is all about. In my opinion, this approach was a necessity back in the early days of software development. Writing a COBOL program was an expensive proposition. Developers needed to have a full set of programming specifications before they started coding.

Software development started changing in the 1980's. Mainframe report writers appeared, making it unnecessary to write a new COBOL program for every report. Rapid development tools made it easier to development online applications to validate user requirements.

I still remember one of my first portable computers. It was built by Compaq and it took up every inch of space underneath the airplane seat. The latest and greatest tool was dBase, a rapid development tool for the PC. We used dBase to validate user requirements for mainframe applications. Everything just took off from there!

The project failure rate was very high for waterfall projects and all of the variations over the years.. The primary reason has been attributed to incomplete or changing user requirements.

• Prototyping was implemented to help develop requirements with users. However, the prototype was almost never used as the final software implementation. Everything was reworked.
• Very formalized change management processes make it hard to satisfy customer requirements, which WILL change over time.
• Project and task estimating had a tendency to pad everything to make sure enough time was allowed. By the time the project was even close to completion, the customers' needs changed.
• Virtually every step required copious documentation. I know for a fact that at least 80% of the documentation was never looked at once it had been written and reviewed once.

Agile Software Development

I am not going to attempt to provide a comprehensive definition of Agile Software Development. I'm just going to restate some of my observations.

I have had the pleasure of working with continuous improvement teams in an operations context as contrasted to software development. Agile clearly has benefited from the concepts associated with lean manufacturing. Self-organized teams focus on eliminating waste: reducing cycle times, eliminating defects, reducing inventory, eliminating unnecessary movement of people or product.   Lean manufacturing also provides some basic tools to assist with waste elimination:  visual systems, error proofing, process measurement, team building.

Should your organization use "Agile" on every project and project phase?  Probably not.  For example, Agile doesn't really apply to the development of a strategic vision for your organization.  However, the fundamental concept of continuous improvement for EVERY PROCESS should not be overlooked.

Summary

I have always been an early adopter of process and technology.  I loved dBase as a prototyping tool.  The Rational Unified Process was an early attempt to improve software development processes.  I quickly learned that the most important aspect of the RUP was to pick and choose the pieces of the methodology that made sense for each project.

Will Agile make a difference?  The Standish Group is well known for publishing statistics on project failure (CHAOS reports).  I don't know if the statistics are going to be better in 10 years.  I do know that many organizations have seen great results with Agile Software Development practices.