What is Agile Methodology?

Engineering methodologies required a lot of documentation thereby causing the pace of development to slow down considerably. Agile Methodologies evolved in the 1990s to significantly eliminate this bureaucratic nature of engineering methodology. It was part of developer’s reaction against “heavyweight” methods, who desired to drift away from traditional structured, bureaucratic approaches to software development and move towards more flexible development styles. They were called the ‘Agile’ or ‘Light Weight’ methods and were defined in 1974 by Edmonds in a research paper.

Agile methodology is an approach to project management, typically used in software development. It refers to a group of software development methodologies based on iterative development. Requirements and solutions evolve through cooperation between self-organizing cross-functional teams, without concern for any hierarchy or team member roles. It promotes teamwork, collaboration, and process adaptability throughout the project life-cycle with increased face-to-face communication and reduced amount of written documentation.

Agile methods break tasks into small increments with no direct long term planning. Every aspect of development is continually revisited throughout the lifecycle of project by way of iterations (also called sprints). Iterations are short time frames (“timeboxes”) that normally last 1-4 weeks. This “inspect-and-adapt” approach significantly reduces both development costs and time to market. Each iteration involves working through a complete software development cycle characterized by planning, requirements analysis, design, coding, unit testing, and acceptance testing. This helps minimize overall risk, and quicker project adaptability. While iteration may not have enough functionality necessary for a market release, aim is to be ready with a release (with minimal bugs) at the end of each iteration.

Typically, the team size is small (5-9 people) to enable easier communication and collaboration. Multiple teams may be required for larger developmental efforts which may also require a coordination of priorities across teams. Agile methods emphasize more face-to-face communication than written documents when the team is in the same location. However, when a team works at different locations, daily contact is maintained through videoconferencing, e-mail, etc. The progress made in terms of the work done today, work scheduled for tomorrow and the possible roadblocks are discussed among the team members in brief sessions at the end of the each working day. Besides, agile developmental efforts are supervised by a customer representative to ensure alignment between customer needs and company goals.

Software Development was initially based on coding and fixing. That worked well for smaller software, but as the size and complexities of software grew a need for a proper process was felt because the debugging and testing of such software became extremely difficult. This gave birth to the Engineering Methodologies. The methodologies became highly successful since it structured the software development process. One of the most popular models that emerged was the Software Development Life Cycle (SDLC) that developed information systems in a very methodical manner.Waterfall method is one of the most popular examples of Engineering or the SDLC methodology. A paper published by Winston Royce in 1970 introduced it as an idea. It was derived from the hardware manufacture and construction strategies that were in practice during the 1970s. The relationship of each stage to the others can be roughly described as a waterfall, where the outputs from a specific stage serve as the initial inputs for the following stage. During each stage, additional information is gathered or developed, combined with the inputs, and used to produce the stage deliverables. It is important to note that the additional information is restricted in scope; “new ideas” that would take the project in directions not anticipated by the initial set of high-level requirements are not incorporated into the project. Rather, ideas for new capabilities or features that are out-of-scope are preserved for later consideration.