Agile development eh, shall I dust off the yoga matt?
Don’t worry, there are no contortions required, although agile is all about being flexible when it comes to managing IT projects.
Right, so I’ll stop limbering up
Thanks, that was quite off-putting. If your business undertakes any IT project then you need to start caring. According to Michael Azoff, principal analyst with Ovum, businesses that ignore the rapid and high quality development promised by agile methodology will struggle to survive – as he puts it, it’s a must for organisations to remain competitive.
So what exactly is it?
Agile is designed to overcome the failings of the traditional ‘waterfall’ approach to IT projects. Under the waterfall method the specifications for a system are drawn up and locked down at the start of the project. The design and coding follow and it is only close to the end of the project that the system is tested, just ahead of it being deployed.
The problem with this rather rigid approach is that by the time the system is delivered many factors may have changed, resulting in the finished system not being fit for purpose. An organisation’s needs may have altered, superior technologies may have been developed or the final system may simply fail to deliver what the organisation hoped for. But accommodating changes using the waterfall methodology means drawing up new specs and starting the entire process again. The result: overspend and delay as organisations are forced to alter existing work at a late stage in the project’s life.
Ok, that’s the waterfall method but tell me what agile does?
Scrum, one of the most common agile approaches, throws away the idea of delivering a finished system in favour of deploying it in chunks. These chunks or iterations will run for two to four weeks, at the end of which the dev team should deliver software that is potentially ready for use. Each software change will be focused on meeting a particular business need. The result is the delivery of regular software updates, rather than the organisation having to wait years for a entire system to be delivered.
And that’s better why?
Many reasons. A key benefit is that agile gives end users an ongoing input into software development and allows them to help keep projects on track. A product owner, who knows the business outcomes that the project needs to deliver, is appointed to collaborate with the dev team throughout the project’s life.
Upon delivery of each software update the product owner will…
…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 Salesforce.com. 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.