MKB Juristen stelt juridische documenten op maat op
Het beste is om belangrijke contracten, algemene voorwaarden en andere juridische documenten niet zelf te knutselen of te kopiëren. Wij helpen ondernemers budgetvriendelijk met juridisch maatwerk, vooraf duidelijke kosten en praktische uitleg.
- Contracten, voorwaarden en juridische documenten op maat
- Budgetvriendelijk en vooraf duidelijk over de kosten
- Gratis adviesgesprek of vrijblijvend een offerte aanvragen
Wat is een agile softwareontwikkelingsovereenkomst? Het is een contract voor softwareontwikkeling volgens een agile werkwijze (scrum, sprints), waarbij de scope bewust niet vooraf wordt dichtgetimmerd. In plaats van één vast eindresultaat tegen een vaste prijs spreek je een werkwijze, budget- en tijdkaders en acceptatie per sprint af. De opdrachtgever stuurt onderweg bij op basis van wat opgeleverd wordt. Dat past bij projecten waarvan de eisen tijdens de bouw nog scherper worden, maar het vraagt wel om andere afspraken dan een klassiek fixed-price-contract.
Het korte antwoord
- Werkwijze in plaats van eindproduct. Je legt scrum, sprints en samenwerking vast, niet één afgebakende specificatie.
- Geen vaste scope. De backlog en prioriteiten mogen per sprint wijzigen.
- Budget- en tijdkaders. Vaak een uurtarief of teamtarief per sprint, binnen een afgesproken maximum.
- Acceptatie per sprint. De opdrachtgever keurt opgeleverd werk sprint voor sprint goed.
- IE, meerwerk en exit. Wie krijgt de rechten, hoe ga je om met uitloop, en hoe stop je tussentijds.
Wat is een agile softwareontwikkelingsovereenkomst precies?
Bij een klassiek ontwikkelcontract beschrijf je vooraf tot in detail wat de software moet doen, tegen welke prijs en per wanneer. De leverancier bouwt dat en levert op. Werkt de software niet zoals beschreven, dan is dat zijn probleem.
Een agile softwareontwikkelingsovereenkomst draait dat om. Partijen erkennen dat niet alle eisen vooraf bekend zijn. In korte cycli (sprints van meestal één tot vier weken) wordt werkende software opgeleverd, beoordeeld en bijgestuurd. Het contract legt daarom vooral de spelregels van die samenwerking vast: rollen, sprintlengte, hoe de backlog wordt geprioriteerd, en hoe je stap voor stap accepteert en betaalt.
Scrum en sprints in het contract
Scrum is het meest gebruikte agile raamwerk. De belangrijkste elementen komen terug in de overeenkomst:
- Product owner. Meestal iemand van de opdrachtgever die prioriteiten stelt en de backlog beheert. Contractueel belangrijk: deze persoon moet beschikbaar en beslissingsbevoegd zijn.
- Sprints. Vaste periodes waarin het team een afgebakende hoeveelheid werk oppakt. Leg de sprintlengte en het aantal geplande sprints vast.
- Backlog. De prioriteitenlijst met gewenste functionaliteit. Deze mag wijzigen — dat is juist de bedoeling.
- Sprint review. Aan het eind van elke sprint bekijkt de opdrachtgever wat er is gebouwd.
Geen vaste scope, wel kaders
Het meest wezenlijke verschil met een gewoon contract: er is geen dichtgetimmerde scope. Dat maakt sommige opdrachtgevers nerveus, want hoe weet je dan waar je aan toe bent? Het antwoord zit in de kaders.
- Budgetkader. Een maximumbedrag of een aantal sprints tegen een vast tarief. Zodra het budget op raakt, beslist de opdrachtgever of hij verlengt.
- Tijdkader. Een indicatieve einddatum of een aantal sprints, met de afspraak dat de scope wordt aangepast als de tijd knelt (niet de kwaliteit).
- Minimale eisen. Soms een lijst met functionaliteit die er sowieso in moet — een minimum viable product — zodat de opdrachtgever niet met een half product blijft zitten.
Zo houd je de flexibiliteit van agile, maar zonder een blanco cheque te tekenen.
Acceptatie per sprint
Bij fixed-price accepteer je aan het eind één keer het hele product. Bij agile keur je per sprint goed. Dat verkleint het risico: je ontdekt problemen vroeg, niet pas na maanden.
Regel in het contract wat “geaccepteerd” betekent. Meestal: de opgeleverde functionaliteit voldoet aan de vooraf per sprint afgesproken acceptatiecriteria (de “definition of done”). Leg ook een reactietermijn vast — bijvoorbeeld dat werk als geaccepteerd geldt als de opdrachtgever niet binnen tien werkdagen reageert. Zonder zo’n termijn kan een project eindeloos in de lucht blijven hangen.
IE, meerwerk en exit
Drie onderwerpen die vaak misgaan als het contract te dun is:
- Intellectuele eigendom (IE). Auteursrecht op maatwerksoftware ontstaat bij de maker (de leverancier), niet automatisch bij de opdrachtgever. Wil de opdrachtgever de rechten hebben, dan moet dat expliciet worden overgedragen in het contract. Let ook op open-source-componenten en bestaande bouwstenen van de leverancier, waarop vaak alleen een licentie wordt gegeven.
- Meerwerk. Doordat de scope beweegt, is de grens tussen “gewone” bijstelling en echt meerwerk lastig. Spreek af dat werk binnen het budgetkader gewoon meeloopt, en dat verlenging van sprints of extra budget vooraf schriftelijk wordt bevestigd.
- Exit. Omdat je tussentijds kunt stoppen, is een exitregeling cruciaal: opzegtermijn, afronding van de lopende sprint, overdracht van de broncode en documentatie, en betaling van het tot dan geleverde werk.
Voor welke projecten geschikt?
Agile past bij projecten waarvan de eisen onderweg scherper worden: een nieuw platform, een app waarvan het gebruik nog moet uitkristalliseren, of software die meebeweegt met een veranderende markt. Voor een strak afgebakend klusje met vaste eisen — een simpele koppeling of een standaard website — is een fixed-price-contract vaak eenvoudiger.
Voorbeeld: een mkb-groothandel wil een besteldashboard voor klanten. De precieze functies hangen af van hoe klanten het gaan gebruiken. Met een agile overeenkomst bouwt de leverancier eerst het bestelproces, kijkt de groothandel mee, en bepaalt daarna of rapportages of voorraadinzicht de volgende sprint waard zijn. Het budget is gemaximeerd op acht sprints.
Eerlijke aanbeveling
Een agile softwareontwikkelingsovereenkomst is de juiste keuze als je flexibiliteit nodig hebt en bereid bent actief mee te sturen als opdrachtgever. Zorg dat budget- en tijdkaders, acceptatie per sprint, IE-overdracht en een exitregeling zwart op wit staan — juist omdat de scope bewust openblijft.
Heb je een klein, strak afgebakend project met vaste eisen, dan heb je geen jurist en geen agile contract nodig; een eenvoudig fixed-price-model volstaat dan. Twijfel je over IE, meerwerk of de exit, of gaat er een fors budget om, laat het contract dan eenmalig nakijken. Dat verdient zich terug zodra er een verschil van mening ontstaat over wat er is afgesproken.
Meer weten of laten opstellen? Bekijk de agile softwareontwikkelingsovereenkomst, lees hoe je zo’n agile softwareontwikkelingsovereenkomst opstelt en wat het kost om er een te agile softwareontwikkelingsovereenkomst te laten opstellen.
Veelgestelde vragen
Een contract voor softwareontwikkeling volgens een agile werkwijze (scrum, sprints), waarbij de scope niet vooraf vast staat. Je legt de werkwijze, budget- en tijdkaders en acceptatie per sprint vast in plaats van één vast eindproduct tegen een vaste prijs.
Bij fixed-price staan scope, prijs en einddatum vooraf vast en accepteer je één keer het hele product. Bij agile beweegt de scope mee, betaal je per sprint of uur binnen een budgetkader en accepteer je sprint voor sprint. Agile past als de eisen tijdens de bouw nog scherper worden.
Aan het eind van elke sprint beoordeelt de opdrachtgever de opgeleverde functionaliteit aan de hand van vooraf afgesproken acceptatiecriteria (definition of done). Leg een reactietermijn vast, bijvoorbeeld goedkeuring als er niet binnen tien werkdagen wordt gereageerd, zodat het project niet blijft hangen.
Auteursrecht op maatwerksoftware ontstaat bij de maker, dus bij de leverancier. Wil de opdrachtgever de rechten, dan moet dat expliciet worden overgedragen in het contract. Op open-source en bestaande bouwstenen van de leverancier krijgt de opdrachtgever meestal alleen een licentie.
Door kaders af te spreken: een maximumbudget of vast aantal sprints, een indicatief tijdkader waarbij de scope (niet de kwaliteit) wijkt als de tijd knelt, en eventueel een lijst met minimale functionaliteit. Zo behoud je flexibiliteit zonder onbeperkte kosten.
Ja, mits het contract een exitregeling bevat: opzegtermijn, afronding van de lopende sprint, overdracht van broncode en documentatie en betaling van het geleverde werk. Juist omdat je bij agile stap voor stap werkt, is stoppen makkelijker dan bij fixed-price, mits goed geregeld.
Voor projecten waarvan de eisen onderweg scherper worden, zoals een nieuw platform of een app waarvan het gebruik nog moet uitkristalliseren. Voor een strak afgebakend, klein project met vaste eisen is een eenvoudig fixed-price-contract vaak praktischer.
