Agil på den fede og sjove måde
Agil på den rigtige måde
Agil er blevet det nye sort. Alle er hoppet med på bølgen og siger, vi er også gået over til Scrum, Kanban og alle mulige andre afskygninger af agile metoder.
Men der er mange versioner af agil udvikling, og jeg har for nylig haft fornøjelsen af at arbejde agilt med en kunde, som i virkelig agilt!
Sidste sommer blev Schultz, hvor jeg arbejder, valgt som leverandør på en løsning til Københavns Universitet (KU), som skulle resultere i en app til de studerende og de ansatte på universitetet. Løsningen skulle implementeres på en helt ny måde - både for universitetet og for os. KU ville gerne have hjælp til at udvikle løsningen, men havde et stort behov for, at de efterfølgende selv kunne vedligeholde og videreudvikle løsningen. De ville samtidigt gerne køre et agilt udviklingsforløb, så de kunne komme hurtigst muligt i markedet med den størst mulige værdi.
KU havde på daværende tidspunkt ikke så stor erfaring med agil udvikling, så derfor ville de gerne have en leverandør, som kunne hjælpe med at få en optimal proces.
En ny produktiv samarbejdsform
Vi indgik derfor et samarbejde, som jeg ikke har prøvet tidligere, men som viste sig, at være meget produktivt og lærerig for begge parter.
KU stillede med Product Owner, udviklere, arkitekt, projektleder og udviklere. Vi stillede med ScrumMaster, arkitekt, projektleder og udviklere. Vi lavede på den måde et fælles team, hvor halvdelen kom fra KU og den anden halvdel fra os som leverandør. KUs team tog ansvar for projektets vision og funktionalitet, mens vi tog ansvaret for den underliggende tekniske løsning - begge tog ansvar for projektet med hvert sit speciale. Universitetet vidste hvad de gerne ville have og ikke mindst, hvilken funktionalitet, som var vigtigst. Vi vidste, hvordan det skulle implementeres, og hvordan man kører et agilt projekt.
Udviklerne fra Københavns Universitet skulle efter projektets ophør være i stand til at supportere, vedligeholde og ikke mindst videreudvikle løsningen med ny funktionalitet. Derfor var de fra starten en integreret del af udviklingsteamet og i høj grad med til at præge retningen i forhold til det tekniske design og implementeringsdetajler. Samtidigt fungerede de som et brohoved ind i KUs driftorganisation, som drifter løsningen. Det var vigtigt, og noget der ofte giver store problemer i projekter er netop overgangen mellem udvikling og drift.
Udfordringerne
Som leverandør er det selvfølgelig en udfordring at indgå i et samarbejde på den måde. Kunden får jo den ultimative indsigt i fabrikken, når de sidder med ved tasterne dag ud og dag ind.
Tillid mellem parterne bliver ekstremt vigtig. Leverandøren skal være klar til at vise kunden, hvordan "pølserne laves", og det stiller jo krav til åbenhed og ordentlighed i fabrikken.
Som kunde skal man jo også have tillid til leverandøren og tillid til, at de har samme mål som kunden: At lave det rigtige produkt - til den rigtige pris.
Er det vejen frem?
JA - der er masser af eksempler på at vandfald, kæmpe kravspecifikationer og lange kontrakter fejler gang på gang. Her kan jo nævnes EFI, Motorregisteret med en kravspecifikation på 16.000 sider, JFS og så videre... Vi kender alle eksemplerne.
Hvordan kan vi forvente et andet resultat, når vi gør det samme igen og igen? Typisk er svaret på endnu en IT skandale, at der bare skal mere kontrol. Flere IT projektråd, mere proces og endnu længere kontrakter, hvor leverandøren skal låses endnu mere fast. Men problemerne ligger jo ikke kun hos leverandøren - de ligger også hos kunden.
Et tillidsfuldt samarbejde mellem de to parter er en vigtig forudsætning for et godt resultat (og også for mange andre forhold i livet). Kunden ved, hvad de vil have og skal tage ansvar herfor. Det er kundens ansvar, at det rigtige laves og kommer ud, så de får mest mulig værdi i projektet. Det er leverandørens ansvar, at det laves på den rigtige måde. Teknikken er leverandørens kernekompetence, og leverandøren skal stå på mål for dette.
Resultatet
Er en app der er installeret af over en tredjedel af de studerende på KU og som løser den grundlæggende ønskede funktionalitet. En app og bagvedliggende platform, som har oplevet meget få fejl, og hvor kunden uden vores hjælp har kunnet supportere og vedligeholde den. Det er endt med en glad kunde og en glad leverandør, og det er jo sådan vi alle helst vil afslutte projekterne. Og så var det faktisk også sjovt undervejs!
Er agil udvikling en 100% forsikring mod fremtidige IT-skandaler – måske ikke, men jeg tror på, at modellen skaber et grundlag for succes. Enig?
