Agile coding: a primer

An essential guide to the theory, benefits and risks behind agile development, and insight from the IT leaders who are using the approach

In recent years, agile development has gained a cult-like following who insist that it is much more effective than more traditional software development methods, such as waterfall.

So what is agile development, and why is it attracting so much interest among developers?

Agile is a form of incremental software development that is quite unlike other approaches. The idea is that it helps reduce the risks in traditional development by including continuous planning and feedback processes right from the start of the project. The project is constantly adapted according to how much progress is made and the needs of the business.

A typical agile project involves programmers working in cross-functional teams, which gives the approach a flexibility and responsiveness that others lack, according to proponents.

The agile methodology contrasts markedly with waterfall development, which sees requirements and a specification set out at the beginning of a project. Developers then follow the spec and once the coding is done, it moves into the testing phase.

Both waterfall and agile have their strengths and weaknesses.

“There are some very serious pitfalls to waterfall,” says Michael Azoff, principal analyst at Ovum. “A lot of effort goes into generating requirements and creating a specification, which you then work from for your build.

“However, it is difficult to know requirements precisely, especially at the beginning of a project. These change through the lifetime of the project itself.

“Testing also tends to be done at the end of a waterfall project, where there will be a lot of pressure with the deadline approaching, and people take shortcuts as a result.”

With agile development, on the other hand, there is frequent feedback on coding throughout a project, with code constantly reassessed and tested.

“The client is far more involved in an agile project,” says Martin Rice, chief executive of software development company Erudine. “You test the hell out of everything as you build it, and as a result things can only go wrong over a one-month period, rather than a five-year period.”

The benefits of agile have penetrated the public sector, where large-scale projects within the Department for Work and Pensions (DWP) are being run according to the approach. The DWP’s Universal Credit system is an example of this and follows a recommendation to use agile in a recent Institute for Government report.

“There will be agile activity in 60 per cent of the department,” said Malcolm Whitehouse, group applications director, DWP, when speaking at a recent public accounts committee meeting looking at IT and governance.

“However, we will use more standard development practices with core infrastructure delivery projects. We didn’t want to take a blanket approach to agile development.”

Government CIO Joe Harley agrees about the benefits of agile and denies that there are obstacles to adopting the approach in the public sector, but suggests it is better suited to some projects more than others.

“We used agile for the first time last year to develop the automated service delivery approach,” added Harley at the same committee meeting. “It is most useful when engaging with citizens and customer direction – basically when adopting a customer-centric approach.”

David Norton, research director at analyst firm Gartner, argues that agile can work in any industry or sector, but it requires a business need.

“The idea that there are verticals that agile practices are not applicable to is gone. From healthcare to aerospace, agile is going on everywhere,” says Norton.

“Waterfall approaches have their place. For instance, in areas where there isn’t a great deal of change, and where you have an existing workforce. You probably don’t need to disrupt this, so it is usually best to leave them alone.

“Deciding not to use agile when there are no business drivers is fine. But what is not fine is when a business has a need to use agile, but it doesn’t want to move out of its comfort zone and make the change.”

Norton insists that if there is a business need and agile is to be successful, the business not only has to approve a change in the approach, but be directly involved in the development process throughout.

“The number one failure I see when companies adopt agile is the business walking away. Agile is an example of an empirical process, based on empirical feedback. If the business isn’t involved, you can’t close the loop,” adds Norton.

“With agile, feedback is typically required every few weeks, and you really do need the business to decide whether they like the features or not. If this doesn’t happen, you build up serious amounts of technical debt, and it is this that will kill a project.”