Implementation Approaches, What's The Difference?

While I have talked in the past about the attributes for successful projects, I did not discuss the tactical approaches. Before joining Global 360, I had not heard much talk about tactical methods. However, it is obviously quite important. In my research, I have deduced the approaches down to the three most common: Agile vs. Iterative vs. Waterfall. What follows is a short discussion.

Agile Methodology
Back in 2001, a group of software developers who followed the "lightweight method [of development]" gathered in Utah to discuss various development methods. Out of this meeting, they crafted the "Manifesto for Agile Software Development." Essentially, it boils down to this (from the Agile Alliance Organization):

While all of the following are important, the Agile Method values:

• Individuals and interactions more than processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The ultimate end-goal is a successful implementation of working software. The most common criticism of Agile methodology is typically that it sacrifices detailed documentation for face-to-face communication and efficiency. The best way to think of the Agile Method is as an adaptive approach. In other words, as a project's needs change, so will the team - in order to deliver what is ultimately desired. This is not to say that the Agile Method is unplanned, rather it accounts for the reality where software implementations are often a moving target. Critical to this method, more so than any other, is the experience and resumes of the people involved.

Waterfall Methodology
Proposed in 1970 by W.W. Royce, famed software engineering researcher, this approach views development as a flowing process of: requirements analysis, design, implementation, testing, integration, and maintenance. Only when one step is completed and perfect, should the next one begin - there is no jumping back-and-forth, or skipping around. Interestingly, in the same paper which introduced the concept, Royce argued against it saying, "[it] is risky and invites failure."

While on paper Waterfall Methodology makes a lot of sense and in certain cases is ideal, most organizations are unable to invest the resources (i.e., money, people, time) required for a successful implementation of the method. In fact, many organizations do not know exactly what they want until they have a mock-up or prototype. They then use this as a way to learn more and incorporate the positives and eliminate the negatives in their design.

This is summarized quite nicely in a Wikipedia article on the subject. It states:

"The idea behind the waterfall model may be "measure twice; cut once", and those opposed to the waterfall model argue that this idea tends to fall apart when the problem being measured is constantly changing due to requirement modifications and new realizations about the problem itself. The idea behind those who object to the waterfall model may be "time spent in reconnaissance is seldom wasted."

Iterative Methodology
On the scale of "adaptive" to "predictive," this method falls somewhere in the middle between Agile and Waterfall approaches respectively. Essentially this approach allows for incremental development where a developer learns from previous versions of a system, using this information to constantly improve each new release. While quite practical for software development, for project implementations, it is not quite as applicable.

The Iterative Method boils down to the: Initialization step (creating a base version), the Iteration step (redesign and implementation of Project Control List tasks), and the Project Control List (record of all tasks that must be performed, including new features).

The initialization step forms the foundation for the project, offering the core features to solve the problem. It is usually easy to implement and simple to understand. The idea is to then use this as a way to elicit feedback from others. This feedback influences the Project Control List, which is used to form the next iteration.