The quick and the dead

I thought this week I would talk a little bit about Agile software development. If you’ve not come across it before, and I’m sure you probably have, it refers to a number of similar methodologies for software development, for example Scrum. Why is it worth talking about? Well the answer is to do with the way anything developed can be rapidly updated in a controlled way making the best use of teamwork.

Basically, Agile software development is a way of managing a project that involves numerous small improvements to a piece of software rather than starting with a massive long-term plan and working towards it. It’s sort of like the ant approach to solving a problem. Lots of little actions take place by a number of different individuals and at the end of the project some massive piece of software has been created (or in the ants’ case, a massive ant hill!).

Each of these small iterations is worked on by a team, and they work their way through the standard software development life-cycle. The time for these iterations is usually between a week and a month. So each increment goes through planning, requirement analysis, design, coding, unit testing, and acceptance testing phases.

The technique is quite popular with programmers because there is usually little emphasis on written documentation, although there is face-to-face communication, and the team, which is usually between five and ten people, typically contains a customer representative. In fact that person is usually the one creating any written documentation.

At the end of each iteration, customers and stakeholders will review the progress so far and can then re-evaluate priorities. So this is why the technique is described as agile. The original plan is not written in stone and new choices can be made at any time during the project to ensure that customers maximize their return on investment.

Team members usually get to know each other quite well and know what each one is working on. Regular meetings of the whole team can help to identify any problems and the team as a whole can work on solving them. Meetings are held with everyone standing up – which focuses the mind and stops meetings dragging on for long periods of time.

Agile software development originated in the 1990s. The Agile Alliance (www.agilealliance.org) was formed by a number of organizations in the early 2000s to promote Agile software development. Agile methodologies like to see themselves as being adaptive, and they contrast that to other methodologies that are predictive. Typically, engineering methods tend to try to plan out a large part of the software process in great detail over a long span of time. The problem with this approach is that things may change between the plan being originally devised and the software being finally delivered. This means that they try to resist change. The advantage that agile methodologies offer is that they embrace change. They can adapt to changes and include them in the final software.

A second difference is that Agile methodologies are people-oriented rather than process-oriented. This means that the final process will be one that is usable by people rather needing people to learn to use the process.

So Agile software development is designed for scope creep – mission creep – that process whereby something was created for one purpose and then (while it’s there!) has other things required of it.

So why call the article the ‘quick and the dead’? I was metaphorically suggesting that Agile computing is quick (and very much alive) and older monolithic strategies might be dead in the water. What do you think?