Development Projects in an Agile World

Introduction 
It goes without saying that the pace of technological change and innovation is accelerating. The acceleration of development and innovation also means that in the information technology sphere the value of specifications quickly deteriorate. The University of Missouri completed studies of the value of a set of contractual specifications for products or services. In 1980 the half life of a specification was 10-12 years, in 2000 it was 2-3 years and 2014 it was around six months.

In an environment of swift, often disruptive innovation, organisations seeking to compete in a rapidly changing market place need to revisit the manner in which they engage. Naturally, if the model for engagement changes then the form of contracting should follow.

This article discusses at a general level an alternative engagement method which seeks to provide adaptability by examining the dominant engagement method and comparing it with the alternative agile or evolutionary method.

Waterfall Engagement Method
The dominant development engagement method is often referred to as the 'waterfall' method. As the name suggests, this method broadly anticipates a cascade of sequential steps in development from planning to design, coding, testing, and finally, deployment. Underlying this method are various assumptions concerning the development project including that:

• the project will often have a fixed duration and price
• a customer's requirements are thoroughly and comprehensively understood and will remain static throughout the duration of the project 
• the specifications developed to respond to those requirements will also be comprehensive, detailed and static
• the project will involve minimal, if any, variation to the requirements, specifications, project plan or price throughout the project.

Inherent in the waterfall method is the belief that every development project involves well defined initial requirements and specifications so that after an agreed period of months or sometimes years, a supplier can provide a customer a stable, fit-for-purpose product which fulfils all of the requirements specified by the customer often years previously at the price agreed by the parties.

As anyone involved in development will attest, development projects are rarely as utopian as this assumption supposes. For example, while customers often have broad objectives, it is difficult for them to evaluate specifications to determine if those specifications will fulfil those objectives. Conversely, suppliers rarely have sufficient information in the necessary detail to be able to provide a project without variation or to estimate accurately. Even skilled and experienced suppliers will confront problems in the development phase. Customer requirements inevitably change over time and the functionality initially requested is often unwanted or redundant at the end of the project.

Given the assumptions described earlier, contracts used for waterfall projects predictably focus on issues which are often inimical to a close and collaborative relationship between suppliers and customers. Customers expect suppliers to go away and produce, over a specific duration, a certain product for an agreed price. Sometimes this becomes a 'set and forget' relationship. Unsurprisingly, customers are often disappointed to find what is delivered is not consistent with initial requirements or those requirements are redundant once the project is completed. Some of the most expensive system integration failures have been through long run, waterfall style methods (just think of some of the efforts that our large banks have gone through in large enterprise resource planning (ERP) projects).

Due to the focus of the contract in providing a pre-determined product to certain specifications, change is treated as an exception rather than the rule. The contract does not envisage and accommodate an assumption that software development is often evolutionary. Delivery may be technically correct but users in testing raise 'new' issues not originally envisaged in the initial requirements phase.

In this environment, with these dynamics, contracts are designed to focus on risk mitigation, ensuring that mechanisms are agreed to hold the supplier to performance to a timeline and outcome. Because waterfall projects often have low transparency and long durations, the consequence of failure are significant. Consequently, there is arguably a disproportionate focus on liability and indemnity provisions and mechanisms to penalise slow or bad performance. Provisions are introduced to allocate responsibility and cost to parties who fail to perform on time and in accordance with the contract.

Without mitigation these dynamics manifest themselves in an adversarial relationship between the supplier and customer and promote 'gaming behaviour' like suppliers inflating prices to account for inherent uncertainty and unpredictability. Indeed, some suppliers anticipate that profits in the project will be provided through the change process and tender on this basis. The efforts to mitigate risk in waterfall projects can be at the expense of actually establishing an engagement which facilitates customers achieving their objectives, with suppliers being appropriately rewarded for their effort.

Agile Engagement Method
The agile or evolutionary development method seeks, in part, to address the deficiencies of the waterfall method by establishing a different engagement model.

The tenets of the agile engagement model are summarised in four statements in the Agile Manifesto: 

1. individuals and interactions over process and tools 
2. working software over comprehensive documentation
3. customer collaboration over contract negotiation
4. responding to change over following a plan.

These statements encapsulate principles which are fundamental to agile methodology (agile). They focus attention on individuals and interactions, rather than strict compliance with process and tools. In particular, unlike waterfall projects, agile anticipates regular and close collaboration across supplier and customer groups. Rather than an emphasis on developing comprehensive and detailed requirements and specifications to be rigorously followed, agile focuses on delivering small increments of deployable working items. Agile anticipates change as an inherent part of software development and eschews following a pre-determined plan at the expense of adapting to provide useful outcomes.

Agile Contract Elements
The agile or evolutionary development method seeks, in part, to address the deficiencies of the waterfall method by establishing a different engagement model.

To better understand and illustrate the agile methodology, set out below are key elements which we anticipate would form the contractual elements to be incorporated in an agile contract.

a) Project or Product Vision – This establishes the overall goal or high level aims which a customer wishes to achieve through the engagement. The vision focuses attention on the outcome desired and may detail items like who uses the product, the purpose of the product and the efficiencies or improvements sought through the project. Significantly, the vision is not necessarily reduced to detailed and specific requirements and specifications, but acts as a reference point for the development teams in guiding their project efforts.

b) Backlog – The 'backlog' is an evolving statement of the customer's requirements based on the vision. All discrete items to be developed during a project are identified, articulated, estimated and prioritised in the backlog. Throughout the project the backlog is fluid. Additional items can be added, some might be removed and others might be reprioritised as the project evolves, allowing resources to be dedicated to those items that provide the most value.

c) Management Structure – Essential to an agile contract is a representative of the customer to be involved in the project, to communicate and revise the customer's requirements as they relate to the project vision. Given the significance of the role, the project owner has responsibility for the backlog including its development and adjustment during the project by introducing new items, removing redundant items and reprioritising others. They also need to participate in the various meetings (discussed below) to track the project's progress.

The second key element in the management structure is the development team. As the name suggests, the development team is responsible for the day to day activities during the project, including coding and testing.

A third element to the management structure may include a party intended in part to guide or act as facilitator of the project. Often referred to as the 'Scrum master', their role is to ensure collaboration occurs between the project owner and the development team. While there are obvious issues with this approach, the Scrum master' may be a member of either the customer or supplier. They could also be an independent third party. Alternatively, there may be no Scrum master.

d) Sprints – Work is performed through discrete work efforts of between two and four weeks often referred to as 'Sprints'. The duration of a 'Sprint' should not be changed beyond a four week period and the deliverables determined for each 'Sprint' should not be changed. Any failed or unperformed tasks should be reinserted back into the backlog to be reprioritised. For this reason, it is unnecessary to specify a traditional change management mechanism. In our experience, within a sprint mechanism it is also possible (and useful) to build in systems to compensate for underperformance and promote exceptional performance.

In keeping with the collaborative nature of agile, there are several types of meetings that occur in relation to each 'Sprint'. For each 'Sprint' there is the initiation meeting where the project owner and development team (potentially with the aid of the 'Scrum master') plan the next sprint. It is through these meetings the project owner can prioritise items in the backlog and the development team can determine how many of those items can be achieved and the likely cost.

During each 'Sprint', short (ie no more than half an hour) daily meetings are held by the development team potentially with the project owner. Among other things these daily meetings identify the work completed, issues with the work and anticipated work to be completed.

It may be that at the end of each 'Sprint', the development team, project owner and potentially the 'Scrum master' will undertake a review meeting to review performance during the preceding 'Sprint', including any improvements to the project process.

e) Deliverables and Acceptance – Each 'Sprint' should result in a deployable item. This means it is coded, tested, working and ready for deployment. The customer determines whether an item has achieved acceptance by determining whether it has achieved the 'Definition of Done' which are criteria agreed by the customer and the supplier at the beginning of the 'Sprint'.

f) Pricing – A major impediment to customers adopting an agile approach is the perception that it simply constitutes a time and material contract without holding suppliers accountable for specific outcomes. There are a range of different pricing mechanisms adopted in agile contracts, including pure time and materials, capped time and materials, fixed price per iteration or unit of work. All of these mechanisms have different advantages and disadvantages on the dynamics of the work. For example, we have seen contracts where failures to provide minimum deliverables in any 'Sprint' have impacted on the price of subsequent 'Sprints'.

g) Liability – Despite the use of an agile approach, liability provisions are likely to be equivalent to those found in waterfall projects with an aggregate cap and exclusions of consequential losses.

h) Termination – Because the project progresses in much smaller increments with deployable increments of work provided at the end of each Sprint, termination takes on less significance. Indeed, taken to its natural conclusion, a customer's ability to control the backlog and descope items during the project means theoretically termination for convenience is a right of the customer. That said, this right should arguably be balanced against the supplier's costs in ramping up to perform the project. It may be that given the nature of agile contracts with their short incremental work efforts, only minimum termination provisions should be included which contemplate termination for a change of control or in the event of insolvency of a party.

When to Use Agile
While there are clear advantages to using an agile engagement method, the success of the methodology arguably demands certain requirements or conditions. Not every project can be transformed from waterfall to agile with instant success.

Agile Familiarity – Familiarity with agile approach is critical, otherwise the parties risk inadvertently reverting to a waterfall approach during negotiations and in the project's conduct. This can result in a hybrid model which diminishes or eliminates the advantages which can be achieved through an agile approach, without necessarily providing the protections or advantages of waterfall. The conduct of an agile contract ideally requires that the customer have significant prior agile experience in order to ensure the process is managed and followed appropriately. Inexperience is likely to result in underperformance and escalation of costs.

Depth of Experience – Ideally, the supplier would also be familiar with agile principles. Furthermore, given the focus on personnel, a supplier with a depth of experience and personnel, while not a necessity, arguably provides a greater capacity for the supplier to resolve obstacles during the project as more senior staff can be used to resolve increasingly intractable problems. For suppliers with shallow pools of resources, problems arising in the project may remain unresolved because the supplier does not have sufficiently experienced personnel.

Management vs performance – As the preceding commentary highlights there is a high degree of engagement between customers and suppliers in an agile contract, much more than the 'set and forget' approach often adopted in waterfall projects. Therefore, there is a challenge in agile methodology in striking an appropriate balance between suitable management of the project and too many management mechanisms which impede actual performance.

Project types – Arguably, the agile method works best on specific types of projects, including software development or digital transformation or development works. It may not work as well on larger projects with a greater level of complexity in terms of delivery items or interactions with a multitude of third parties. Inherently, the project needs to be able to be broken into short 'Sprints' that produce meaningful output.

Waterfall Vs Agile
Customers should be cautious around proposals by suppliers to use agile methodologies. Suppliers can propose agile methodologies to avoid perceived risks that a waterfall approach would entail particularly holding the supplier more appropriately accountable. Our view is that agile should be used where it best fits the nature of the project, for example where the project has the following characteristics: 

• high change/fluid environment 
• 'bite size' deployable elements 
• skilled customers and vendor methodology 
• no need to satisfy a fully defined outcome to a budget.

Subject to some comments below, the waterfall approach works well for projects where:

• the requirements can be determined up front 
• appropriate budget and project allowance is made for change over the project life 
• change management techniques will be applied to align the business to new processes supported by the new system 
• the customer's business case requires clear outcomes to a fixed budget and time 
• the project can be defined in phases, but the phases are significantly longer involving substantial work 
• third party software is being configured, interfaced and implemented.

It is important to recognise that projects can fail whether agile or waterfall, not due to the methodology but due project management which fails to recognise the different project methodologies. If you embark upon a two year waterfall project it may not deliver what you need by the time it is complete – waterfall projects can still be broken down into shorter duration deliverables. Similarly, with agile if you fail in prioritising you can spend a lot of money for little business value in a series of Sprints that do not lead to the long term outcome.

Conclusion
Waterfall needs to learn some lessons from agile. Phases should be as small as possible. The need for change should be planned and budgeted for. Similarly, organisations conducting agile projects need to understand that budgets and business cases are premised (and approved) on achieving certain outcomes for a known expenditure, not just the promise of activity.

For management and professionals like lawyers who inherently focus on risk mitigation, cost and value, agile methodologies can appear high risk. At first glance they appear to simply be a time and materials contract with little accountability or customer protections with the distinct possibility of cost escalations without any realised value or benefit. That said, there is significant evidence that the predominant waterfall methodology fares no better. According to one survey available at Dr. Dobb's, 64% of agile contracts were considered successful in comparison to 49% for waterfall or traditional style contracts.

By being highly collaborative and adaptive, agile contracts establish an environment which is arguably more likely to facilitate solutions and products that are closely aligned with a customer's requirements, in a manner which allows the customer to manage and control costs over the duration of the project. Contrast this with the frequent outcomes of waterfall projects involving cost overruns and products which often do not meet evolved customer requirements. In a market environment demanding fast evolution, but cost certainty, it may be that the agile methodology provides a viable solution.