---

What is it?

The Manifesto for Agile Software Development proclaims that Agile developers value:

In other words they promote people above process. Like more heavy-weight development processes such as the Rational Unified Process (RUP), Agile methodologies adopt an iterative development process that seeks to address the key issues that were the cause of the 'software crisis' - ever-changing requirements, project over-runs, mismatches between requirements and delivery and so on. But where RUP attempts to handle the uncertainty of the real world by central planning, Agile seeks to incorporate uncertainty and contingency into the process itself.

Broadly speaking, therefore, we can talk about two camps of software development - those who tend towards modelling, formalised processes as exemplified by RUP and those who tend towards Agile processes. Obviously this is a generalisation, but it's one that serves a useful purpose in describing competing philosophies about software development.

Which Agile?

There are a number of competing schools of Agile development, including extreme programming (XP), Scrum, Crystal, Adaptive Software Development and many more. While all agree on the core Agile values mentioned previously, and share many of the practices, these competing methodologies differ in emphasis and some - such as XP and the idea of pair programming - differ radically in some areas.

These core practices include the use of automated builds, continuous integration, high degrees of unit testing, an emphasis on refactoring and the use of rapid prototyping to engage direct feedback from customers. While the details might vary between the different flavours of Agile, these are the practices that they share in common and which are designed both to facilitate high-communication team working and a highly iterative style of development.

Note also that these practices are very much programming practices - they are at the developer level. Agile methodologies, particularly XP, favour rapid prototyping and short iterations rather than in-depth modelling and design. In fact 'no big design upfront' is a favoured slogan amongst extreme programmers. This emphasis on programming is in contrast to the emphasis on architecture and design common to the more formal processes.

Key Agile Practices

Automated builds - on anything but the smallest projects having an automated build process is essential. Manual builds are liable to be both fragile and specific to a single machine - and time lost to making those builds work is time lost to development and testing. Even if you have to take time out to create an automated build environment it's time you'll get back later. It also makes it simpler to ensure that you have a standardised build that everyone on a project can share. Key tools: Ant, Maven, Nant.

Continuous integration - If you've got an automated build in place the next thing is to go for continuous integration. Waiting for weeks on end before you integrate code from different team members is a recipe for disaster. Of course an automated build and continuous integration environment pre-supposes version control (or Software Configuration Management to give it a more formal and impressive name). The sooner that you identify integration errors the sooner you can fix them. Key tools: CruiseControl, CruiseControl.Net

Unit testing - How do you minimise those integration errors? Use unit-tests so that code changes do not break existing functionality. Test-driven development is a key feature in many Agile methodologies for a good reason. In a highly fluid environment with multiple developers, shifting requirements and changing priorities it's essential to ensure that what worked yesterday works today. Key tools: Junit (and other xUnit tools such as NUnit, HTTPUnit etc), MockObjects.

Refactoring - Martin Fowler popularised the term refactoring in his book of the same name. It essentially boils down to code changes which improve the structure and clarity of the code without necessarily changing the functionality. Many Agile methodologies specifically attack the idea of code ownership - in this view all code belongs to all developers, who are free to improve the code when they feel it's necessary. Refactoring support now exists in many IDEs, such as Eclipse, NetBeans, Visual Studio etc. Note that refactoring without having unit tests in place is like doing a tightrope walking act wearing a blindfold and without a safety net. Key tools: Eclipse, NetBeans, IntelliJ IDEA, Visual Studio.NET.

Iterative development - Iterative development and short release cycles are both key agile processes. Short development cycles mean that working software is delivered quickly to the client so that feedback and changes to requirements are identified before too much has been invested in driving down the wrong road. There are also positive effects in terms of team working - the short cycle means that teams get used to working together through the whole define - develop - deliver cycle. Some Agile methodologies, such as Scrum, posit a particular length of development cycle, others are more flexible but still caution against anything too long (>3 months).

Other Practices

Pair programming - Two sets of eyes are better than one. Pair programming has been popularised by Extreme Programming (XP). In pair programming two developers sit at one workstation and develop the code together. Two developers are likely to encourage each other to stick to writing unit tests, conforming to coding standards, talk through algorithm and design issues, refactoring etc. By swapping the pairs it also ensures that expertise spreads throughout a team, and knowledge isn't localised to one or two experts, again encouraging refactoring.

Daily meetings - Scrum, for example, has the team meet every morning (the daily Scrum). Here members of the team report what they expect to be doing that day, ask questions of other developers and generally get a feel for how the project is progressing. As with many of the Agile practices, this is another strategy for developing high-bandwidth communications within projects.

On-site customer - Having a client representative directly involved in a project minimises the inevitable communication delays that arise when there are questions about requirements, functionality and features. Whether you have a client on-site or not, having fast and direct access to domain experts and users is a key component of nearly all Agile methodologies.

Anything else?

There's plenty more to say about Agile, both in terms of the philosophy, technical practices and organisational implementation. Take a look at the Software Methodology book recommendations here at TechBookReport to help pick the right book if you want to find out more.

Also note that self-reflection - taking time out to think about how you're developing and to see what works and what doesn't - is an important aspect of fine tuning your Agile processes.

Return to home page