Businesses must be flexible, adjustable and dynamic in order to thrive. Contract management is particularly relationship dependent, and thus finding harmony with contracting partners is critical to long-term success. Businesses have struggled to find the right contract management approach, as demands and technology cause frequent changes that may necessitate starting from scratch.
Most projects face price, time, functionality and resource constraints. Waterfall and agile project management methods address these issues differently; these methods are a framework for completing complex projects.
“Agile” is an umbrella term for different project methodologies. Agile methods differ from waterfall methods. 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 used to refine and deliver the project outcome, and planning, development and delivery are continuous and adaptive.
Common features of the agile method are:
- delivering functionality and business value to the customer;
- business goals and needs can be defined, even if a solution cannot be defined at the outset;
- the project is divided into different “sprints”, each of which has its own set of priorities and goals;
- the end of each sprint, there is an approval process. Each sprint must result in a potentially shippable product increment;
- close communication with the supplier is achieved by planning and reviewing at meetings;
- the customer can reprioritise its business needs during the course of the project, allowing requirements to be changed; and
- regular meetings are held to allow lessons learnt to be discussed
However, agile methods are not suitable for every project because they can increase legal and commercial risk for the customer. The customer may have fewer rights and remedies for defects and delays than would be the case using the traditional waterfall development model and they require both parties to commit a significant level of time and resources.
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
- 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. The Product Owner:
- is responsible for the “product vision” and focuses on business needs;
- takes part in the sprint planning meetings, sprint review and sprint retrospective meetings;
- can be nominated and appointed by the customer.
- Development Team – the ‘developer’ role in 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 includes team members with a mix of functional skills and usually comprises supplier personnel. The Development Team focuses on:
- delivering the work through the sprint;
- self-organising so they can make decisions to get work done;
- ensuring transparency during the sprint they meet daily at the daily scrum. The daily scrum provides transparency to the work and provides a dedicated place for team members to seek help, talk about success and highlight issues and blockers.
- 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 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. The Scrum Master:
- facilitates the development process by focusing on the development team, its progress, removal of obstacles and quality assurance;
- is typically a member of the supplier’s personnel;
- can be absent as parties can elect to not have a Scrum Master.
- Stakeholders – includes representatives of customer’s management and 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 – 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 – 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 – 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”.
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 and the contract can be a time and materials contract, a fixed price contract, 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.
In an agile project:
- A product specification may only emerge during the course of the project. The customer could ask the supplier to create a description of the product, including its functionality. The supplier can then be required to warrant that the product will comply with this description
- If the development team is comprised of both supplier and customer personnel, the supplier will be less likely to offer warranties or indemnities
- The parties need to consider whether warranties apply to each product increment, or only the product as it exists at the end of the project term.
- 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. It is difficult to determine whether there is a delay or a defect and remedial work is more likely to be classified as 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.
With agile, the ability to spot problems every step of the process is much easier and faster, thereby addressing along the way and fixing it. Teams working on projects are most efficient, performance improves benefiting the company overall. For any business to grow today agile is the new norm. In order to flourish in a digital era, going agile will not only help companies scale costs but also harness abundance and embrace risks.
Interested in chatting with us?
Have you taken a look around Biztech Documents?
High quality, ready to customise legal documents and agreements at your fingertips. Be guided through an expert interview wizard, then your customised legal document is sent to your inbox, all done in under 5-20 minutes.
Head to Biztech Documents to create yours today.