Fra store forkromede IT-løsninger til "Minimal Viable Products" - 5 veje til succesfuld agil implementering

30 år med implementering af IT-løsninger i danske pengeinstitutter har lært mig en del. En af de første erfaringer jeg gjorde mig var, at forretningen har magten, de bestemmer. Så uanset hvilke krumspring jeg gjorde, og hvilken historie jeg fortalte, så købte de ”den” kun, hvis jeg kunne se ”ude fra og ind”. Med fokus på ”What’s in it for me” og forretningsværdi. Jo mere, jeg fokuserede på det, jo mere parate var vores kunder, når vi kom med løsningen.

Tidligere leverede vi IT-løsninger, der kunne det hele – og mere til. Jeg har da i min tid set flere eksempler på såkaldt “Gold plating”, som det vist hedder i dag.

Forretningen troede de vidste, hvad de ville have. Vi formede et projekt, analyserede, designede, testede, tilrettede, analyserede, designede, tilrettede, testede osv.

Og efter et års tid eller mere og flere forsinkelser undervejs, så igangsatte og implementerede vi endelig det store forkromede IT-system.

Og nogle gange – eller ofte – var det ikke helt det, som forretningen ville have. Noget havde ændret sig i deres omverden, vi havde måske ikke forstået brugerne eller inddraget dem så godt, og implementering blev lidt op ad bakke …

Minimal Viable Products

Men nu leverer vi ”Minimal Viable Products”. Og hvad er så det for en størrelse? Jo, det er lige præcis der, hvor nok er nok. Der hvor vi leverer lige nøjagtig nok værdi til, at det giver mening for forretningen at tage i brug.

Jeg bryder mig ikke ret meget om selve ordet, for det er – set ude fra og ind – et lidt negativt ladet ord. ”Skal jeg virkelig nøjes med et minimalt produkt?” – ”Så venter jeg hellere til der kommer noget mere…”.

Men det dur bare ikke i en agil udviklingsmodel, hvor vi ønsker at komme så tidligt som muligt ud til de rigtige brugere og få feedback på, om vi ramte rigtigt. Jo længere tid, vi sidder i udviklingsteamet og analyserer, designer, udvikler og tester, jo mere arbejder vi i blinde og ud fra antagelser. I stedet for at arbejde ud fra feedback, fakta og konkret viden fra brugerne.

Vi har brug for, at løsningerne bliver taget i brug af kunderne, at de får erfaringer med det, at de ser løsningen i den kontekst, den var tænkt – og giver os feedback på, om vi er på rette vej.

Og hvordan gør vi så det?

Mit bud på agil implementering

Tre faser i agil implementering

Det hele starter med, at en ide fødes. Forretningen har et behov, der kan løses og giver værdi med en IT-løsning.

Der etableres et scrum-team. Dette team arbejder med et “Minimal Viable Product”, som de releaser når Product Owner vurderer, at de kan “Go live".

Anden fase er når produktet sættes i gang i sin første version, og dermed igangsættes i produktion.

Nu vil teamet i 14 dages sprints hele tiden forbedre produktet ud fra feedback og forretningsværdi fra brugerne.

Sidste fase er der, hvor forretningen begynder at bruge produktet i sin første version. Det er helt essentielt for den agile udviklingsmodel, at det sker, så snart produktet ser dagens lys.

Det er her implementeringen begynder. Forretningen får erfaringer med produktet, oplever det i den rette kontekst.

På et velvalgt tidspunkt efter ibrugtagningen, vil de begynde at realisere de gevinster, som IT-løsningen giver dem.

5 veje til succesfuld agil implementering

1. Tidlig kommunikation og involvering af kunden

Første step på vejen er at få inddraget forretningen allerede, når ideen fødes. Nogen har fået lov til at investere i udvikling af en IT-løsning, fordi der forventes en gevinst.

Nøgleordene er kommunikation og tidlig involvering. Vi skal give dem ”the big picture”, visionen, værdien.

Ideen skal være så god, at forretningen næsten ikke kan vente til vi går i luften med “Minimal Viable Product.

2. Hold kunden tæt og minimèr udviklingstiden

Når udvikling af produktet starter, handler det om at involvere brugerne så tidligt som muligt og så mange som muligt. For ikke at arbejde i blinde og ud fra antagelser.

Her vil teamet praktisere tidlig pilotdrift, User eXperience discipliner osv.

Udviklingstiden skal være så kort som mulig, så teamet kan begynde at arbejde ud fra konkret feedback og viden.

3. En release giver først værdi, når den er taget i brug

Når teamet har søsat sit “Minimal Viable Product”, er det helt vitalt, at det tages i brug. Jeg gentager lige: "Det giver først værdi, når det er taget i brug. Ikke når det er leveret, men når det er taget i brug.

Ellers kommer det bare til at ligge på hylden og samle støv - evt. sammen med andre kuldsejlede IT-løsninger.

Derfor skal teamet kontinuerligt interessere sig for og måle, om forretningen tager løsningen i brug. Dermed får de etableret et “Feedback-loop”, hvor der løbende indløber feedback til teamet om brug af løsningen. Så de hele tiden kan prioritere og udvikle, hvad der er vigtigst, ud fra hvad brugerne og forretningen melder ind.

4. Flest muligt implementeringer som småændringer

Når vi arbejder agilt, vil vi hele tiden tilstræbe at holde implementering af releases som små og hyppige ændringer, der uden nogen nævneværdig implementeringsindsats kan rulles ud til brugerne.

Tænk på, hvordan App Store fungerer med automatiske opdateringer. På samme måde her kan man måske liste små nyheder ind i funktionerne, så de popper op, når brugeren arbejder med funktionen. Så virker det relevant og nærværende.

Jo flere implementeringer vi kan klare på denne måde, jo billigere og mere effektiv bliver implementeringsindsatsen.

5. Realisering af gevinster i rette tid

Agil implementering lægger op til, at forretningen tager et mere minimalt produkt i brug fra starten. Et produkt, der giver værdi, men måske ikke er helt udbygget endnu.

Product Owner kan måske levere nogle release forecasts, som viser en forventet udvikling, som forretningen kan tage udgangspunkt i.

Ellers vil de løbende opleve forbedringer af produktet, og dermed vil realiseringen af gevinster blive en mere asynkron proces i forhold til igangsætningen af produktet.

Graf over forretningsværdi contra antal releases

Grafen på billedet skal illustrere, hvordan forretningsværdien af produktet stiger i takt med de releases, der leveres fra teamet. Den forretningsansvarlige vil nu i ro og mag planlægge, hvornår det giver mening at høste gevinsten, både i forhold til produktets tilstand og øvrige aktiviteter, der skal koordineres i forretningen. Det vil ikke ske som vi tidligere lagde op til: BIG BANG! Også omlægger forretningen forretningsgangen, arbejdsgange, processer m.m., når den store forkromede IT-løsning kom.

Men det skete så heller ikke altid før ... Så vidt jeg husker ...

Tøv ikke!

Så start med MVP, kom igang med produktet.

Start med en donut uden krymmel. Få en senere med krymmel, og få til sidst et helt fad med forskellige slags donuts

Så kan vi nå at lave opskriften om, hvis du ikke kan lide den, inden vi laver hele fadet.

Og vi kan ovenikøbet lave dem med lige nøjagtig den slags krymmel, du allerbedst kan lide.

Hvis bare du giver dig tid til at smage på dem ...

God appetit!