Agile Methods vs. the Waterfall Method

I was taught about many different approaches to the software life cycle while I was in college. The waterfall approach to software projects was seen as the wisest way to go, since this approach addressed the concern that a change made at any phase of the life cycle ought to also affect previous phases’ documentation and testing. One of the last courses I took at school included a section that quickly covered agile approaches. In my great enthusiasm over these new ideas, I went to work and shared my enthusiasm with my co-workers. Wouldn’t it be great if we could skip over the weighty documentation phases and start producing a working solution while the business needs are still fresh in our minds? Wouldn’t it be great to work closely with other team members to help each other proof our architectures and brainstorm complex issues as they arise and before struggling alone? My co-workers laughed at my naïve enthusiasm. Who want to sit next to someone else and watch while they code all day? In our profession of high intellect and large egos, who wants to be dragged down by being forced to pair up? How can we start to build a solution before every detail of the problem is fully defined?

As some years have passed, or maybe as my employer has changed, the agile methods have really seemed to catch on. Iterative approached are being tested, and in my experience they are successful. I do not claim to be a guru on agile methods, and I do not claim to know the ins and outs of SCRUM versus Extreme Programming. But what is the key difference between the agile methods versus the traditional methods to software engineering?

I think the difference can be summed up in one word: communication.

While communication has always been an important part of software engineering, I fell that the traditional approaches encourage us to lay everything on the table from the start. Go through a phase of requirements gathering. Go through a phase of specification writing. Go through a phase of writing a detailed design document. Finally, build what you planned. Plan your work and work you plan, right?

I say wrong! To me, the key to the success of the agile projects I have worked with lay our ability as a development team to admit that we cannot ask all of the questions up front. Besides the fact that requirements change with time, so does our understanding of the business problems. And I have never seen a requirements document that is not laden with holes and ambiguities. A small detail missed in the requirements phase can be the downfall of the entire project.

Agile methods appreciate this risk and mitigate it through constant communication. There is no one phase where meetings are held with the end users. The end users are involved in meetings with the development team throughout the life of the project. The end users are part of the team and play an active role in communicating with the development team and working with the seeds of the end product from its infancy to its completion.

As a result of my experiences, I hope to never spend a year working on a functional specification again. I hope to never face another deployment phase of a project that follows a year of closed-door development. I hope to say goodbye to the waterfall approach once and for all and hello to agile development.