In any project, from school work 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.