Simon Metz - Engagement Director

Agile software development processes are built on the foundation of iterative development. To that methodology adherents to agile development add a lighter, more people-centric viewpoint than traditional approaches. The iterations or sprints tend to be much shorter, typically a matter of weeks rather than months as seen in iterative development methodologies.

Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. This allows for smaller sets of Regression Testing which allow for bug free deployments of code and web software. Many projects are initiated with more features and as the project progresses a final product spec becomes apparent because of feature prioritization exercises or timing/budgets.

Agile teams learn to add features in the order that makes sense to the business which also adds to buy-in from key stakeholders. Since features always get discarded at the end of a project, a team interested in building a powerful application must build and fully incorporate the most important features first. Although there are some engineering considerations to be accounted for, a manager must be certain to build the critical business functionality first keeping in mind dependancies. Especially in web based architectures, sometimes a small component is easliy built in conjunction with a highly complex feature so that they work in tandem and can be tested and made bug free in the same sprint. An agile team understands the real business trade-offs that are being made as each new feature is added, and using this approach new builds of the app can occur very frequently. An additional advantage to the business is in a year long product development cycle, the business now has clear choices to make every two weeks. Options include continuing to add more features on the current plan, prioritizing the features differently, or to stop adding features altogether. The business now can decide halfway through the year if all of the key features are present. The ability to release a version of the product at each iteration also makes the developers far better software engineers. Issues such as integration and installation that previously were deferred to the end of a project must now be addressed consistently throughout the entire development lifecycle. Software built in this manner is of consistently higher quality.

Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software, but have the drawback from a business perspective that they do not provide long-term planning capability and therefore are more difficult for larger corporations to implement. A popular Agile methodology is Scrum which uses daily scrum meetings guided by a ScrumMaster to break up agiles tasts into daily sub tasks.

Extreme Programming, or XP, is the best-known agile process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of Refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the developers start again on writing tests for the next part of the system based on a prioritization schedule.