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?
- Danmarks største job- og karrieresite for ingeniører og it-professionelle.
Hej Kim
Du siger "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."
Kan du oplyse hvad det er for et problem du mener at have konstateret med Motorregisteret? (Jeg formoder du er klar over at EFI og Motorregisteret er to forskellige projekter, det ene inddriver gæld, det andet bruges til at indregistrere køretøjer.)
Hej Morten,
Tak for din kommentar. Jeg kender ikke projektet i detaljer, men fulgt det på sidelinien i fx version2 og computerworld.
Der skal ikke mange Google søgninger for at se, at:
Næppe noget jeg vil kalde en succesfuld proces.
Jeg kan godt følge din betragtning. Projektet har været forsøgt startet et antal gange og jeg var usikker på hvilket af forsøgene du omtalte.
Men dejligt at det i det mindste kom i mål og i følge skat giver forretningsværdi.
Som jeg har læst det, så skete det da man opdelte i mindre leverancer og en ny udbudsform. Det lugter jo lidt af agilt - selvom jeg ikke kender alle detaljerne :-)
Fedt at høre at projektet gik godt og at kunderne og slutbrugerne er glade for resultatet!
Det virker som om agile metoder har slået ekstremt bredt igennem når der internt i en organisation skal udvikles et produkt. Men er der tale om en ekstern kunde, vil de oftest insistere på en kontrakt med en relativ fast pris og leveringsdato, hvilket gør en agil tilgang noget sværere.
Har selv startet konsulentvirksomhed for 1½ år siden, og går efter at sælge produktudvikling i sprints i stedet for at binde os selv og kunden op på store 500 siders kontrakter, som ingen alligevel gider læse - det er gået ganske fint indtil videre :)
Så kan man skære i scope - det er jo også her at de agile metoder kommer til sin ret. De agile metoder giver ret god indsigt i hvor meget der udestår i product backloggen og teamets velocity. Disse kan sammenholdes med leveringsdato og man kan se, hvor meget der kan nåes indenfor denne tid. Da Product backloggen er prioriteret, så ligger de vigtigste krav forhåbentlig nederst og derfor gør det mindre ondt, at de måske ikke nåes i første leverance.
Jeps, hvis kunden er med på at ikke at forsøge at fasttømre scope i kontrakten, vandfalds-style. Hvilket i mine øjne er et godt tidspunkt enten at dreje kunden i retning af en agil process eller finde en anden kunde, hvis det viser sig ikke at være muligt.
Hej Kim
Mange fine betragtninger og i øvrigt tak for det gode samarbejde omkring app og platform. Vi er stadig meget glade for resultatet. Med vores forståelse for løsningen har vi nu mulighed for at se nærmere på Xamarin Forms. Noget tyder på at det kan nedsætte omkostninger til vedligehold og nyudvikling – Ikke helt uinteressant for Københavns universitet selvom vi er dømt kornfede af vores fremsynede minister
Der er en enkelt ting hvor jeg synes myndighederne måske slipper lidt for nemt. Du skriver at det er leverandørens ansvar at sikre at tingene laves på den rigtige måde. Det er naturligvis også rigtigt, men jeg vil mene at man som ansvarlig for at forvalte skatteborgernes penge på den bedste måde, også skal have en vis indsigt i og et vist ansvar for kvaliteten af en løsning. Det er noget som man skal have en dialog om undervejs – På lige fod med omfang, tid og penge. Jeg har set projekter som blev dømt som successer ud fra disse 3 kriterier, men hvor teknisk gæld resulterede i en stor vedligeholdelsesopgave efterfølgende.
Det kræver selvfølgelig at myndigheden har kompetencerne til at indgå i denne dialog og at de har modenheden til at acceptere at skære en hæl og klippe en tå om nødvendigt, men man kan gøre det med åbne øjne og med forståelse for konsekvenserne.
Hej Rasmus,
Tak for din kommentar og for det gode samarbejde :-)
Jeg er fuldstændig enig i at kunden også bør tage del af ansvaret for den tekniske løsning på samme måde, som leverandøren også skal forstå og rådgive kunden ift. deres forretning.
Mit argument er mere, at man skal tage det største ansvar hvor man har sine kompetencer - leverandøren på teknikken og kunden på sin forretning.