Agile development can be risky

Agile is an iterative approach to project management and software development that helps deliver products faster.

Involving software development practices that emphasise adaptive planning, evolutionary development, early delivery and ongoing improvement.

In 2018 Spark, a New Zealand telecommunication company, proudly announced that it was "going agile" and told its employees that they needed to get onboard. The software as a service industry is high risk / high reward, so it is no wonder that Spark is reorganising itself. Agile development may help them to innovate faster while reducing the impact of sunk costs and technical debt.

The waterfall method

A major contributor to the high failure rate and inefficiency we have seen historically in the industry is the traditional ‘waterfall’ project management approach.

The usual process is: specification requirements – design – coding – testing and error detection – integration – deployment – maintenance.

All of the planning, design and budgeting is done up-front. Development follows, then testing. If time and budget constraints have not brought the whole operation to a halt, then the resulting product can finally be unleashed on the end user.

The problem with this approach is that the initial stages can be (and often are) flawed. Software development teams are not always equipped to properly understand end user requirements. They may be operating in a void, without relevant survey and user feedback data. The team is unlikely to break out of this void during development as end users will not get their hands on the product until after it's finished (usually at tremendous cost to the team). Users are not in a position to say if the product doesn't work until it is far too late.

With waterfall, a common complaint is that the user feedback loop is either non-existent or too slow.

Agile development

Agile takes a completely different approach. Instead of trying (and failing) to specify 100% of the product requirements and design up-front, agile focuses on delivering small at first, then on delivering iterative changes and improvements. Throughout this cycle the team is informed by and makes changes based on user feedback.

Here are the key stages:

• Sprint – a time-boxed period of coding / development.
• Sprint planning – establishing sprint goals.
• Daily scrum – each day during a sprint, the team holds a daily scrum, preferably at the same place and time, and not longer than fifteen minutes. The scrum is concerned with what each person is contributing to a present/future sprint and also what has been contributed to previous ones.
• Sprint review and retrospective – demonstrating the work from the current sprint and improving processes respectively.
• As another sprint begins, the product owner and development team select further items from the product backlog and begin work again.

The risks

While agile development has its benefits, there are some risks to be aware of. Large established organisations, in particular, face a range of legal risks as they transition to agile working.

Customer complaints

During waterfall development the customer can rely on traditional legal remedies in the event of a dispute, such as contractual damages, cancellation, or remedial work in the case of defects or delays. Agile development can frustrate these remedies as it can be difficult to determine whether there is actually any delay or defect when delivering such services. The flexibility of agile development means that such defects can be buried behind prioritisation decisions or poorly drafted acceptance criteria. A delay may be re-framed as insignificant by 'unprioritising' it and adding to the product backlog. Amending the definition of customer acceptance may mean that the project appears to be on-track. The informal nature of decision-making during this process can also make it difficult to gather evidence if there is an alleged breach of contract.

Time limits

Time, whilst fluid under agile development, is also bound to sprints and usually there are deadlines. In waterfall development the customer estimates the project duration, the number of sprints, and the overall timeframe for delivering the product. The customer and supplier may also formally agree to such a timeframe by specifying contractual deadlines that are negotiated before the agreement is reached. Agile may take some of this control away from the customer. Whilst setting time limits may be desirable for both parties in a traditional contractual setting; such limits may also undo many of the benefits of agile development and the rapid user-feedback cycle it enables. Having some framework in place to ensure contractual remedies is of course necessary, but to operate efficiently proponents of agile development are often faced with a higher degree of legal uncertainty.

Employment

Employment law requires that worker roles and responsibilities are defined (often in writing) at the outset and then adhered to throughout the period of employment. Employers are required to specify the work to be done as precisely as their business allows; and employees are entitled to rely on those specifications as they perform work. Some degree of flexibility is allowed by law, but requiring a worker to regularly carry out duties that fall well outside of their usual responsibilities is unlikely to be acceptable. Disputes, personal grievances, and even litigation may arise if an employer routinely crosses the line.

Agile development places an emphasis on personal responsibility and flexible working. Participants in a sprint may be required to perform work that falls well outside of their usual duties, in order to satisfy the urgent requirements of the project. Care needs to be taken when drafting employee job descriptions to ensure that the worker is familiar with (and comfortable with) the sometimes demanding requirements of agile development. Specify the scope of work that the employee is likely to perform in a manner that provides for flexibility, but without being vague. This is often as difficult as it sounds, so it is prudent to take advice.

Other risks

Other common legal risks to be aware of are:

• Not meeting specific requirements within the original timeframe - this may not necessarily be seen as a breach of the express terms of the contract (as the subject of the breach may have been added to the development backlog).
• Unclear acceptance criteria for a sprint – if the agile software development contract is unclear about acceptance criteria the parties can be left arguing over whether an element of the product is completed or not. Acceptance criteria may be described in detail in the contract so that there is no reliance on less formal descriptions that may be contained in user stories; but then again this approach may limit the flexibility that makes agile development so effective. A balance is required and it is prudent to take advice before setting the criteria.
• It is common for agile software development projects to go over budget. Leaving aside delays or quality issues that ramp up costs, if a customer walks into a project without clear goals then their eyes are likely to light up every time the developer says “hey, do you want the product to do this cool thing”. A lack of direction is very likely to cause problems down the road.
• Everyone needs to be involved. Developing software using agile methodology is an intense process. Agile is a collaborative process. All participants should be focused on the project and communicating with each other regularly. If a key member of the team suddenly goes AWOL then the project may grind to a halt and this is likely to frustrate the entire team.

Closing thoughts

Agile development can foster creativity and deliver customer satisfaction. It is important, however, to be aware of the potential pitfalls from the outset so that all parties feel satisfied with each stage of the process before moving forward. Agile methods require all participants to commit a significant level of time and resources. A lack of commitment or an inability to properly resource the project may result in disputes, that will ultimately diminish many of the benefits of agile that are discussed in this article.