Agile kontrakter: deadlines, accept og ansvar i IT-projekter

En agil kontrakt registrerer et samarbejde, hvor slutresultatet ikke er fastlagt på forhånd, så den skal regulere, hvem der prioriterer, hvornår et sprintresultat accepteres, og om leveringsdatoer er bindende. I henhold til hollandsk lov er en leveringsdato i et agilt projekt ikke automatisk en streng deadline: retten ser på kontrakten, arbejdsmetoden og hvordan parterne rent faktisk samarbejdede, og selv en overskredet streng deadline berettiger ikke altid til ophævelse.

I agil udvikling arbejder parterne i korte sprints og justerer produktet, efterhånden som projektet skrider frem. Denne artikel forklarer, hvordan man kvalificerer leverandørens forpligtelse, hvordan man strukturerer kontrakten, hvad nyere retspraksis siger om deadlines, og hvad kunder og leverandører bør kontrollere.

Hvorfor kræver agil arbejdsform en anden kontrakt?

Fordi resultatet er et bevægeligt mål. I et traditionelt IT-projekt fastlægger parterne et funktionelt og teknisk design, og leverandøren lover at levere det til en fastsat dato; i agil udvikling leverer hvert sprint en fungerende del, og klienten justerer kursen på baggrund af demonstrationer.

Kontrakten skal derfor afgøre fire emner, som en traditionel specifikation besvarer i sig selv:

• hvem der bestemmer specifikationerne og prioriteterne: produktejeren på kundens side;
• hvordan ændringer behandles i backloggen (den prioriterede liste over funktionalitet, der stadig skal bygges), planlægningen og prisen;
• hvornår en del tæller som færdig, baseret på en definition af færdig og målbare acceptkriterier;
• om de aftalte leveringsdatoer er strenge eller vejledende.

Agil arbejdsgang er svær at kombinere med et offentligt udbud, hvor omfanget er fuldt fastlagt på forhånd. En ordregiver, der ønsker agil udvikling, bør i udbudsmaterialet give plads til en rammeaftale med fleksibelt definerede afkaldsopgaver.

Er det en forpligtelse til at yde sit bedste eller en resultatforpligtelse?

I agile projekter kvalificeres leverandørens forpligtelse ofte som en best-efforts-forpligtelse (inspanningsverbintenis), fordi der ikke er aftalt et fast slutresultat. Under en resultatforpligtelse (resultaatsverbintenis) lover leverandøren et specifikt beskrevet resultat.

Etiketten i kontrakten er ikke afgørende: retten ser på indholdet af aftalerne og hvordan parterne rent faktisk har samarbejdet. Under en resultatforpligtelse er spørgsmålet, om resultatet blev leveret; under en indsatsforpligtelse, om leverandøren har udvist den omhu, som en rimeligt kompetent og rimeligt handlende IT-professionel har udvist.

Artikel 6:74(1) i den hollandske borgerlige lovbog (BW) er grundlaget for erstatning for en tilskrivelig misligholdelse, men den angiver ikke, hvornår der foreligger en misligholdelse; det afhænger af forpligtelsens kvalifikation. I henhold til artikel 6:248(1) i BW har en kontrakt også de konsekvenser, der følger af rimelighed og retfærdighed, hvilket giver plads til at tage hensyn til samarbejdets agile karakter.

Hvordan strukturerer man en agil kontrakt?

Normalt i to lag. En rammeaftale fastsætter de generelle regler: gældende vilkår, ansvar, fortrolighed, intellektuel ejendomsret og samarbejdsmåde. For hver opgave eller frigivelse fastsætter en implementeringsaftale omfang, planlægning, team, pris og acceptkriterier.

Konkrete, målbare acceptkriterier pr. sprint er vigtigere end etiketten på forpligtelsen. Uden dem er der intet at teste resultatet i forhold til, og der opstår hurtigt uenigheder om, hvorvidt et sprint lykkedes. Inkluder en definition af "done", der ikke kun dækker funktionalitet, men også kodekvalitet, dokumentation og overførbarhed.

Tidlig opsigelse fortjener mere opmærksomhed end i en traditionel kontrakt, fordi et agilt projekt ikke har et fast slutpunkt. Aftal, hvornår hver part må stoppe, hvad der sker med leverede komponenter og kildekode, og hvordan arbejdet overdrages til en anden leverandør.

Standard IT-vilkår, såsom NLdigital Terms, regulerer kun agile aspekter i begrænset omfang. Tjek hvilken udgave der gælder, og registrer de agile aftaler i implementeringsaftalen.

Hvad siger retspraksis om frister?

Der er ingen generel regel om, at en dato i et agilt projekt aldrig er streng. To nylige domme viser, hvordan retten vægter kontrakten og samarbejdet.

Distriktsdomstolen i Midden-Nederland, 2023: streng frist, men ingen ophævelse

I en dom i ECLI:NL:RBMNE:2023:5936 blev der udviklet software til et vejesystem ved hjælp af scrum med en aftalt leveringstid på omkring 24 uger og senere faste kalenderdatoer. Retten fastslog, at disse datoer var strenge deadlines, så leverandøren var i misligholdelse uden varsel, da de overskred aftalen.

Klientens ophævelse mislykkedes ikke desto mindre. I betragtning af projektets agile karakter, det delte ansvar mellem begge parter og det faktum, at kun én arbejdsblok var tilbage, berettigede den manglende løsning ikke ophævelse i henhold til artikel 6:265 i BW. Kravene om tilbagebetaling og erstatning blev afvist.

Distriktsretten i Amsterdam, 22. april 2026: vejledende datoer

I ECLI:NL:RBAMS:2026:3930 hævdede en klient, at udvikleren havde leveret en ny app for sent, overskredet budgettet og vedligeholdt eksisterende apps dårligt. Tilbuddet anvendte to-ugers scrum sprints og en vejledende lanceringsdato.

Retten fandt ingen strenge deadlines: lanceringsdatoen og sprintplanlægningen var vejledende, og scrum-tilgangen krævede et tæt samarbejde. Uden en streng deadline skulle klienten have en gyldig misligholdelsesmeddelelse, og dens meddelelser satte ikke udvikleren i misligholdelse. Alle krav blev afvist.

Lærdommen: Hvis du ønsker en fast dato, skal du angive det udtrykkeligt i kontrakten. En dato i et tilbud eller en e-mail er normalt ikke nok.

Hvad skal du som klient tjekke?

• Hvem er din produktejer, og har denne person mandat til at ændre efterspurgten på dine vegne?
• Er acceptkriterier og en definition af "done" registreret for hver sprint eller release?
• Angiver kontrakten udtrykkeligt, hvilke datoer der er strenge frister?
• Inden for hvilken periode skal du teste og reagere på en leverance, og hvad sker der, hvis du ikke gør det?
• Hvornår får du adgang til kildekoden og dokumentationen?
• Hvad udleveres ved tidlig opsigelse, og til hvilken pris?

Hvad skal man som leverandør tjekke?

• Er det tydeligt, at datoer i tilbud og planlægning er vejledende, medmindre andet er aftalt?
• Registrerer I produktejerens beslutninger og ændringer i ordrebeholdningen skriftligt?
• Registrerer I, når klienten ikke leverer input, testkapacitet eller afgørelser til tiden? Dette kan udgøre kreditors misligholdelse (artikel 6:58 i BW).
• Er betalingsgrundlaget klart: pr. sprint, pr. time, pr. funktionspunkt eller pr. resultat?
• Har du begrænset dit ansvar og udelukket følgeskader i rammeaftalen?

Hvad kan vi gøre for dig med agile kontrakter?

Vores IT-advokater bistår IT-leverandører og kunder med agile projekter. Vi kan:

• udarbejde eller gennemgå en rammeaftale og implementeringsaftaler for et agilt projekt;
• formulere acceptkriterier, en definition af "udført" og klare deadlineklausuler;
• udarbejde en udtrædelsesordning for tidlig opsigelse og overførsel til en anden leverandør;
• vurdere, om en leverandør er i misligholdelse, og om hævning er mulig;
• udarbejde en misligholdelsesmeddelelse eller et svar på en sådan og føre sag om forsinkelse eller ophævelse.

Læs mere om, hvad en IT-advokat laver.

Resumé

• En agil kontrakt består typisk af en rammeaftale og implementeringsaftaler pr. opgave.
• Leverandørens forpligtelse er ofte en forpligtelse til at gøre sit yderste; etiketten i kontrakten er ikke afgørende.
• Målbare acceptkriterier og en definition af "udført" forhindrer uenigheder om, hvorvidt en sprint lykkedes.
• Om en leveringsdato er en streng deadline afhænger af kontrakten og samarbejdet, så angiv det udtrykkeligt; selv en overskredet streng deadline berettiger ikke automatisk til ophævelse (ECLI:NL:RBMNE:2023:5936).
• Reguler tidlig opsigelse, kildekode og overdragelse til en anden leverandør på forhånd.

Ofte stillede spørgsmål