A law firm which offers more

Call us: 0113 246 0622

Agile Software Development – a better way to develop software?

Comments

“Agile Software Development” is now seen by many as the preferred software development methodology. It is important to recognise how this approach to software development differs to traditional approaches and how to contract for it effectively.

Traditional Software Development – The Waterfall Model

In modern usage the term “Waterfall Model” has come to refer to any approach to the creation of software that is not an iterative approach (discussed below). There are different variations, but broadly a development project utilising the Waterfall Model will be carried out in the following stages:

• Requirements Gathering / Specification;
• Design;
• Implementation;
• Integration;
• Testing;
• Installation; and
• Maintenance.

Although the Waterfall Model does have its advantages, its fundamental flaw comes in the fact that it is very much designed for a perfect world. For example, it is highly unlikely that even the most thorough requirements gathering exercise will capture 100% of the requirements on the first attempt (requirements may only become apparent to users once they are presented with a version of the software to experiment with). It is inevitable that a developer will need to revisit previous stages as new issues become apparent (e.g. a fundamental design flaw is discovered during the testing stage).

The Waterfall Model also lacks flexibility. Development of software is usually subject to a number of external influences. Requirements may be altered or refined while the process is ongoing. Adhering to the Waterfall Model means starting again from the beginning of the process, and carries with it potential consequences such as missed deadlines and increased costs.

Agile Software Development – An Iterative Approach

Agile Software Development (the “Agile Approach”) attempts to address the above problems with the Waterfall Model. The fundamental feature of the Agile Approach is that it is an iterative approach. Variations of planning, design and implementation stages are repeated as many times as necessary until the software achieves the agreed upon criteria. In this way, the software “evolves” throughout the development process as it is tweaked and refined until the desired result is achieved.

The Agile Approach is not technically a method for developing software in itself, but rather it is the umbrella term for a group of software development methods that utilise an iterative approach. Some well known software development methods that are based on the Agile Approach include:

• Dynamic Systems Development Method (DSDM);
• IBM Rational Unified Process (RUP); and
• Scrum.

Broadly, all software development methods that follow the Agile Approach consist of discrete stages (“Iterations”) which are time boxed and repeated. Typically these are similar to the stages of the Waterfall Model discussed above. The key difference from the Waterfall Model is that testing of the software (ideally involving people who will be actual users once it is complete) comes much earlier in the process and is repeated in a number of Iterations. This allows user feedback and shifts in requirements to be identified and incorporated into the project early on. The process or repeating Iterations makes the Agile Approach much more flexible and much more realistic in the dynamic world of modern software development.

The Agile Approach is not without its detractors. The primary criticism is that it is often seen as inefficient (especially in larger organisations). The open ended nature of the approach can be seen as lacking certainty as regards meeting deadlines and budget requirements. For this reason many organisations often take a hybrid approach, combining the flexibility of the Agile Approach with the certainty and dependability of a firm project plan.

The Agile Approach and Contracts

The Agile Manifesto (produced by the Agile Alliance who first proposed the Agile Approach) states “customer collaboration over contract negotiation”. Although this is perhaps an admirable objective, the reality is that contracts (and their effective negotiation) are an essential part of any software development project. It is in the interests of both parties to ensure that the project is clearly documented, and that significant risks are addressed and borne appropriately.

As with any contract for software development there are a variety of issues to consider. Of particular significance to software development utilising the Agile Approach are:

Pricing model – generally, a time and materials pricing mechanism will favour the developer and a fixed fee will favour the customer. This is however not always true, and in the right set of circumstances, a properly designed fixed fee could ensure a higher return for the developer than charging on a time and materials basis. Often a hybrid approach can be agreed with elements of the project being fixed fee and other elements being time and materials;

Requirements changes – how are changes in the requirements going to be dealt with? How will changes in costs be apportioned? As requirements gathering is an ongoing process what will happen if the project is discovered to be fundamentally untenable?

Timetable – a truly Agile Approach makes a rigid timeline difficult to adhere to. Almost all development projects will need to deliver something by a specific date. Perhaps consider a hybrid approach with clear deadlines but also built in flexibility to account for unexpected project changes or problems.

Our commercial team have experience of drafting and negotiating software development agreements to assist a variety of clients. Should you require any further information, or an appointment to discuss a software development project, please contact a member of our commercial team who will be happy to speak to you.
 

Disclaimer: Anything posted on this blog is for general information only and is not intended to provide legal advice on any general or specific matter. Please refer to our terms and conditions for further information. Please contact the author of the blog if you would like to discuss the issues raised.