What is Agile software development?

This article is aimed at business executives who need to gain a basic understanding of the Agile Software Development process.

This is a very simplified explanation of the Agile process, it should not be used as a plan to run a project. Basically, you’ve heard of Agile and you want me to give you a quick introduction.

First, let me get one thing out of the way. Agile, does not mean cowboy-clipreg programming. Agile software development is a very disciplined and transparent process.

In most software development methods, you create a set of requirements documents before coding starts. This is not the case with the Agile methodology.

A claim document contains detailed details of what you want. On a medium-sized project, the documentation alone may take several months to prepare and refine.

How does Agile Software Development work without a claim document? Well, you still have a specification. But it is very high level, with just a few main sections like “We need new cashpoint software”. “It has to interact with a mobile phone”. “It must take into account all banks and UK-issued credit cards”.

The high-level specification gives an overall indication of the project’s intention. Creating high-level statements is stress-free and easy to control.

This brief specification is basically enough to start an Agile project. An agile project ticks together for regular periods, e.g. One week, two or four weeks.

In the first period, developers and architects will look at your existing infrastructure, security, etc. They will begin to build a basic framework for ATM software.

By the end of the next period, some very basic codes will work and be fully implemented in a pre-production environment. The basic code just has one or two bits of functionality. Such as pressing a button on the screen that goes to the database, getting some data and displaying it on the screen.

This basic code will have solved or revealed many problems remaining until the end of most other methods. This is also known as a “vertical strip of functionality” or a “walking skeleton”.

Then at the end of the next period. You will get a few real bits of functionality that you can test and use. It won’t be much, but you will see some tangible results for your budget. Instead of waiting 6 months to see some output from other methods.

From then on, new functionality is provided at the end of each period. It’s not long before you can actually start using the application.

This is where you get some good benefits. If a real user uses the application, he can highlight potential problems at an early stage where they are easy and quick to fix and most importantly at low cost to solve.

As the project progresses, you can change your requirements. For example, new rules may take effect. That’s no problem for an Agile project. You wait for the current period to finish and test the functionality. Then discuss the new requirements with the developers. The developers take it easy and say OK, we postpone what we did in the next period and implement those changes.

So if you don’t have a detailed specification, how do things get done? Well, I mentioned earlier that you still have a top-level claim. At the beginning of a project, this is the only information you need.

When a developer does a piece of work, he goes and sits down with the user and discusses the requirement to get the exact details. Generally, it should take about three days to complete these works. During these three days, the developer will be in constant contact with the user asking questing and showing progress for the user.

Having the users involved ensures that the project is developed exactly as required. Users will be far more threatening to the final application when delivered.

The Agile methodology may not be suitable for all environments such as NASA, the military, etc. But it is certainly applicable to most industries such as insurance, finance, healthcare, government, etc.

Let me make it clear that implementing a project in Agile is not easy, it is highly disciplined and must be bought in from everyone involved, and it includes all stakeholders in the project. It requires a lot of communication that is best done face to face.