In any project, from a school project to the most detailed software development project, you will know more about it at the end than the beginning. It’s hardly rocket science. So why, when thinking about the implementation of detailed software development projects, do so many companies plan every micro detail at the very beginning of the project? Surely it makes sense to perform the first part of the project, define short-term requirements, examine results and conclusions, and then plan again for the next stage. Agile software development, producing software in short iterations, is the common sense approach to software development. It minimises the planning at the initial stage with the realisation that a more fluid approach, with planning at each stage of the development, would guarantee the best results. By constantly testing and integrating the results at each stage, the final product can be released earlier if it is ready, or changes can be made that will lead to an implementation that is both rapid and successful.

The more traditional ‘waterfall’ approach to software development is a process-led approach. The stages of the project are well defined and the requirements are set in stone at the start by analysts – the design at the outset, followed by blueprint documents, then the construction, integration, testing and finally deployment to customers. As any software developer will know, this is the traditional way that software is developed. But it is an approach that lacks the flexibility that would allow the project to evolve with the changing needs of the user.

The agile approach is different; the philosophy is based on the idea that if projects are developed in short iterations (two to three weeks), at the end of which the user can see a working version of the software for sign-off before progressing to the next iteration, then the overall project will be much more flexible. The methodology advocates that the best way to measure progress is through the constant development of working software. At the outset of a project, everyone knows that the requirements will change. No-one knows exactly how the software will work and the agile methodology embraces change and uses it to progress. By predicting only a few weeks in advance, this minimises wastage in terms of time spent on document writing at the outset. It also takes into account the everyday variables that can affect any project, for example personnel changes or problems, technological developments and regulatory changes (particularly in the financial services sector).

The strengths of the agile development methodology are based on the flexibility of the agile offering. Deciding what a project will look like a year prior to its completion does not take into account the industry changes or the changes within the customer organisation that could affect the project. If the customer changes its mind after nine months, this might require a complete project re-think under the waterfall methodology, but the adaptability of the agile methodology allows change to be made based on the requirements of the customer. Also, the fact that a client can assess the development and suggest future plans and changes after each iteration, thereby developing a deeper understanding of the project’s requirements, means that changes can be made throughout the project’s lifespan.

Another advantage of the agile methodology is the constant testing and integration. The test-driven environment - the project will be tested during each iteration - ensures that any faults can be corrected on a regular basis. Therefore after each iteration, progress can be viewed and measured and the next stage can correct any faults, whereas testing towards the end of a ‘waterfall’ project may find a huge problem with the system that needs widespread correcting. This can prove very costly and hugely inefficient. Alongside this is the advantage of an integration of teams (both teams at different supplier locations and integration between end user and supplier teams) – the constant testing and development will mean a close collaboration between end user and supplier who will meet face-to-face on a regular basis to ensure that the next stage of the project is a success.

But it’s not all advantageous - there are limitations to the agile development methodology. For one, it is very dependent on the structure of the client organisation. The customer has to have an agile organisational structure, with internal process that have the flexibility to allow for constant change in a project. If a customer has a rigidity of structure, whereby all projects are strictly planned (and therefore predictable) from beginning to end, then attempting to put in place a methodology that embraces constant change and development is likely to cause internal confusion and consternation.

The need to get customer buy-in at every stage can be a potential difficulty, particularly for customers who are inherently used to the waterfall methodology. Whereas in the waterfall methodology the customer involvement is limited to two stages – beginning and end - the requirement for on-going participation and input in the agile methodology may prove problematic for some organisations. If the supplier is trying to develop software using the agile methodology, but the customer is not getting involved, the benefits are immediately lost. It can also prove costly if the customer is continually suggesting changes – the project can quickly grow larger than its original scope. Suppliers have to take this into account when costing projects of this nature.

Another drawback of agile is that if one part of the project does not work, the whole project can become bottlenecked. This is especially problematic if the issue is within the development team, who are central to rapid progress. If a bottleneck does occur, it wastes the time of everyone involved in the whole project.

There is no doubt that the agile methodology is gaining popularity. In the early twentieth century Henry Ford revolutionised the automotive industry with the invention of just-in-time production, a methodology implemented to improve the ROI of a business by reducing in-process inventory and its associated costs. Just-in-time was a methodology whereby a series of signals, or Kanban, automate the production process into making the next part of the car. Although the progress and development of agile is not perfectly analogous, the philosophies do have similarities; each element of the agile software development is done in small iterations, each iteration self-contained but having a knock-on effect on each other. The take-up of agile seems to be following a similar trajectory to just-in-time too. Just-in-time has proved a tremendously successful and popular methodology, although for several years it was only taken up by very few manufacturers – mainly Ford and then Toyota. However, like agile, sceptics needed very clear proof of its benefit before its more widespread adoption.

Agile is becoming more widespread and sceptics are being won over. The realisation that you have the most information at the end of the project, as opposed to the beginning, is infiltrating into mainstream software development methodology, whilst doubters amongst end user organisations are realising that a shift in internal ideology can create a more rapid and successful deployment of software. Although many organisations are tied to the more traditional waterfall methodology, whose main benefit remains the predictability of delivery, agile – the challenger methodology – is becoming ever more popular due its (potentially) more rapid delivery and the greater involvement of the end user at each stage in the development process.

For more pieces like this, subscribe to our email newsletter.