Making software development contracts Agile

Software development projects delivered using 'Agile' methodology (rather than the more traditional 'waterfall' approach) are becoming increasingly mainstream.  This article looks at the key differences between Agile and waterfall projects, the benefits and risks of Agile projects and how traditional software development contracts might need to adapt for Agile projects. 

What is Agile development?

With a traditional waterfall approach, a development project is divided into a sequence of distinct phases: initial planning, definition of customer requirements, design of the solution to meet those customer requirements, development/build of the software code, testing and deployment of the finished product into the production environment, and a formal procedure for overall customer acceptance at the end of the project.  The waterfall approach assumes that each phase of the project can (and should) be completed before starting the next phase, and that the customer will not receive any working deliverables until the project is completed. 

By contrast, Agile development projects feature repeated short development cycles (usually referred to as "sprints"), including planning, design, development, testing and deployment activities, each covering a small subset of the overall requirements, and meaning that useable software code can be delivered to the customer more regularly throughout the life of the project. 

Differences between Agile and waterfall projects include: 

  • There are no detailed business requirements, or rather, the methodology allows those requirements to develop as the project progresses towards a high-level project objective.  The parties typically work to a "Product Backlog", which lists in order of priority the customer's non-technical requirements for the solution expressed as "user stories" (eg, "As an <analyst>, I want <a live data feed> so that <I can make decisions in real-time>".

  • The Product Backlog of requirements is not fixed or subject to a formal change control procedure as is common for waterfall projects.  Instead the customer may reprioritise the list of requirements or add or remove requirements at any time between sprints.

  • Project management is shared by the customer and supplier through regular planning and review meetings before, during and after each sprint.  In a traditional waterfall project, the supplier is usually tasked with the majority of project management activities and must deliver the project according to the agreed project plan.  In Agile projects the customer will provide an estimate to the supplier of the overall project duration based on an estimated number of sprints, with each sprint being for a specified duration (often between 2 to 4 weeks), but the actual duration of the project is dependent upon how long it takes to complete all of the items on the Product Backlog.  The consequence of this is that the customer needs to be comfortable with the risk of timetable slippage, and the supplier is generally not measured against fixed milestones as they would be for a waterfall project.

  • Waterfall projects usually have a formal acceptance procedure at the end of the project, but in an Agile project, testing and acceptance against the shortlisted requirements is carried out during each sprint.  Any outputs that fail to achieve acceptance during a sprint go back into the Product Backlog and must be redelivered during a later sprint. 

What are the risks of Agile?

The key advantage of the Agile approach is that the software design can remain flexible and adaptable over the life of the project, and reflect any changes to the customer's requirements as they evolve.  By contrast, a waterfall project can lead to a system being developed that conforms to the requirements that the customer had in mind at the outset, but which might become less relevant over time (particularly for a lengthy project).  Agile will not be appropriate for all development projects, but works particularly well where a customer is looking to rely on the supplier to help define how the final solution should work.  It also avoids a common pitfall of traditional development projects, where the supplier is getting stuck on a particular phase can stall the whole project. Agile development allows the supplier to move onto the next phase and deliver useable code to the customer at regular intervals. 

That said, Agile projects can pose more commercial and legal risk to the customer than traditional waterfall projects if not managed properly.  This makes choosing the right supplier even more important, but also puts more of an onus on the customer to remain involved in the development process and engage collaboratively throughout the project.  Even when managed well, risks can remain: 

  • Having less detailed requirements might encourage supplier innovation, but can equally lead to ambiguity and misinterpretation.

  • Evidential issues might arise from the collaborative approach, such as determining which party is responsible for a defect or delay.  Was a failure of the supplier to achieve a critical requirement a consequence of the priority given to that requirement by the customer, or if the customer has members of its personnel on the development team, was the defect caused by the customer's or the supplier's personnel?

  • Repeatedly adding incomplete or unaccepted items from a sprint back into the Product Backlog for remedial work may result in cost overruns and overall timetable slippage. 

For public sector customers such as government departments, a specific concern may arise from the supplier being unable to accurately price Agile projects at the outset.  This is due to the flexibility of the approach and not having detailed customer requirements, which in turn means the supplier might only be able to provide a loose estimate.  This may make it difficult for the customer to properly form its business case, which is a key requirement for public sector procurement. 

What to include in your Agile development contract

Early termination

A right to terminate the contract early can help in avoiding the potential for increased project costs or delays, and incentivise the supplier to perform properly.  For example, the customer should seek to have the right to terminate after every Sprint, but may negotiate this with the supplier so that the customer only exercises this right in respect of critical requirements or due to cost blowout.  Any right to terminate should include a right for the customer to take what has been delivered (together with any necessary licences) to a replacement supplier. 

Costs for remedial work

Ensure that the supplier bears the cost for any undelivered or unaccepted requirements that go back into the Product Backlog after a Sprint.  This will help incentivise the supplier to ensure it delivers successfully under each Sprint. 

Performance targets and delivery

While some developers might argue that it's not in the spirit of an Agile project, customers should set clear performance targets and goals for each Sprint, such as the minimum number of requirements that must be successfully delivered.  The contract might also link payments to the achievement of these performance targets (eg, by reducing the instalment to be invoiced at the end of each Sprint on a pro rata basis if the supplier fails to deliver all of the requirements, or withholding a certain percentage of the overall project fee until the project as a whole has been successfully completed). 

Acceptance criteria

Compensate for the use of non-technical "user stories" to define the requirements by ensuring that the acceptance criteria applying to each Sprint are described in detail. 

Project roles and responsibilities

Ensure that the roles and responsibilities of the project team are clearly defined in the contract.  Selection of appropriately skilled personnel (on both sides) will be critical to the success of the Agile approach, and the contract should therefore include a process for determining how the development team and other key personnel will be selected and – in the case of the supplier's personnel – retained for the duration of the project.  Customers should also be mindful of creating evidential issues in establishing a warranty claim or protection under the supplier's IP indemnity if the customer's own personnel have had a significant role on the development team.

Nakedbus laid bare

The High Court has recently issued its first decision about use of keywords identical to another party's registered trade mark rights in the context of Google Adwords – see InterCity Group (NZ) Limited v Nakedbus NZ Limited [2014] NZHC 124.  This is the first decision in New Zealand about keywords, after similar decisions in overseas jurisdictions in the last few years. 

The High Court found that by using the keywords "inter city" and displaying Google advertising, Nakedbus had infringed InterCity's registered trade mark, breached the Fair Trading Act 1986 by misleading and deceiving consumers, and had engaged in passing off.  While the judgment is only interim and subject to appeal, the High Court found that InterCity was entitled to declaratory and injunctive relief and a further hearing to determine an account of profits. 

Google AdWords and the selection of keywords is a powerful marketing tool used by many businesses around the world to promote their business via the Google search engine.  The High Court decision therefore provides some welcome guidance to New Zealand users of Adwords and their use of keywords, especially when the keywords are identical to those of direct competitors. 

The High Court found that use of keywords identical to a registered trade mark did not amount to trade mark infringement because Nakedbus' use of the InterCity sign was not "likely to be taken as being used as a trade mark".  However, the Court found there was trade mark infringement by Nakedbus in the Google advertisements generated by the keywords, which the Court found to be misleading to consumers.  The Google advertisements made statements such as "inter city buses from $1 – We'll beat any inter city fare" and were considered ambiguous as consumers were likely to believe they were InterCity advertisements or were otherwise connected to InterCity.  For similar reasons, Nakedbus' Google advertisements were also found to be misleading and deceptive under the Fair Trading Act. 

While the decision may be appealed by Nakedbus, it indicates that use of identical keywords does not in itself amount to trade mark infringement, but that Google advertisements generated from the keywords might still infringe, and so land advertisers in hot water.  For these reasons, users of Google Adwords who use keywords identical to those of their competitors need to be very careful about what the messages in their Google advertisement tell consumers, especially as to the origin of goods or services.

Judicial review decision stops Ministry of Education in its tracks

Telco Technology Services Limited v Ministry of Education [2014] NZHC 213 [19 February 2014]

In a highly unusual move, the High Court last week granted Telco Technology Services Ltd (Telco) an interim injunction to prevent the Ministry of Education (the Ministry) from appointing another company to exclusively implement the final phase of The Schools' Network Upgrade Project which is designed to provide 97.7% of schools with ultrafast broadband by the end of 2015. 

In its RFP for the final phase of the Project, the Ministry highlighted its intention to select two or three suppliers to deliver the services and asked tenderers to answer questions related to capacity on the basis of winning a contract for a maximum of 50% of the available schools. 

Despite this intention, the Ministry has since commenced contract negotiations with a single preferred tenderer on the basis that tenderer will receive a 100% allocation of all remaining schools. 

Telco claims that the pricing in its proposal was based on a 50% share of the available schools, and that had it known only one provider would be appointed by the Ministry, it would have significantly changed the basis upon which it priced its proposal. 

The High Court found that there was a serious question to be tried in relation to Telco's application for judicial review.  Collins J asserted that “judicial review is available in a commercial tendering context where the Crown may have breached procedural expectations in a material way to the detriment of the tenderer”.  He then went on to state that “it is reasonably arguable that the Ministry breached its fundamental procedural obligations when it failed to give Telco the opportunity to be assessed on a fair and equal basis with the successful tenderer”. 

Given that the Courts are usually reluctant to judicially review commercial decisions, this interim decision is quite interventionist.  The substantive proceeding is due to be heard in March.

Six easy ways to strengthen a clickwrap contract

Given the prevalence of contracts formed over the internet every day (for example, every time someone buys goods from an e-commerce platform, or downloads an app), it might seem odd that questions are still asked about the enforceability of online contracts.  At law, simple contracts can be formed over the internet in just the same way as any other contract or context.  Unless special legal requirements apply (such as for guarantees or contracts for the sale of land), all you need is an offer, acceptance of that offer, the intention to create a binding relationship, and some kind of consideration. 

One common way to do this, for example when selling something online, is to require the customer to click "I accept" to a standard set of terms before completing their purchase (this is called a "clickwrap" contract). 

Although a court has never had to look at the question in New Zealand, overseas courts regularly uphold clickwrap contracts, so long as the basic ingredients of contract formation are present.  However, where clickwrap contracts fall down is often around adequate notice of the terms of the contract.  It's hard to argue that a buyer has accepted a standard set of terms (and indicated their intention to be bound by them) if they have not had a real opportunity to read and consider the terms before accepting.  And if there is no proof that adequate notice has been given (and that the buyer in question has actually clicked the "I accept" button), then it can be very hard to enforce a clickwrap contract in court. 

To stand you in good stead if you ever do need to take action, here are some easy suggestions to help strengthen the enforceability of your clickwrap contract: 

  • Show users your terms on-screen (rather than via a hyperlink). Make it easy to find your terms elsewhere on your website too (eg, link to them in your website footer).

  • Make sure your terms are clear and easy to understand. Avoid legalese at all costs.

  • If there are any unusual or onerous terms, make sure these are clear and up front (consider putting them in bold or right up the top of your terms). Make your terms balanced and fair (and make sure that they comply with mandatory consumer protection and privacy law).

  • Make it so that users have to scroll down to the bottom of the terms before they can click "I accept".

  • Give the user the option of accepting or not accepting the terms, and make sure that their selection is permanently recorded in a way that you can easily and reliably retrieve.

If you change your terms, make sure that users re-accept your new terms before they buy from you (or use your services) again

European court rules on hyperlinking

Sharing links is one of the most common ways of exchanging online content with others.  The act is so commonplace that it might seem odd that questions over its legality are still being considered.  In the highly anticipated Svensson judgment released on 13 February 2014, the Court of Justice of the European Union (CJEU) has decided that the owner of a website can use hyperlinks to redirect internet users to third parties' copyrighted content without infringing copyright.  The case involved a news monitoring service which supplied links to news articles on a number of websites. 

The main proviso to the determination is that the content must be otherwise "freely available" to internet users online.  Therefore, posting a hyperlink to content which is not freely available, such as content protected by a subscription, login page or pay-wall, is likely to constitute an infringement. 

The reasoning behind the CJEU's decision is that hyperlinking does not result in the material being made available to any "new public".  If a copyright owner has authorised their works on one publicly available website, this will be considered an authorisation for all internet users to access the content.

Although there is likely to be future discussion about what exactly "freely available" means, the decision potentially gives rights holders a new argument against third parties providing unauthorised links to infringing copies of content – applying Svensson, the fact that content is being made available to a "new public" might make it unlawful.

Record-breaking spam fine

The High Court has fined Image Marketing Ltd a record $120,000 for offences under the Unsolicited Electronic Communications Act (aka the anti-spam act).  Image Marketing admitted sending spam emails and text messages in 2009 and 2010 for its database products and mobile phone antennas and was prosecuted by the Department of Internal Affairs.  Media reports indicate that Image Marketing sent more than 500,000 emails and 45,000 texts in 2009

The birds and the bees - protecting copyright in the app marketplace

'Flappy Bird' was a devilishly simple gaming app that became a viral app sensation.  The popularity of the app spawned a multitude of 'Flappy' clones most notably 'Flappy Bee', which soared to number four overall on the Apple US app store even before the creator of Flappy Bird removed his app and opened the Flappy clone floodgates. 

As well as being similar to the Flappy Bird app, Flappy Bee was also visually almost identical to the 'Bee Leader' app designed by New Zealand developer Flightless.  Flappy Bee appeared to copy the Bee Leader app icon, main character and background visuals. 

This one incident illustrates the global arena in which app developers operate, and the irrelevance of national borders: the Flappy Bee app was created by a European app designer, inspired by the app of a Vietnamese developer, sold globally through a US app marketplace and appearing to infringe the copyright of a New Zealand app developer.  In circumstances like these, how does a small app developer even start to go about protecting their intellectual property? 

Unfortunately, there is no global copyright police force championing the legal rights of copyright owners the world over and the enforcement of copyright remains a private exercise.  Resort to the courts is not only often outside the budget of most app developers, but can often be a slow and territory specific system that can be out of sync with the global and fast paced world of app development. 

A pragmatic solution for those who consider that the copyright in their app has been infringed is to complain directly to the app marketplace where the infringing app is offered for download. 

The Apple and Google Play app marketplaces have simple, free complaints procedures for apps sold on their platforms that infringe the copyright in another party's work: 

Both procedures require the following to initiate a complaint: 

  • Identification of the copyright work claimed to have been infringed

  • Directions to where/how the copyright work is published (such as a URL location, or the title of a published work including a pinpoint reference to the material that has been infringed)

  • Identification of the material that is claimed to be infringing and the URL of the infringing app's location within the relevant app marketplace. 

Once a complaint has been submitted, Apple passes the details of the complaint onto the allegedly infringing developer, so that the parties can attempt to resolve the issue between themselves.  However, Apple does not commit to taking any action or passing any judgment.  Google does take a more active role in assessing complaints, and – as does Apple – has the right in its contracts with developers to remove from the platform apps which it considers to be infringing.  In practice, we expect it unlikely that either company would remove an app for copyright infringement in all but the most clear-cut of violations. 

As the Flappy Bee app story illustrates, these mechanisms can be effective – the Flappy Bee developer was ordered by the Apple app store to change the app's name due to its apparent attempt to leverage off the Flappy Bird phenomenon, and the app no longer uses the Bee Leader artwork, suggesting that Flightless was also able to find success using the complaints procedure.