Thank you, Charlotte. Hopefully, you can hear me. Good morning, afternoon, or evening, depending on where you are.
My name is Stewart, and I am a lawyer based in the UK specializing in technology contracts. I have been a lawyer for over 20 years, working in the UK, the USA, and Australia. I first started drafting contracts for Agile methodologies nearly 20 years ago, before the Agile Manifesto was written, when it was primarily known as rapid application development in the software development world.
From my experience, I believe lawyers represent one of the biggest barriers to the adoption of Agile—probably something Marko might agree with. That is quite an admission for a lawyer to make, but I stand by it.
Why Lawyers Struggle with Agile
The purpose of this presentation is to explain why lawyers often resist Agile contracts, identify some of the myths they use to dissuade clients from adopting Agile, and examine the commercial challenges of drafting Agile contracts.
Lawyers prefer certainty. They want predictable outcomes, well-defined costs, and clear timelines, all of which they meticulously document in contracts. By nature, lawyers are conservative and highly trained to identify risks and draft clauses that mitigate them. They also rely heavily on precedent—reusing contract templates and clauses that have worked in the past. While this provides predictability and reduces litigation risks, it also stifles innovation.
Historically, software contracts have been modeled on engineering and construction contracts, which follow rigid, sequential processes. This made sense when software development required designing and building applications from scratch. That is why we use terms like "software engineering" and why software courses often focus on engineering principles.
However, today's environment demands rapid digital transformation and a first-to-market approach, making traditional sequential contracts less effective.
Limitations of Traditional Contracts
To be clear, Agile is not suitable for every contract or project. However, sequential contracts present several challenges:
- They require defining all features upfront, locking in specifications even if requirements evolve.
- They create resistance to change, as modifications often mean price adjustments and contract renegotiations.
- They encourage a rigid, inflexible mindset that prevents adaptation to new insights.
- They risk delivering solutions that no longer match the customer's actual needs.
In the worst-case scenario, a customer may reject the final solution because their needs evolved but the contract did not allow for adjustments. This can lead to costly disputes, making it a lose-lose situation for both parties.
Misconceptions About Agile Contracts
One of the most common myths about Agile contracts is that they must use a time-and-materials (T&M) pricing model. In reality, Agile can support a wide range of commercial models, including fixed-price agreements. The key is structuring contracts to allow flexibility while maintaining accountability.
Many Agile contracts break projects into phases, such as:
- Discovery Phase: Identifying business needs and priorities.
- Incremental Implementation: Delivering functionality iteratively.
Another misconception is that Agile contracts lack defined outcomes. While Agile does not dictate every feature upfront, the overall project goal remains clear. For example, if the goal is to build a CRM system, the contract ensures a CRM system is delivered. However, the specific features and functionalities may evolve based on user feedback.
Cultural Shifts in Agile Contracts
Agile requires a collaborative approach. End users and key stakeholders must actively participate in shaping the solution. This often requires organizations to shift decision-making power from senior executives to more junior employees who are closer to the development process. In traditional contracts, junior staff may have limited authority, but Agile demands greater empowerment and involvement.
Managing Change in Agile Contracts
Traditional contracts discourage change, requiring lengthy impact analyses and approvals before modifications can be made. Agile contracts, in contrast, incorporate structured mechanisms for adaptation. There are two levels of change:
- Minor Changes: Adjustments to features and priorities that can be handled quickly.
- Major Changes: High-level changes that require broader agreement and documentation.
Maintaining version control of prioritized requirements ensures transparency in how the project evolves over time.
Intellectual Property Challenges
In Agile development, intellectual property (IP) ownership can become ambiguous. Most modern software development involves integrating third-party libraries, open-source components, and proprietary code. While joint ownership may seem like a fair solution, it can create legal complications.
A better approach is for parties to agree upfront on IP ownership terms, ensuring clarity in the contract. This avoids disputes over who owns specific parts of the solution.
Roles and Responsibilities
Every Agile methodology defines distinct roles, but these roles can be flexible. Contracts should recognize this evolving structure rather than imposing rigid job descriptions. Instead of specifying strict role definitions, contracts should focus on the expected responsibilities and contributions of each party.
Acceptance and Delivery
Agile emphasizes iterative delivery. Each iteration should be formally accepted once it meets its defined criteria. Unlike traditional contracts, where final acceptance often hinges on a single delivery milestone, Agile allows for continuous acceptance, reducing risks of rejection at the end of the project.
However, requirements may change over time, meaning previously accepted features may later become redundant. This does not mean the iteration failed—it simply means the project evolved beyond its earlier requirements.
Commercial Models and Cost Control
There is no single commercial model for Agile contracts. Instead, pricing models should align with project needs. Options include:
- Fixed-price per iteration: Ensuring predictable costs while allowing scope flexibility.
- Time and materials (T&M): Paying for effort expended, allowing maximum flexibility.
- Outcome-based pricing: Payments tied to achieving key business goals.
Ultimately, the best commercial model depends on the nature of the development and the business objectives.
Conclusion
Agile contracts require a shift in mindset from rigid, sequential agreements to flexible, collaborative partnerships. The key principles include:
- Focusing on outcomes rather than predefined features.
- Structuring contracts to allow iterative change.
- Empowering teams with decision-making authority.
- Clarifying intellectual property ownership upfront.
- Ensuring formal acceptance of each iteration.
- Choosing the right commercial model to align with project goals.
By adopting these principles, businesses can create contracts that support Agile delivery while maintaining legal and financial clarity.
With that, I will stop here and wait for questions at the end. Thank you.