Busting the myths of agile development: what are its real benefits?

Agile isn't necessarily faster or cheaper than waterfall development

Agile is a more complex issue than you might think

Agile is in vogue. While it's been around for well over a decade as a formal term – and even longer as a concept, some would argue – it has become increasingly important in recent years, particularly in the public sector, where it's now the default approach for running software projects.

Operating projects and programmes in this way – as opposed to the traditional waterfall method – represents a significant change, not only to the mechanics of the project teams, but right across an organisation. Because of this, it's important to understand agile, what value it brings, and, importantly, the role that the customer organisation needs to play to make agile successful.

The real value of agile

A common misunderstanding of agile is that it is cheaper and faster than waterfall delivery. The truth is much less clear cut – it can be cheaper and faster, but only if it is suited to the organisation and project in question. Where this is not true, waterfall may actually be cheaper, faster, or both.

The real value in agile is in fact in its flexibility and responsiveness to evolving business requirements, which ensures that the organisation gets a system that genuinely addresses its needs, rather than the system it thought it wanted at the beginning of the process (as would be the case in a waterfall project, where full requirements are defined at the start and remain relatively static). The reality is that business requirements evolve over time, and agile makes it easier for projects to adapt accordingly.

Moreover, the ongoing stakeholder involvement, which is central to agile, ensures that problems are identified and corrected as early as possible, thereby reducing costs and preventing any nasty downstream surprises for both customer and supplier.

Agile versus waterfall?

Another common fallacy about agile is that it is an all-or-nothing decision to use this approach. Ideally, it would be. However, in reality, hybrid projects that apply aspects of waterfall and agile are perfectly possible. For example, agile projects can exist within a larger waterfall programme. While this may not deliver the full benefits of agile, this approach can provide organisations with a stepping stone to agile development, or enable more effective development for parts of a larger project or programme. We will look in more detail at the implications of running agile within waterfall-style contracts momentarily.

Changing customer responsibilities

One of the most important things to understand about agile is how the responsibilities of the customer organisation differ from what is expected of them during waterfall projects.

Firstly, the organisation needs to appoint a knowledgeable and empowered individual to form the link between the development team and the wider organisation – the Product Owner, in Scrum terms. This individual is typically a business analyst with experience of project management, and their role is to define the vision for the project, set the priorities for features being developed, plan the project iterations and form the link between the project team and the wider organisation.

They are also responsible for brokering the conversations between different parts of the organisation to ensure business needs are met and, where necessary, compromises reached and expectations managed. The importance of this role must not be underestimated, and it is vital that an appropriate individual is selected for it. They need a deep understanding of what the job involves, must have a good relationship with the various stakeholders, know the business needs inside out and be able to make quick, appropriate decisions about the direction of the project.

Secondly, the success of agile depends on effective planning by the Product Owner, and to enable this, the organisation needs to have delegated sufficient authority to the person in this role, to enable important decisions to be made quickly. The iterative nature of agile and the need for regular releases to the customer mean there simply isn't time to wait for something to be discussed at next month's management meeting. If everything needs to go through several levels of signoff, this will strangle the project and wipe out any benefits that agile would otherwise deliver.

Thirdly, the success of agile depends on getting regular feedback from stakeholders. The customer organisation needs to understand this and make the appropriate individuals available at the right time on an ongoing basis, rather than simply at the end of the project delivery. This ensures that any concerns are resolved as they arise, and helps the project progress smoothly.

Understanding leads to success

It's only by understanding what agile is and the value it can bring that organisations can determine whether it's the most appropriate development approach for their particular project or programme.

  • Matthew Du-Feu is an experienced software developer, Product Owner and Scrum Master, who has led agile teams delivering complex, high security software

Article continues below