I et agilt projekt findes aftalen om, hvad der skal leveres, ikke kun i kontrakten. Den findes også i backloggen, i sprintplanerne, i godkendelserne efter hver sprint og i de beslutninger, jeres product owner har truffet undervejs. Når et agilt projekt ender i en tvist, er det derfor projektværktøjets historik, der skal sikres først. Uden den kan ingen af parterne vise, hvad der blev aftalt, prioriteret og godkendt.
Artiklen er til ledelsen, product owner og IT-chefen hos kunden. Den handler om det, der er særligt ved agile projekter. Det generelle om IT-projekter, der går galt, er beskrevet for sig. → IT-projektet er gået galt: jeres første skridt
Hvorfor agile projekter er svære at dokumentere
I et klassisk projekt beskriver kravspecifikationen, hvad der skal leveres, og leverancen kan holdes op mod den. I et agilt projekt bliver kravene konkretiseret undervejs. Det er en styrke, når samarbejdet fungerer. I en tvist bliver det en svaghed, fordi det er uklart, hvad der var aftalt på et givet tidspunkt.
Digitaliseringsstyrelsen har udgivet K03, en standardkontrakt til agile IT-projekter. Styrelsen oplyser, at K01, K02 og K03 på flere områder ikke længere er tidssvarende og ikke længere opdateres. Mange agile aftaler er derfor leverandørens egne eller bygget på andre skabeloner. Fælles for dem er, at de ofte henviser til en proces: hvordan backloggen styres, hvordan sprints planlægges og godkendes, og hvem der har mandat til at træffe beslutninger.
Det, der tæller som dokumentation
- Backlog med historik · Hvilke krav der fandtes, hvornår de blev ændret, og af hvem
- Sprintplaner · Hvad leverandøren forpligtede sig til i hver sprint
- Sprintgodkendelser · Hvad kunden accepterede, og med hvilke forbehold
- Definition of done · Hvornår en opgave regnes som færdig
- Referater fra sprint reviews · Hvad der blev vist, og hvad der blev sagt
- Optagelser af demonstrationer · Hvordan systemet faktisk fungerede
- Estimater og forbrug · Hvor meget tid der blev brugt i forhold til planen
- Kodehistorik · Hvad der faktisk blev udviklet, og hvornår
Den vigtigste kilde er backloggens historik. Et udtræk, der kun viser backloggen, som den ser ud i dag, er ikke nok. I skal kunne se, hvordan den så ud på bestemte datoer, og hvem der ændrede hvad.
Sikr projektværktøjet nu
Agile projekter styres næsten altid i et værktøj som Jira, Azure DevOps eller lignende. Ofte er det leverandøren, der ejer instansen, og jeres adgang kan blive lukket, når samarbejdet bryder sammen.
- Eksportér alle sager med fuld historik, kommentarer, vedhæftede filer og statusændringer.
- Eksportér sprintoversigter, så det fremgår, hvilke sager der var i hvilken sprint.
- Gem tavler og rapporter som PDF eller skærmbilleder med dato, fx burndown og velocity.
- Notér, hvem der har administratoradgang, og om nogen kan slette eller ændre historik.
- Bed leverandøren skriftligt om at bevare hele instansen uændret, hvis I ikke selv har fuld adgang.
En eksport fra et projektværktøj indeholder ikke altid al historik. Tjek, hvad eksporten faktisk viser, og overvej at få sikringen lavet, så den kan efterprøves. → Jira, Zendesk og ticketsystemer som bevis
Sprintgodkendelser er tveæggede
I mange agile aftaler godkender kunden hver sprint eller hver leverance. Godkendelserne er vigtige beviser, men de kan bruges mod jer. Har jeres product owner godkendt en sprint uden forbehold, kan leverandøren hævde, at det leverede var i orden. Saml derfor alle godkendelser, og notér for hver af dem:
- hvad der blev godkendt, og hvad der ikke blev,
- om der var forbehold, og hvor de står,
- om godkendelsen var en egentlig accept eller blot en registrering af, at sprinten var slut.
Gem også mails og chats omkring hver godkendelse. De viser ofte, at en godkendelse blev givet under tidspres, eller at der samtidig blev peget på fejl, som skulle rettes i næste sprint. Fremover: godkend kun det, der faktisk virker, og skriv forbehold ind i godkendelsen, ikke i en separat mail, der kan blive overset.
Product owner er et nøglevidne
Jeres product owner har typisk truffet mange af de beslutninger, der nu er omstridte: prioriteringer, fravalg og accept af løsninger. Det gør personen til et vigtigt vidne. Bed om, at product owner skriver en kort, saglig beskrivelse af forløbet, mens det er friskt, med henvisninger til sager og referater. Hvis product owner har forladt virksomheden eller er en konsulent, så sørg for at få beskrivelsen, før forbindelsen bliver svær. → Medarbejdere skal afgive forklaring
Gem også product owners egne arbejdsnoter, prioriteringslister og mails med leverandøren. De viser ofte begrundelsen for en beslutning, som backloggen kun viser resultatet af. Kortlæg også, hvem der ellers har haft mandat til at ændre i backloggen. Ændringer foretaget af personer uden mandat kan blive et stridspunkt.
Ændringer i et agilt projekt
I et agilt projekt er det normalt, at kravene ændres. Spørgsmålet i en tvist er derfor ikke, om der var ændringer, men om de lå inden for den aftalte ramme, eller om de udvidede projektet. Leverandøren vil ofte forklare forsinkelse eller merforbrug med jeres nye ønsker. Saml de sager, der blev tilføjet undervejs, og notér, om de erstattede andre opgaver, eller om de kom oven i. Sammenlign med den første backlog eller løsningsbeskrivelse, så det kan ses, hvor meget rammen faktisk flyttede sig. → Ændringsønsker og ekstraregninger
Hvem gør hvad
- Ledelse · Beslutter retning og involverer advokat
- Product owner · Beskriver forløbet og beslutningerne
- IT-chef · Sikrer projektværktøj, kodehistorik og miljøer
- Scrum master eller projektleder · Samler referater, sprintplaner og godkendelser
- Advokat · Vurderer aftalen og processens betydning
- IT-sagkyndig · Vurderer de tekniske forhold uvildigt
Det må I ikke gøre
- Lukke sager eller rydde op i backloggen, efter tvisten er opstået.
- Ændre definition of done med tilbagevirkende kraft.
- Godkende flere sprints for at holde projektet i gang, uden forbehold.
- Lade product owner forlade projektet uden at få forløbet beskrevet.
- Basere jer på leverandørens rapporter alene. Hent selv data fra værktøjet.
Hvornår skal I have hjælp udefra?
Når uenigheden handler om, hvad der blev leveret i forhold til backloggen, om kvaliteten af det leverede, eller om tidsforbruget var rimeligt. En uvildig IT-sagkyndig kan vurdere de tekniske forhold, holde backlog, kodehistorik og leverancer op mod hinanden og sikre projektværktøjets data. Nielco IT har været IT-sagkyndig i danske retskredse og er uvildig. → IT-skøn i tvister om IT-projekter og software
Læs også: Open source-licensen er brudt: tvisten om jeres produkt · Leverandøren leverer ikke: dokumentér IT-projektet
→ Tvist med en IT-leverandør eller en kunde · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
