Agile Software Development Agreement
Template — South Africa
An attorney-drafted Agile Software Development Agreement template designed specifically for South African businesses commissioning or delivering software using agile methodology. This comprehensive, legally compliant document governs sprint-based delivery, acceptance procedures, backlog change control, intellectual property ownership, source code escrow, and flexible pricing models — ensuring compliance with the Electronic Communications and Transactions Act 25 of 2002, the Copyright Act 98 of 1978, and the Protection of Personal Information Act 4 of 2013.
Drafted by qualified South African attorneys
Reviewed for compliance with current legislation · Last updated April 2026
Why Your Business Needs This Agreement
Client Paying for Software They Do Not Own
The most devastating risk in agile development engagements is the client paying hundreds of thousands or millions of rands for custom software, only to discover that the developer owns the intellectual property. Under Section 21(1)(c) of the Copyright Act, the author — not the commissioning party — is the first owner of copyright. Without an express written IP assignment, the client has a licence at best and nothing at worst. This has been the subject of litigation in South Africa and internationally, with clients losing ownership of software they funded entirely.
Scope Creep Without Commercial Control
Agile's flexibility is its greatest strength — and its greatest commercial risk. Without a change control mechanism that distinguishes between normal backlog reprioritisation and material scope changes that affect budget and timeline, the project can grow far beyond the original commercial understanding. The client may blame the developer for exceeding the budget, while the developer argues they were simply delivering what the Product Owner requested. A properly structured change control clause with clear approval thresholds prevents this dispute.
Developer Lock-In Without Repository Access
When the developer maintains exclusive access to the source code repository throughout the engagement, the client is entirely dependent on the developer's continued availability and cooperation. If the relationship deteriorates, the developer has significant leverage — they control the code. This has led to situations in South Africa where development agencies hold source code hostage during fee disputes. Real-time repository access from day one eliminates this risk entirely.
Quality Disputes Without Defined Acceptance Criteria
Without a contractually defined "Definition of Done" and sprint acceptance criteria, disputes about software quality are subjective and irresolvable. The client says the software is not good enough; the developer says it meets the requirements. Without agreed metrics — code review completion, test coverage thresholds, security scan clearance — there is no objective basis for resolving the dispute. This often leads to payment disputes, with the client withholding payment and the developer withholding further work.
Bait-and-Switch Team Composition
Development agencies frequently propose senior, experienced developers during the sales process to win the engagement, then replace them with junior developers once the contract is signed. Without contractual provisions identifying key personnel by name, requiring client approval for replacements, and specifying minimum skill levels, the client has no recourse. The resulting drop in productivity and quality can derail the project entirely.
No Transition Assistance on Termination
When an agile engagement ends — whether through completion, termination for convenience, or termination for cause — the client needs the departing developer to transfer knowledge, document the codebase, and support the handover to a replacement team. Without contractually defined transition assistance obligations (including a specified number of days and the activities to be performed), the developer has no obligation to assist, and the client may spend weeks or months reverse-engineering undocumented code.
What is a Agile Software Development Agreement?
The Agile Software Development Agreement is one of the most commercially important contracts in the South African technology sector — and one of the most frequently mishandled. Traditional fixed-scope, fixed-price development contracts are fundamentally incompatible with agile methodology, which embraces iterative delivery, evolving requirements, and continuous stakeholder feedback. Yet many South African businesses still attempt to use waterfall-style contracts for agile projects, creating a dangerous mismatch between the commercial agreement and the delivery methodology. The result is predictable: disputes over scope changes, arguments about what was "in" or "out" of the original specification, disagreements about payment for work that was accepted but later deemed insufficient, and — most critically — intellectual property ownership uncertainties that can cost millions.
This attorney-drafted template has been specifically designed for agile software development engagements under South African law. It accommodates the iterative nature of agile delivery by replacing the traditional fixed-scope approach with sprint-based acceptance procedures, backlog-driven change control, and pricing models that align commercial incentives with agile principles. The agreement covers three pricing models that can be used individually or in combination: time-and-materials (the client pays for actual hours worked at agreed rates), fixed price per sprint (a fixed fee per sprint regardless of hours), and capped time-and-materials (T&M billing with an agreed maximum cap per sprint or per project, providing cost predictability without the rigidity of pure fixed-price).
Under the Copyright Act 98 of 1978, software is classified as a "literary work" under Section 1 and is automatically protected by copyright. Section 21(1)(c) provides that the author is the first owner of copyright — which means that without an express written assignment, the developer (not the client) owns the copyright in the software they create. This is a critical issue in agile development, where the developer is almost always an independent contractor rather than an employee. Section 21(1)(d) only vests copyright in the employer when the work is created by an employee in the course of employment — it does not apply to independent contractors, consultants, or development agencies. This means the IP assignment clause in the Agile Software Development Agreement is not a nice-to-have — it is the mechanism by which the client acquires ownership of the software they are paying to have built.
ECTA provides the legal framework for the electronic aspects of the engagement — sprint acceptances communicated via project management tools, digital signatures on change orders, and the validity of electronic records as evidence of acceptance or rejection. POPIA applies when the development team processes personal information during software development — which is common when working with production data, test data derived from real customer records, or user acceptance testing environments that contain personal information. The agreement must address the developer's obligations as an operator under POPIA Section 21, including data security, purpose limitation, and data return or destruction on project completion.
This template covers every critical area of agile software development engagements: sprint methodology and process, sprint acceptance and warranty, backlog change control, pricing and payment models, intellectual property assignment and licensing, source code repository access and escrow, confidentiality, liability and indemnification, term and termination with transition assistance, and dispute resolution. Whether you are a development agency delivering agile projects, a startup engaging a development partner for a product build, or an enterprise commissioning custom software, this agreement provides the legal foundation your agile engagement requires.
Who Needs This
Want early access to the Agile Software Development Agreement template?
We'll email you the moment early access opens
Under Section 21(1)(c) of the Copyright Act 98 of 1978, the developer — not the client — is the first owner of copyright in software they create as an independent contractor. Without a written IP assignment, the client does not own the code they paid for.
Section 22 of the Copyright Act requires that copyright assignment be in writing signed by the assignor — verbal agreements to transfer IP are not enforceable for copyright
ECTA Section 15 confirms that electronic records (including sprint acceptance notifications in project management tools) satisfy legal requirements for written documents
POPIA Section 21 requires a written operator agreement when the development team processes personal information (including test data) on behalf of the client
The CPA Section 54 requires that development services be performed to a standard that people are generally entitled to expect — setting a baseline quality standard for agile deliverables even where the agreement does not specify acceptance criteria
Key Clauses Included
This Agile Software Development Agreement template covers 12 essential sections, each drafted by South African attorneys.
Agile Methodology & Sprint Process
Defines the agile framework to be used (Scrum, Kanban, SAFe, or a hybrid), the sprint duration (typically 2 weeks), sprint planning procedures, daily standup requirements, sprint review and demonstration format, retrospective process, and the product backlog as the single authoritative source of work. Specifies the roles and responsibilities: Product Owner (client-side), Scrum Master, and Development Team. Establishes the sprint velocity tracking methodology and the cadence for backlog refinement sessions.
Sprint Acceptance & Warranty
Establishes the acceptance criteria for each sprint's deliverables — typically defined during sprint planning and documented in the sprint backlog. Specifies the acceptance testing period (commonly 5-10 business days after the sprint review demonstration), the format for acceptance or rejection notices, deemed acceptance rules (if the client fails to respond within the acceptance period), defect classification criteria (critical, major, minor, cosmetic), and the sprint warranty period during which defects in accepted deliverables are remediated at no additional cost to the client.
Change Control for Backlogs
Governs the process for adding, removing, or reprioritising backlog items — which is the essential mechanism for managing scope in agile engagements. Establishes impact assessment procedures for scope changes that affect budget, timeline, or technical architecture, approval thresholds (changes below a defined value can be approved by the Product Owner; changes above the threshold require steering committee approval), and the documentation requirements for change requests. This section replaces the traditional "change order" process with a backlog-native approach that preserves agile flexibility.
Pricing & Payment Models
Supports three pricing models that can be used individually or in combination. Time-and-materials: the client pays for actual hours worked at agreed daily or hourly rates, with timesheets submitted at a defined frequency (weekly or per sprint). Fixed price per sprint: a fixed fee per sprint regardless of hours worked, providing cost predictability. Capped time-and-materials: T&M billing with an agreed maximum cap, with dual notification thresholds (typically at 75% and 90% of the cap) to alert the client before the cap is reached. Covers invoicing procedures, payment terms (typically 30 days from invoice), late payment consequences, and VAT treatment.
Intellectual Property Ownership & Assignment
This is the most critical section of the agreement. Provides for full assignment of intellectual property in all deliverables from the developer to the client, effective upon payment for each sprint. Addresses the Copyright Act Section 21 issue — confirming that because the developer is an independent contractor (not an employee), IP does not automatically vest in the client and must be expressly assigned. Protects the developer's pre-existing IP (frameworks, libraries, reusable components) through a broad, irrevocable licence to the client. Addresses open-source components used in the deliverables, requiring disclosure and ensuring compatibility with the client's IP strategy.
Repository Access & Source Code Escrow
Defines the client's access rights to the source code repository during the engagement — whether full access from day one (increasingly common and recommended), access upon sprint acceptance, or access only upon final project acceptance or termination. Establishes optional source code escrow for situations where real-time repository access is not provided, specifying the escrow agent, deposit frequency, release trigger events (developer insolvency, material breach, project abandonment), and cost allocation. Requires that all code be committed to the repository with meaningful commit messages and that the repository include build scripts and documentation.
Team Composition & Key Personnel
Identifies the key personnel assigned to the project — including the technical lead, senior developers, and Scrum Master — and establishes the client's approval right for replacements. Specifies the minimum skill levels and experience requirements, the notice period for personnel changes, and the ramp-up period allowed for new team members. Addresses the common concern of "bait and switch" — where senior developers are proposed during the sales process but replaced with junior developers after the contract is signed.
Confidentiality & Data Protection
Mutual confidentiality obligations protecting both parties' proprietary information, trade secrets, and business strategies. Addresses POPIA compliance when the development team accesses or processes personal information during development — including test data management, production database access for debugging, and user acceptance testing environments. Requires the developer to implement appropriate security measures under POPIA Section 19 and to return or destroy all personal information upon project completion.
Liability & Indemnification
Caps the developer's aggregate liability — typically at the total fees paid under the agreement in the 12 months preceding the claim, or at the total project value for fixed-price engagements. Excludes indirect, incidental, and consequential damages. Establishes mutual indemnification: the developer indemnifies for IP infringement in the deliverables, and the client indemnifies for claims arising from the client's use of the deliverables and from materials or data provided by the client to the developer. Includes professional indemnity insurance requirements.
Term, Termination & Transition Assistance
Defines the agreement term (typically the project duration or an ongoing retainer), termination for convenience with the required notice period (commonly 30 days or the end of the current sprint), termination for cause (material breach, insolvency, abandonment), and the critical transition assistance provisions — including knowledge transfer sessions, documentation of the codebase, handover to a replacement developer, and the specified number of days of transition support included in the termination provisions.
Acceptance Testing & Definition of Done
Establishes the project-level "Definition of Done" that applies to all sprint deliverables — including code review completion, unit test coverage thresholds, integration test passage, documentation updates, security scan clearance, and deployment to the specified environment. Defines the user acceptance testing (UAT) process, the criteria for project-level acceptance versus sprint-level acceptance, and the remediation procedures for deliverables that fail acceptance testing.
Dispute Resolution & Governing Law
Specifies South African law as the governing law and establishes a dispute resolution process designed for the fast-paced nature of agile projects. Provides for expedited mediation under the Arbitration Foundation of Southern Africa (AFSA) rules as the first step, followed by binding arbitration for unresolved disputes. Includes provisions for technical expert determination — where disputes about the quality or functionality of deliverables are resolved by an independent technical expert rather than a legal tribunal.
South African Law Compliance
Copyright Act 98 of 1978
The Copyright Act is the most critical legislation for agile development agreements. Section 1 classifies computer programmes as "literary works" with automatic copyright protection. Section 21(1)(c) makes the author the first owner of copyright — meaning that without an express assignment, the developer owns the code they write. Section 21(1)(d) vests copyright in the employer only for works created by employees in the course of employment — it does not apply to independent contractors, which is what most agile development teams are. This makes the IP assignment clause in the agreement the sole mechanism by which the client acquires ownership. Section 6 defines the exclusive rights of the copyright owner. Section 19B permits limited decompilation for interoperability. Section 22 allows assignment of copyright, but only in writing signed by the assignor.
Electronic Communications and Transactions Act 25 of 2002
ECTA governs the electronic aspects of agile development engagements. Sprint acceptances communicated through project management tools (Jira, Azure DevOps, Linear), change requests submitted electronically, and digital signatures on formal documents are all governed by ECTA. Section 11 confirms that electronic records and communications are legally valid. Section 13 addresses the attribution of electronic communications — ensuring that sprint acceptance notifications are attributable to the authorised representative. Section 15 confirms that electronic records satisfy legal requirements for written documents, which is relevant to the IP assignment clause under Copyright Act Section 22.
Protection of Personal Information Act 4 of 2013
POPIA applies whenever the development team accesses or processes personal information during the engagement — which includes accessing production databases for debugging, using anonymised or pseudonymised test data derived from real records, and building user acceptance testing environments. Section 19 requires appropriate security measures. Section 21 requires a written agreement when the developer acts as an operator processing personal information on behalf of the client. Section 22 requires notification of security compromises. The agreement must address the developer's data processing obligations, the handling of test data, and the return or destruction of all personal information upon project completion.
Consumer Protection Act 68 of 2008
The CPA may apply where the client qualifies as a consumer — a natural person or juristic person with annual turnover below R2 million. Where applicable, Section 54 requires that services be performed in a manner and quality that people are generally entitled to expect, and Section 56 provides an implied warranty of quality. For agile development engagements, this means the delivered software must meet a reasonable standard of quality and fitness for purpose. Section 48 prohibits unfair, unreasonable, or unjust contract terms, which may affect broad disclaimers of warranty in the agreement.
South African Common Law of Contract
The South African common law of contract governs the formation, interpretation, and enforcement of the agile development agreement as a commercial contract. The principles of consensus, capacity, legality, and possibility of performance apply. The parol evidence rule may limit the admissibility of pre-contractual representations and proposals (such as initial project estimates) that are not reflected in the final agreement. The common law also provides remedies for breach — including specific performance and damages — that supplement the contractual remedies in the agreement.
South African businesses are lining up for My-Contracts — be first in when we launch
Create Your Agile Software Development Agreement in Minutes
Our guided wizard walks you through every clause — no legal knowledge required. Attorney-drafted, South African law compliant.
Define the agile framework and team structure
Agree on the agile methodology (Scrum, Kanban, or hybrid), sprint duration, ceremony schedule, and team composition. Identify key personnel by name and role — Product Owner (client-side), Scrum Master, Technical Lead, and Development Team members. Establish the communication tools, project management platform, and code repository to be used throughout the engagement.
Establish the pricing model and payment terms
Select the appropriate pricing model — time-and-materials, fixed price per sprint, or capped T&M — and agree on the rates, caps, invoice frequency, and payment terms. For T&M engagements, agree on the timesheet submission format and review period. For capped T&M, define the notification thresholds that will alert the client before the cap is reached.
Define acceptance criteria and the Definition of Done
Establish the project-level Definition of Done — the quality gates that every sprint deliverable must pass before it can be accepted. This typically includes code review by a senior developer, unit test coverage above a specified threshold, passing integration tests, security scan clearance, updated documentation, and successful deployment to the specified environment. Define the sprint acceptance period and the defect classification criteria.
Customise the IP, confidentiality, and data handling provisions
Complete the intellectual property assignment clause, ensuring it covers all deliverables and includes appropriate protections for the developer's pre-existing IP. Document any open-source components that will be used. Address POPIA compliance for test data handling. Establish the repository access model — real-time client access versus traditional source code escrow.
Execute and commence the engagement
Have both parties sign the agreement, verify that all key personnel are available, set up the project management and communication tools, grant repository access per the agreed model, and commence Sprint 0 (project setup and backlog refinement). Schedule the first sprint planning session and ensure both parties understand the acceptance process that will apply from Sprint 1 onwards.
Frequently Asked Questions
An Agile Software Development Agreement is a contract specifically designed for software projects delivered using agile methodology — Scrum, Kanban, SAFe, or similar frameworks. It differs fundamentally from a traditional fixed-scope development contract in several critical ways. Traditional contracts define the entire scope upfront and treat any change as a formal "change order" that requires renegotiation. Agile contracts accept that requirements evolve and use the product backlog as a living document that can be reprioritised each sprint. Traditional contracts have a single acceptance point at project completion. Agile contracts have acceptance points at the end of every sprint, providing the client with working software and the ability to redirect the project based on what they have seen. Traditional contracts typically use fixed-price models. Agile contracts support time-and-materials, fixed price per sprint, and capped T&M models that align with iterative delivery. Without an agile-specific contract, the legal framework actively undermines the delivery methodology.
What You Get With This Template
Drafted specifically for South African agile development — compliant with the Copyright Act, ECTA, POPIA, and the CPA
Comprehensive IP assignment clause that addresses the Copyright Act Section 21 ownership issue for independent contractor developers
Three flexible pricing models — time-and-materials, fixed price per sprint, and capped T&M — with clear invoicing and payment provisions
Sprint-based acceptance and warranty provisions that align the legal framework with agile delivery methodology
Backlog-driven change control that preserves agile flexibility while providing commercial governance for material scope changes
Repository access and source code escrow options to protect the client's investment and prevent developer lock-in
Key personnel clauses that prevent bait-and-switch team composition changes
Transition assistance provisions ensuring smooth handover on termination, including specified days of knowledge transfer and documentation