Agile development: Cheat Sheet

Why it's time to get flexible about IT projects

...assess which business needs have been met, the quality of the work delivered and whether it is providing value for money. The dev team will adjust what is delivered in forthcoming updates based on feedback from the product owner - for example, prioritising different business needs, or altering the pace of delivery to better balance value for money and product quality. On the technical side, work such as integration and testing is automated to keep pace with the fast turnaround.

This constant feedback and scope for change throughout the project's lifespan is designed to allow it to better meet user demand or to correct miscommunications. Ovum's Azoff said: "Humans very easily misunderstand each other and having a process that allows for revisiting that aspect is very useful."

So what are the real-world benefits?

Faster project delivery, high quality systems and a product that better reflects what the client wants, according to advocates of agile. One big name company that has demonstrated how well the methodology can work is software-as-a-service firm The length of time it took for the vendor to push out new releases had grown to 18 months but after adopting an agile methodology it was able to reduce its release cycle back to six months, according to Ovum's Azoff.

The fast pace of delivery possible under agile was also a driving factor in the government's decision to choose the methodology to deliver its £2bn Universal Credit project within its two year project deadline. Azoff said that agile's rapid delivery stems from a reduction in the amount of work that needs to be redone at the end of a project to correct for changing/misunderstood demands or lapses in quality. The modular and flexible approach of agile also makes it easier to identify and prioritise delivery of key parts of the project, in order to bring a project in on time and budget.

How does one become "agile"?

Through a lot of hard work. Ovum's Azoff estimates that it can take anything between six months to a year of training for staff on the business and technology side before they are ready to tackle an agile project. Mindsets need to be changed, ways of doing business need to be altered and business silos need to be broken down to allow for cross departmental and inter team working.

Azoff stressed the need for organisations to appreciate the additional burden of expecting a workforce to verse themselves in agile while carrying out their day to day jobs. Organisations should ensure they provide the necessary support and be prepared to invest resources in smoothing this transition up front, he said.

A major risk to any agile project comes from individuals not having the expertise or knowledge to keep the project on track – be it the product owner not having a clear idea of the desired business outcomes or the dev and testing teams not being used to working without detailed documentation.

Best to start small then?

Exactly. The training and restructuring that agile demands means it is better to trial it on a small project to give the workforce a chance to familiarise themselves with the methodology.

Is agile the future?

It would appear so, once organisations have invested in training staff and reorganising business processes for agile there is little reason for them to return to the waterfall methodology. Ovum's Azoff said that waterfall, with its rigid nature, is a "faulty process" and that agile will become the "dominant" methodology.