Agile Projects and Contracting for Startups

Businesses must be flexible, adaptable and dynamic in order to thrive. Contracting processes - from contract establishment to ongoing contract management - can play a big role in whether this is achieved.

And given the relationship-dependent nature of contracting, finding harmony with contracting partners is critical to long-term success.  Aligning contracting methods to project management method for a given project is one way of ensuring contracting doesn't stand in the way of success.

Agile v Waterfall

'Waterfall' and 'Agile' project management are two alternative methods for completing complex projects that address these issues differently.  Where 'Waterfall' project methods involve the project being organised into sequential phases, 'Agile' methods involve short, frequent development cycles which are iterative and incremental.  Feedback is then used to refine and deliver the project outcome, and planning, development and delivery are continuous and adaptive.

Today we will look further at Agile project methods and what is typically involved, and the contracting issues that come up in Agile projects.

The scrum process – a subgroup of agile

Scrum is a framework that helps teams work together. Much like a rugby team (where it gets its name) training for the big game, it encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve. It is the most well-known agile framework and has informed many of the roles, tools, terminology and processes associated with agile methods.

Scrum resolves complexity in work by making data unclouded, so that people can inspect and adapt based on current conditions, rather than predicted conditions. This allows teams to identify the common pitfalls resulting from constantly changing requirements; underestimation of time, resources and cost; compromises on software quality; and inaccurate progress reporting. Frequent inspection ensures progress and detects variances early on so that adjustments can be made quickly.

Agile project roles - methodologies emphasise several key roles

1. Product owner – the project’s key stakeholder – usually an internal or external customer, or a spokesperson for the customer. There is only one Product Owner who conveys the overall mission and vision of the product which the team is building. The Product Owner is ultimately accountable for managing the product backlog and accepting completed increments of work.

2. Development Team – the ‘Developer's’ within a 'scrum' means a team member who has the right skills, as part of the team to do the work. They are responsible for undertaking the actual project work. This team comprises members with a mix of functional skills and usually comprises supplier personnel.

3. ScrumMaster – the role responsible for gluing everything together and ensuring that 'scrum' is being done well. In practical terms, that mean they help the Product Owner define value, the Development Team deliver the value and the scrum team to get better. The scrum master is a servant leader which not only describes a supportive style of leadership but describes what they do on a day-to-day basis.

4. Stakeholders – includes representatives of the end-customer’s management team who are engaged in the development process throughout the project to ensure that it remains focused on the customer’s business needs and priorities.

Agile project tools for project management

• Product vision
  It consists of a precise definition of what needs to be developed, focusing on business goals and targeted benefits. The product owner is responsible for formulating the product vision. This should be settled before negotiations begin so that parties are working towards the same objectives. It can be included as an appendix to the contract.
• Product backlog
  This is a prioritised list of the customer’s business requirements that are to be developed during the project term. This usually comprise of development items, estimate of business value, estimate of effort, and priority of each development item.
• User stories
  These are short descriptions of what a user does or needs to do as part of their role. This creates a simple description of the user’s requirement and captures a description of the required features that the project should be developing from the end user’s perspective.
• Sprint process
  There is no specified duration for each sprint but they are generally quite short (eg 2-4 weeks). The length of the sprint should not be changed if work is behind schedule. Unfinished development items remain in the product backlog and are reprioritised. The next sprint usually starts immediately after the last, unless a break is scheduled.
• Sprint meetings
  • Planning and meeting: held at the beginning of the sprint. The product owner outlines to the development team which development items from the product backlog are the highest priority. This meeting allows the development team to prepare a sprint backlog.
  • Daily meeting: development holds a meeting each day to allow team members to report what they have completed, what they are planning to do, and address any obstacles.
  • Sprint review meeting: takes place at the end of the sprint. Involves a review of which product backlog items have been “done”.
  • Sprint retrospective meeting: involves the Scrum Master and the development team (and sometimes the product owner). Involves a discussion of the process: what went well, what could be improved.
• Sprint backlog - sets out requirements that are to be developed during the current sprint and breaks down each requirement into tasks, with an estimation of time required for each task and an allocation of tasks to team members.
• Definition of “done”
  The definition of “done” is agreed on during the negotiation phase and can be added as a schedule to the contract, it should be considered at each sprint planning meeting; and the project is complete when all development items in the product backlog have been finalised in compliance with the definition of "done”.
• Timeboxing
  A timebox is a defined period of time during which a person or team work towards the completion of a goal and work stops when the time limit is reached.

Contractual issues in agile projects

Several aspects of contracting must be approached in a separate way for the contract to reflect the reality of an Agile project.

• Timetable – time limits are relatively fluid, the customer’s expectations are addressed by the customer estimating the project duration or number of sprints and failure to meet specific requirements within the original timeframe will not always be seen as a breach.

• Pricing and payment –– customers often prefer a fixed price, whereas the supplier will want to be paid for all time spent on the project. A criticism of agile methodologies is that the flexibility to change requirements as the project unfolds exposes the customer to pricing risk as a time and materials contract, or under-delivery within a fixed price project period.  Alternatives here can include a 'target price' contract or an 'incremental delivery' contract.

• Warranties, indemnities and risk allocation –– the customer in an Agile project arguably take on a greater legal risk than would be the case in a traditional waterfall project. In traditional project methodologies, the supplier will usually give various warranties about the product or service, and both parties will seek to limit or exclude its liability in the contract and some risks may be allocated using indemnities.

• Intellectual property (IP) — issues concerning IP in agile projects are similar to other commercial arrangements and the parties must resolve whether developed IP should be licensed or assigned to the customer.

• Remedies  — for breach of a waterfall-type agreement include damages, termination and remedial work in case of defects. In an Agile project, it is difficult to determine whether there is a delay or a defect and remedial work is really a further 'requirement' to be included in the product backlog (even at the customer’s cost), rather than as a contractual breach.

• Dispute resolution — agile projects require close collaboration, so disputes must be resolved quickly and the contract should provide for informal discussion of disputes between the product owner and either the Scrum Master or a senior member of the development team. Following this, senior management can deal with any issues. Finally, disputes may be resolved via mediation or expert determination.

• Termination — in agile contracts, a key benefit for the customer is the shorter development cycle, giving the customer more flexibility than is the case under a fixed term project using a waterfall methodology. The customer’s termination rights reflect this flexibility. The customer should have a right to terminate for convenience after each sprint, or after a defined number of sprints and the supplier will want to be able to recoup the cost of its initial investment in setting up the project, so a minimum term is a concern for the supplier.

Interested in chatting with us?

In need of legal support from a tech startup lawyer? Biztech Lawyers is a multi-award-winning law firm, known for fuelling and protecting tech innovation worldwide. Get in touch now to see how we can help.