Agile Methodology; a Popular Alternative in Project Management

Anyone who has participated in a professional project at their workplace can identify with some basic principles of one of the traditional software development project management styles, the ‘Waterfall.’ In this type of environment the requirements (or customer needs) of a project are permanently fixed at the outset along with the resources necessary to satisfy those requirements. The team performs several steps in succession along the path of the waterfall towards project completion. The major steps normally include: design, code, integration, test and deployment. Once these steps are completed, the final product is revealed to the customer. Although the waterfall method is generally considered to be a software development tool, it has uses for any type of project where a team is attempting to develop and deliver a product to a customer. This can be a new product or changes to an existing product.

One common complaint of the waterfall method arises when projects take months or even years to complete. Once the project is complete and the product is revealed, how do we know the product is what the customer envisioned? What if (during let’s say a hypothetical two year project) there have been other new technologies developed that would have changed and/or expanded the scope of the project had that been an option? After all, Moore’s Law tells us this is almost certain to happen in long term tech related projects.

The Agile methodology claims to be a solution to this problem. One of the key principles of Agile is the following, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This is the first of twelve principles written in the Agile Manifesto (written in 2001 by a group of software developers and available at agilemanifesto.org).

The main difference here is that with Agile the team produces workable pieces of the project or “increments” on a routine basis, usually every two weeks. These workable products must be testable and commented on by end-users. With this methodology, the project participants can receive routine feedback as to what works with the product and what doesn’t work. For example, if the product in question was a new mobile app, using the traditional project management system one can envision the customer illustrating everything they would want from the app (i.e. the design, the features, security, analytics, etc.) to the development team. Then, six months later the customer receives a final product. Now the product may be just what the customer envisioned, however what if the customer changes their mind about a certain module once they see the final product ‘in the flesh?’ What if a new mobile app technology is introduced during the six month development period that would have been a great fit for this product?

With the Agile system there are basically mini waterfalls taking place within each increment or ‘sprint.’ Using the mobile app example, instead of building the mobile app and delivering it to the customer, the Agile team might deliver the basic design as one increment. Next would be feature #1, then feature #2, then security. You get the idea. During each increment the development team remains nimble enough to change course based on new information from the customer or the industry at large.

Try to envision how Agile would work within your industry. How about changing from one type of accounting software to another, or automating a legacy process? Do you think Agile would add value to these types of projects? Do you think the waterfall process has value?

Please leave me your comments.