introduction

They say there are many ways to skin a cat (not us – we love moggies).  Equally, there are many ways (or methodologies) to develop software.  The most common software development methodologies used are waterfall and agile, and the contractual framework for the project should change depending on which methodology you use.

Waterfall software development is the more common, and traditional, delivery method.  If you are working on a big NZ software development project (especially a public sector one), it is likely the contract will follow waterfall.

Agile is the up and coming contender and we think its use will continue to grow.

In this guide, we look to explain how agile works and discuss the things you need to think about in your ICT contract if you want to use agile (and get customers to agree to that too).

waterfall

Let’s briefly look at waterfall.  The waterfall approach gets its name because it follows a step-by-step or linear process.  Once one stage of the project is finished, the next stage starts.  As a result, the process looks like a waterfall.

The main feature of waterfall is that key aspects of the project are usually agreed upfront or during the early stages of the project, e.g. price, specifications, and milestones.

Given this, the biggest benefit of waterfall (in theory) is certainty – the supplier knows what it is in for and can better manage customer expectation, and the customer knows what it will be getting.  On the other hand, the method is rigid and assumes that, once each stage is finished and signed off, that stage will not need to be revisited.  This is meant to manage risk because you shouldn’t progress to the next stage until the current stage is accepted.  But, this is impractical in practice.  In reality, latent issues can become apparent in later stages of ICT projects.  If resolving the issue involves re-engineering deliverables completed in earlier stages, the issue can be hard (and expensive) to fix, time-consuming and can create knock-on effects.

We think the biggest issues with waterfall are:

• it simply doesn’t sit well with the fact that large ICT projects evolve during the lifetime of the project, e.g. because of emerging (and additional) requirements due to a better understanding by the customer of what it requires after completing the design process, or the issue of unknown unknowns. While most ICT project contracts have a change control process, these processes are clunky and usually one-sided in favour of the customer, meaning a supplier can’t obtain change when it is fair to do so
• it assumes the customer has the skills, experience, and knowledge to supply a complete list of requirements for the solution the subject of the project. While not a problem for all customers, many do not run major ICT projects on a regular basis and don’t have the right skills to assess its requirements and manage the project.  This can result in an over-reliance on the supplier (who is often called the expert by a customer, despite the fact that the supplier is an expert in IT solutions, not the customer’s business).

Despite these issues, the waterfall approach remains favoured by NZ customers who find it hard to look past the safety net it seemingly provides.  The problem is, this safety net is often window-dressing and waterfall projects have a high failure rate because of the issues we discuss.

genesis of agile

Most people think agile is the new kid on the block but its underlying concepts have been around for over 45 years – since the early stages of computers and, of course, issues arising with ICT projects.

The first published discussion of agile was in 1970 when a Lockheed engineer, Dr Winston Royce, presented on Managing the Development of Large Software Systems.  Funnily enough, his presentation and paper are often quoted as supporting waterfall.  But, if you look closely at what he said, his basic premise was that software should not be developed like a car on an assembly line, i.e. it shouldn’t be developed sequentially – like waterfall.

Despite early advocates of agile, the method really took off after the publication of the Manifesto for Agile Software Development 2001.  The Manifesto’s key values are:

• individuals and interactions over processes and tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following a plan.

so what is agile?

Unsurprisingly, agile gets its name from the approach the method takes, which is more agile and responsive than the rigid waterfall approach.  Agile’s framework enables a project to easily and quickly adapt as it progresses.

A couple of warnings before we describe how agile works:

• agile has its own lexicon which you’ll quickly become familiar with as you work with the method. We chat about some of the more common phrases below
• agile comes in a variety of guises, which while generally following the same approach, have key variants. Scrum, Kanban, Rapid Application Development and XP (extreme programming) are all part of the agile family.  Unfortunately, life is finite, so we haven’t distinguished between those variants – apologies to the purists.

Agile is an iterative approach to software development.  In any project, work is completed in small, bite-size pieces, often called sprints.  Ironically, a sprint can look remarkably like a mini waterfall project.  A sprint lasts a short period of time (anywhere from a week to a month) and, at the end of a sprint, the deliverables the subject of the sprint are tested and reviewed, and then decisions are made on what to include in the next sprint.  Daily (but short) stand up meetings are often held to discuss progress and issues.

Each requirement (often called a story or a unit of a story) for the solution, and any issue or defect arising in a previous sprint, is included in a product/system backlog, and each item is given a priority.  The customer has the ability to re-prioritise items throughout the project (because something that seemed important on day 1 may not be on day 200).  For each new sprint, the customer (working in collaboration with the supplier) determines what is included in the new sprint.  This is generally based on the current high priority items in the product backlog (e.g. high (must have), medium (will preferably have), low (nice to have but not necessary)).

As a result, agile is more flexible and collaborative.  Customers (through a product owner) are actively involved in all stages of the project and, in particular, the review and decision-making stages.  The supplier receives customer feedback (and knows customer expectations) sooner rather than later.  Issues can be identified, prioritised in the product backlog and addressed as they arise.  This has several key benefits:

• issues and bugs are usually found and addressed earlier
• the solution can change to incorporate the customer’s changing views during the lifecycle of the project or to incorporate changing technology.

Agile is often run on a time and materials basis.  Because the solution can change dramatically during the life of a project, having a fixed price can be tricky.  Of course, this terrifies customers, but there are ways to provide comfort on this point.  We discuss this under the heading Your own contract – sanding down the rough edges.

pros and cons of agile

pros:

• flexibility – changes may be accommodated as the project progresses. Agile is particularly useful where the customer is unsure of its requirements – these can be developed and adapted during the project
• the customer can see results early on. In some instances, the customer can start using a basic (or beta) version of the solution early on too
• good for a customer who understands the outcomes it wants, but is unsure of its specific requirements for the solution.

cons:

• success usually requires each party (i.e. the customer as well as the supplier) to be familiar with how agile works and to have personnel with the right skills and experience to properly run an agile project
• lack of certainty – often the initial requirements for the solution are high level, which can cause customer anxiety. That said, it’s possible to draft into the contract protection mechanisms for this (discussed below)
• sprints are usually run on a time and materials basis which can be off-putting to the customer. Again, controls can be drafted into the contract to provide comfort on this.

Kindrik Partners is a fan of the agile methodology.  We think agile projects are more likely to be successful than waterfall ones (in terms of meeting timeframes and budgets, and providing customers with the solution they thought they wanted), although there are a couple of caveats:

• while the solution may come in within budget, the administrative and management costs of an agile project can be higher for the customer because it needs to provide more input and resource during the project – but this is still preferable to having a failed project or major budget blowouts
• a customer should only use agile with suppliers who have a proven track record of successfully running agile projects – someone without the right experience and skills could counteract all of the benefits that the method provides.

agile and what to think about in your contract

There are two sides to the coin when thinking about contracts for agile projects.  Usually, you’re either using:

• your own contract (likely to be based on agile). In this case, suppliers often need to include additional protections for the customer to give the customer comfort over what is normally perceived as a supplier friendly approach
• the customer’s contract (likely to be based on waterfall). Generally, this means the contract needs to be adapted to enable agile.  What should you focus on?

your own contract – sanding down the rough edges

To get a customer over the line on using the agile approach, it’s a good idea to think about the key motivators for the customer and find ways to mitigate any concern.  This often involves importing some waterfall-type contractual elements and adapting them to work in the agile context.

There is no one way to do this, but there are usually some easy solutions available to address any customer concern.

how will I get what I want if the contract doesn’t comprehensively list all of my requirements? 

To address this issue, we suggest that an agile contract sets out:

• what is the intended outcome of the solution or what are the requirements/stories to create a minimum viable product – essentially, the high priority must haves for the solution
• how the parties will measure or confirm that the outcome and the requirements are met – or at least include a process to measure this
• that the product backlog (which lists all of the requirements for the solution) is developed early on, listing all of the then-known requirements and is transparent that the customer will have the ability to change priorities in the backlog. However, the changing of requirements and priorities can have knock-on effects to pricing and timing, so it’s a good idea to be up front with the customer about this risk (which can be easily managed by the customer).

I need certainty on how much the solution will cost and when it will be delivered.

To address this issue, the agile contract can:

• include longstop delivery dates and capped budgets. As a supplier, we think it should be possible to agree to this for a minimum viable product.  Of course, dates and caps need to be subject to reasonable qualifications, e.g. a customer can’t expect to increase its high priorities to a significant degree, unless there is a reduction in scope or increase in price
• include a process to address the knock on issue of agreeing a set delivery date and budget cap, which allows that date or cap to change where it is fair to do so. E.g. if the supplier has worked hard to meet the date and/or cap, then the customer should not unreasonably withhold its agreement to an adjustment.  To ensure balance (and to get the customer over the line on allowing the supplier the right to request a change to the longstop date or cap), the supplier’s right to request a change can be limited to pre-agreed circumstances, e.g. where the supplier (i) is not in breach of the contract; (ii) has kept the customer informed of progress (including progress against budget); and (iii) can justify the adjustment on reasonable grounds.  Also bear in mind that, instead of changing the dates/caps, another way to address this timing/cost issue is to remove lower priority units or stories from the backlog, i.e. to reduce the scope of requirements for the solution.

given the requirements for the solution are not static, who decides what?

As a general rule, the agile methodology is very good at setting out how decisions are made and by whom.  The success of the agile is dependent, to a large degree, on identified individuals (e.g. the product owner (for the client) and scrum master (for the supplier)) having clear decision-making authorities, without the ability of a more senior person to second guess or override a decision, which would be counterproductive.  This is particularly important given key decisions can be made on a daily basis (e.g. at the stand up meetings).

importing agile into a waterfall contract

In many instances, agile suppliers need to work within the constraints of the customer’s standard terms.  But more often than not, those terms assume the waterfall approach will be used for a development project.

While (thankfully) most of the boilerplate clauses in a standard ICT contract will fit with either method (e.g. liability and IP clauses), suppliers should always read the contract to make sure it fits with the agile approach – as some common waterfall clauses cause inconsistencies.

Clauses that commonly need to be tweaked to fit with agile include:

• standard definitions (e.g. Product, Solution, and Specifications, or similar phrases). Often, in the waterfall context, those definitions are linked to the details set out in the contract when it is signed.  With agile, these details will evolve over time.  You want your contractual obligations to link to the evolved product and evolved specifications, not the static descriptions at the start of the project
• the change control process and variation clause. Often a contract states that change may only be made via change control.  However, in the agile context, changes can happen daily and requiring those changes to be put through this formal process would be counterproductive.  We suggest change control is retained (as it can still be useful where very big changes need to happen) but clarification is added that the parties can also make change in accordance with the agile method.  This also applies to a variation clause – make sure it allows changes in accordance with the agile method
• standard warranties. Normally these warranties link to the solution meeting the specified requirements.  Of course, these may change with agile.  These types of warranties should be updated to refer to requirements as they evolve under the agile process
• liquidated damages provisions. We’re not a fan of LDs in any event because fault in ICT projects is generally not black and white.  But, given the fluid nature of agile projects, a customer’s justification for LDs becomes even less clear cut.  Certainly, any LD provision (e.g. for a longstop date) needs to be clearly qualified (e.g. LDs don’t apply if the failure to meet the date is due to the number of changes to the solution, etc.)
• any acceptance testing process. The process will need to align with how acceptance will work under the agile approach, e.g. it will be incremental in nature, and not big bang
• the priority of documents list (i.e. which part of the contract prevails over another part). Usually a development contract will have the master terms prevailing over any term in the SOW or other document.  However, often tweaks made to a waterfall contract to enable agile are done at the SOW level (as it’s often easier to have special terms in the a SOW relating to agile than to change the master terms).  If this is the case for you, it is important that the SOW special terms will override any inconsistent term in the master terms.

Customer contracts often take the form of umbrella master terms with a series of schedules relating to each type of activity that can be performed under the master terms (e.g. development (usually waterfall), support, licensing, other professional services).  Another simple way to enable the use of agile under these terms is to propose a separate development schedule that relates to agile.  That way, a SOW for a project can be created under the agile schedule, instead of the waterfall one.

Finally, the statistics on ICT contracts and their successes (or lack thereof) are sobering to say the least.  Project failures or project-threatening issues are not black swan events (even though both the supplier and the customer on a project often feel they are the only ones to have suffered these issues).  Most of these failures have happened on waterfall projects.  Many customers still cling dearly to belts and braces waterfall contracts that purport to give them a raft of legal remedies.  But those contracts regularly fail to give them the one thing they want – a properly working solution.  We think it’s time for a mind-set change, and being open to trying different methods like agile is a great start.