What is Agile Software Development Methodology?

Before the use of Agile methodology, software development was accomplished via Waterfall Methodology which includes following particular phases of software development in order. The phases include Requirements, Design, Coding, Testing, and Deployment. In Waterfall method, one moves to the next phase only when its preceding phase is complete and verified. Setting the requirements and specifications of the software before starting the development is very important in Waterfall Method. Extensive documentations are written to clarify the specifications to an extent that these documentations become the user guide of the software. Software is developed in full and then tested and delivered to the customer meeting the specifications. Another phase of development starts with documentation of new set of specifications and requirements.

This presents many challenges, some of which include changing business requirements or the technology supporting the software mid development. In addition, the customer is not able to view the progress of the software development or provide feedback. The customer is stuck with the original requirements which might not be of any business value anymore.

The software delivered using Waterfall Method is sometimes simply out of date. Since the customer and features requested by the customer is the biggest driving force in the development of the software, missing this mark means disaster. Hence, instead of using the waterfall method, iterative methodology was introduced to accommodate rapidly changing requirements which became known as Agile Software Development Methodology.

Agile Methodology accommodates rapidly changing requirements by developing the software in iterations or sprints and delivering each iteration of the software to the customer to show progress and request feedback. Agile methodology offers flexible development, early delivery, and continuous improvement.

The progress of the entire product development and each sprint is analyzed by using Burn-Down and Burn-Up Charts. At the end of each iteration, for example every 2 weeks, a working product is demonstrated to the customer. This method reduces risk by showing progress of the software to the customer and adapts to the changes requested by the customer. An iteration does not add enough functionality to make the software viable for market release as multiple iterations are required to release a version of the product.

Communication is very important. Following a set of bureaucratic process delays the communication and the process required to make a change. It is far better to have five people in the room to discuss an issue, feature, or a requirement than to route an email or an issue ticket to each one of these individual and then coordinate a formal process.

It is a challenge to successfully capture all customer requirements at the beginning of the software development cycle. In addition, it is difficult to get customer feedback without showing the actual working software to the customer. So, it is better to directly involve the customer in the development of the software and deliver each iteration or sprint to the customer for direct feedback. Instead of negotiating contract with set specifications, gather live feedback from the customer and accommodate any changing requirements. This assures that the software is being built directly with the features the customer has in mind.