An Introduction to Agile Development

It is commonly understood that the later a change is made in the life of a project the more it costs. Traditional projects mitigate this effect by attempting to eliminate risk by foreseeing problems and identifying solutions to them as early as possible.

Agile development practitioners believe that planning too far ahead is doomed to failure, because, however good we are as software developers, we are not prescient and we will make mistakes.

Instead of mitigating risk by trying to anticipate problems, agile projects are designed to avoid the increase in the cost of change completely. By accepting that change will happen and relying on several techniques to reduce the impact of late changes, agile processes alter the cost of change curve

Requirements

We often use stories in the form shown here, but the form isn’t proscribed:

Retrieve Contact Details

As a salesman I would like to be able to retrieve contact details so that I can make a sales-call with the details to hand.

I will know that I have achieved that
when:

I can retrieve the details for a contact where I specify their name,

I can see the details of the contact for the contact(s) I have found.

Our processes allow people to be humanly fallible!

Documentation

Agile projects encourage people to work together collaboratively and to share responsibility for finding solutions to problems. They avoid processes that encourage the use of documents, diagrams or models that get in the way of human interactions.

One key piece of documentation of the behaviour of the system is the collection of automated tests. Software developed in an agile project often has a much higher degree of automated testing than software developed by more traditional processes. This is a result of the pragmatic, quantitative approach that underlies agile processes. Software that passes the tests is finished; software that has no tests is not because we have no measure to show that it is finished.

Tracking Progress

In agile projects we measure software in terms of stories delivered, functionally complete, fully tested, and deployed into production.

We estimate for small pieces of work over short durations; we do it frequently, every iteration, and we collect statistics on our accuracy.

We use processes like Iterative development, Continuous Integration and Test Driven Development to help us achieve these goals.

Iterative Development

We divide our projects into tiny sub-projects called iterations. Each iteration is focussed on the delivery of a small number of stories and has all of the stages of a full blown project: analysis, design, development, testing, and in many cases even deployment. Typically such iterations are only one or two weeks long, limiting our exposure to the risks associated with predicting our future performance to only one iteration’s effort.