Because the software industry is so different than any other, the development model used prior of creating agile methodology was taken from the engineering disciplines, such as civil or mechanical engineering. Those disciplines put a lot of emphasis on planning before you build because the resources are very expensive and cannot be wasted because of bad synchronization or different physical characteristics like calibers, by example. The planning style is a predictive method that focuses on planning the future in detail. A team that uses these predictive techniques can report precisely what features and tasks are scheduled, both their order and length, for the entire time span of the development process. Predictive teams are very difficult to redirect after the client needs. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. These teams will often institute a change control board to ensure that only the most valuable changes are considered.
Opposed to this, the software as industry relies more on reusability and on site modifications. If a programmer finds a piece of code, of course respecting the intellectual property, can easily adapt it to his project. This approach is called adaptive, because these methods focus on adapting quickly to changing realities – no customer knows from the start exactly what he needs from the start. When the needs of a project change, an adaptive team changes the specifications as well. But this comes with a drawback; because an adaptive team will not be able to describe exactly what will happen in the future, it will precisely know only the current step, the next one depending on the user feedback. Thus, adaptive team knows exactly what tasks are being done next iteration, has an idea about the overall project, but only which features are planned for next month. But if asked about a future release, let’s say six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
Agile methods are a family of development processes, not a single approach to software development. It represents the ways of creating software in a lighter, faster, more people-centric way. The base of this is the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles. The Agile Manifesto states that:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
As methodology, agile development tries to push the development process to the user intended direction, providing many opportunities to assess the direction of a project throughout its lifecycle. This is achieved through iterations of work and at whom end teams must present a finished piece of code, usually a piece of shippable code. Because of this repetition of small chunks of work, as well as the functional product they yield, agile methodology can be described as “iterative” and “incremental.” As opposite, in waterfall approach, development teams have only one chance to get right each aspect of a project. Even more, in an agile paradigm, each and every one stage of development like requirements, design just to mention two of them, is continually revisited throughout the project lifecycle. Because of the short periods between reevaluations, usually couple of weeks, when the team stops and re-evaluates the direction of a project, there’s always time to redirect it in the correct direction.
The results approach to development greatly reduces both software product development costs and time to reach the market. In other methodologies, there’s a dead time associated with creating complex specifications while development team is in a code writing pause. Agile teams, on the other hand, can gather requirements at the same time they’re implementing them, so this process can’t really impede a team from making progress. And because a team’s work cycle is limited to few weeks, it gives stakeholders recurring opportunities to recalibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product.
This combination of features is an attractive option for stakeholders and developers alike. In the end, the development agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.
Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009