The roots of agile programming as we know it can be traced back to 2001. At Snowbird ski resort in the Wasatch Mountains of Utah, a group of seventeen people met have fun, but also to find common ground on a issue that was too much discussed but no result can be achieved. They were the leaders of different currents of improving software creation techniques. They were adepts of Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming and other agile techniques, joined together by the need for an alternative to documentation driven, heavyweight software development processes.
All enumerated methodologies of software creation have the common ground of recalibrating themselves and their result, the code, will be crafter to the user’s desire by asking for input on each stage of project evolution. These recalibrations occur after the user evaluates the product, creates a feedback and sets the next iteration goals. This is also known as sprint or iteration. The sprint is organized into three parts: code creation, user review and setting new goals. At the end of every sprint, the team presents a functional module or piece of software to the user responsible with this for review. This emphasis is on creating a shippable product and also ensures that the software engineers from that team don’t get overwhelmed with a huge amount of requirements. The sprint has a specific length and this can either be set in the first place or can be adjusted later, depending on the team members personal skills or the load with tasks.
Because sprints repeat and the resulting code continually grows in functionality, this style of programming – Agile – is described as “iterative” and “incremental.” Comparing with the waterfall model, the development teams have just a single shot at getting each part of a project right. Usually, the longer and complex the project is, the farther will be the product to desired functionalities. This is happening not because of bad programmers, nor bad specifications, but because the lack of feedback. Fortunately, the Agile style not only asks, but enforces the process of getting the final user or Product Owner feedback.
With the advantage that teams can gather requirements while coding, the process of creating, maintaining and rewriting them is greatly reduced. Thus the customer will not be bored too much with them and fewer errors can be slipped into this process – bored people are more prone to errors. The agile team can focus on smaller tasks, delivering quality and almost bug-free and also having all the time the good feeling of making progress. While agile teams develop within the short, repeatable work cycles, the owners or users have all the time the opportunity to look at the results, test them and ensure that the product being created really matches the customers’ need. Bottom line, we can conclude that agile programming helps companies build products their customers want.
Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009