Hvordan forandrer og forankrer vi, når IT-løsninger bliver implementeret agilt? Del 2

Vi skal videre i implementeringen og zoome ind på fase 2 i min model for agil implementering med ADKAR indarbejdet.

Vi skal se nærmere på, hvordan vi får givet brugerne lyst til at tage IT-løsningerne i brug, når den sættes igang, og hvordan vi sikrer at de bliver ved med at bruge dem.

Fase 2 i agil implementering ser sådan ud med ADKAR elementer indarbejdet:



Fase 2 og ADKAR

Denne fase dækker både, når der releases en ny IT-løsning i sin første spæde version (MVP), og når vi efterfølgende løbende frigiver releases til løsningen, der kontinuerligt bidrager med forretningsværdi, fx med 14 dages sprints.

I min forrige artikel, der behandlede fase 1, gjorde jeg en del ud af de første første elementer i ADKAR, nemlig Awareness og Desire.

Det er helt grundlæggende, at brugerne - når de modtager information om, at en ny løsning er sat igang - kender til løsningen, har hørt om den (Awareness) og der er skabt Desire for at tage den i brug.

Der er altså et pænt salgsforarbejde, der skal gøres, så brugerne nærmest står og venter på det kommer.

Alt dette kan du læse om i omtalte artikel og er en forudsætning, når teamet går "live" med deres løsning.

Næste trin i ADKAR er derefter:

Knowledge

Det tredje element i ADKAR, Knowledge, er nok den disciplin, som vi i tidens løb har været bedst til som IT-leverandør: Hvad kan den? Hvordan bruger du den? osv.

Vi holder kurser, vi udvikler e-learningsmoduler, vi laver kvik-guides, vejledninger, tips & tricks, instruktionsvideoer.

Der er ikke grænser for, hvad vi har leveret af Knowledge sammen med IT-løsningen.

Det nytter bare ikke ret meget, hvis Awareness og Desire ikke er på plads inden.

Ny IT-løsning

I en agil kontekst, kræver det måske knap så meget Knowledge at tage en ny IT-løsning i brug, fordi:

• Den er mindre, og skåret til, så den indeholder præcist hvad der er brug for i forretningen
• Brugerne har været tæt på i det korte udviklingsforløb, scrum-teamet har gennemført, inden første release. Pilot-tests, User-eXperience, feedback osv. Kort sagt: En mere intuitiv løsning
• Teamet måske har spurgt brugerne, hvad der er brug for, for at komme igang. Er der brug for for meget støttemateriale, skulle teamet måske kigge nærmere på løsningen. Er det intuitivt nok at anvende?

Løbende forbedringer

Målet for de løbende leverancer skal være, at de kan rulles ud til brugerne direkte.

Det kan være en god ide at supplere med nyheder, der popper op lige der, hvor brugeren skal gøre noget anderledes eller være opmærksom på en forbedring.

Det har vi fået god feedback på i Bankdata, hvor vi har etableret en særlig nyhedsfunktion til de små ændringer.

Kræver en ændring, at brugerne ændrer adfærd, skal der måske suppleres med lidt ekstra implementeringsmateriale.

Det kan være en lille instruktionsvideo, der kort og præcist fortæller formål, værdi (Awareness, Desire) og hvordan (Knowledge)


Ability

Hvor Knowledge handler om at få viden om nye features, løsninger - ny adfærd og nye færdigheder - så handler Ability om virkeligheden. Har brugerne vist ny adfærd i hverdagen? Kan de bruge de nye features, den nye løsning?

Ability handler om at omsætte viden til praksis.

Dette element i ADKAR har primært sin berettigelse ved release af nye IT-løsninger, da de løbende forbedringer gerne skulle være intuitive og let omsættelige fra viden til praksis.

Så når vi snakker implementering af nye IT-løsninger, handler det om "hands-on", at prøve det af inden "go-live". Måske i et beskyttet uddannelsesmiljø, hvor de kan dumme sig og lave fejl uden konsekvenser.

Og undervurdèr ikke den tid, der skal sættes af her. Ofte har brugerne brug for tid til at indse, hvad forandringen går ud på. Derfor skal du give dem tid til at øve sig.

I sidste ende er det jo bundlinie, det handler om. For det er først, når brugerne anvender løsningen som tiltænkt, at gevinsten kan realiseres i forretningen.

Reinforcement

Og hvis vi fortsætter bundlinie-snakken, så er Reinforcement helt afgørende.

Det er her vi måler, om forandringen holder ved. Det er her vanens magt kan få overtaget. For vores hjerne er jo programmeret til rutiner, vaner, samme adfærdsmønstre. Hvorfor det pr. definition er svært at forandre.

Derfor skal der lægges en stor indsats i dette sidste, afgørende element i ADKAR.

Vi skal se Reinforcement fra to perspektiver i en agil kontekst:

• de små løbende forbedringer, som teamet releaser efter hvert sprint
• De nye produkter, der lanceres i deres første spæde version (Minimal Viable Product)

Det er de små løbende forbedringer, vi skal se nærmere på her. Vi kigger nærmere på nye produkter i min næste artikel, hvor vi kigger nærmere på sidste fase af agil implementering - der hvor IT-løsningen rammer forretningen.

Reinforcement ved løbende værdiskabende releases

Det er teamets medansvar at sikre Reinforcement, hver gang de releaser. De skal interessere sig for, om releasen:

• Tages i brug
• Giver den forventede værdi i forretningen, hvor lille den end måtte være

For hvis ikke teamet efter hver release sikrer sig, at den tages i brug, må de stoppe op, og spørge sig selv hvorfor:

• Fik vi ikke informeret brugerne godt nok om releasen?
• Havde releasen ikke den forventede værdi?

Lykkes det ikke helt, skal vi helt sikkert bakke tilbage og hen i ADKARS's første faser, Awareness og Desire. Eller give Product Owner feedback om, at releasen ikke havde den forventede værdi, så han/hun kan blive mere skarp i sin prioritering fremadrettet.

Kig med igen

Når jeg folder sidste fase af min model for agil implementering ud. Her har jeg en rigtig succeshistorie med fra det virkelige liv.

På genkig!

Hvordan forandrer og forankrer vi, når IT-løsninger bliver implementeret agilt? Del 1

Hvordan forandrer og forankrer vi, når IT-løsninger bliver implementeret agilt? Del 1

I min forrige artikel “Fra store forkromede IT-løsninger til “Minimal Viable Products” fik I et overblik over, hvordan I kan gribe agil implementering an. Tre faser i implementeringen og fem veje til succesfuld agil implementering.

Det lød jo meget nemt. Men alle, der har deltaget i eller ledet forandringsprojekter, ved at der ikke er noget, der er “bare lige”, når vi implementerer IT-løsninger med stor impact hos den enkelte medarbejder.

Kulturen, vanerne, “plejer” har det nogle gange med at æde forandringen lige så stille, og den opnåede effekt udebliver. Og investeringen i IT-løsningen var forgæves.

Vi skal ud i sidste led
Implementeringen sker nemlig ude hos den enkelte medarbejder.
Implementering handler om mennesker.

Lykkes vi helt derude i sidste led i organisationen, kan vi tillade os at læne os tilbage og sige “Tjek 👌 - job well done!”.

Det er det enkelte individ, der skal ønske en forandring, for at det sker, og det kræver hårdt arbejde og klares sjældent kun med top-down kommunikation og information.

Vi skal ud decentralt. Helt ud i sidste led.

ADKAR

Fornylig stiftede jeg bekendtskab med forandringsmodellen ADKAR, der bygger på fem trin i forandringen.

Fem trin, der skal gennemgåes for at sikre succes med sit forandringsprojekt.

Alle fem faser skal håndteres i pilens retning, og lykkes forandringen ikke, skyldes det formentlig at man hoppede et led i kæden over, og man må så bakke tilbage og rette op.

Kender du ikke modellen, kan du læse mere her

Den gav god mening for mig som implementeringskonsulent, fordi den bl.a. sætter fokus på det svære i en forandring.

Samtidig er den god som fælles referenceramme, fordi den er simpel og let at forstå.

ADKAR i agil implementering

Jeg kunne ret hurtigt se ADKAR anvendt i min model for agil implementering i de forskellige faser, og hvor de forskellige discipliner i ADKAR kunne sættes ind. Det faldt sådan ud:

Model for agil implementering med ADKAR elemener

I denne artikel vil jeg sætte fokus på første fase i agil implementering, hvor ADKAR kommer i spil i første trin - der hvor ideen til IT-løsningen fødes, og vi for alvor skal have skabt en bevidsthed og interesse for produktet.

Senere vil jeg fordybe mig i fase 2 og 3.

Awareness og Desire

Fase 1 af agil implementering

I den fase, der handler om at få udviklet “Minimal Viable Product”, handler det om at få skabt awareness og desire hos forretningen, allerede når ideen fødes.

Awareness

Alle, der senere skal modtage IT-løsningen, skal først og fremmest gøres bevidste om IT-løsningen. Der skal skabes awareness. Det kan man gøre ved fx at stille følgende spørgsmål:

- Hvorfor er forandringen nødvendig?
- Hvorfor er forandringen nødvendig nu?
- Hvad er der galt med den måde, vi gør det på i dag?
- Hvad sker der, hvis vi ikke gør det?

Nøgleordene er tidlig kommunikation. Og gerne gentaget 5-7 gange, så vi er sikre på, det holder ved. Nogle gange kan IT-løsningen skabe en brændende platform. “Hvis ikke vi tager det i brug, kan vi ikke længere …”. Et incitament man med fordel kan tilstræbe at få skabt.

Prøv også at differentiere kommunikationen i forhold til de målgrupper, der rammes af forandringen. Nogen bliver måske påvirket mere end andre.

Det er også helt afgørende, at ledelsen her træder i karakter og får skabt bevidsthed om vigtigheden af forandringen. Husk, at den vigtigste faktor for succes med forandring er en aktiv og synlig topledelse!

Når der er opnået en tilpas grad af awareness, er næste step:

Desire

Desire er i denne sammenhæng den sværeste disciplin, som jeg ser det. Fordi vi her bevæger os ind i det personlige, det enkelte individ, den enkeltes identitet.

Hvad styrer ønsket om at ville forandre sig? Hvad er den iboende motivation for det? What’s in it for me? Kort sagt: Hvad skal der til?

Det er her den decentrale indsats er helt essentiel for at få skabt ønsket om forandring.

Den decentrale indsats kan være drevet af et korps af forandringsagenter, coaches, som lokalt er tæt på medarbejderne og sikrer at forandringen sker - at den nye IT-løsning bliver taget i brug, at nye arbejdsmetoder virker og giver den ønskede effekt.

Men en anden væsentlig spiller er også nærmeste leder, som skal klædes på til at håndtere sine medarbejdere og motivere til at skabe desire. Det er der meget psykologi i, og nærmeste leder skal "spilles god" for at kunne coache sine medarbejdere individuelt og finde ud af, hvad der driver den enkelte - hvad der skal til.

Modstand

Ofte vil man støde på modstand. Det er der skrevet mange bøger om. Jeg har praktisk erfaring med to modeller, som har hjulpet mig i forskellige sammenhænge.

Den ene model arbejder med tre niveauer af modstand:



De tre niveauer af modstand

Det er vigtigt at finde ud af, hvor modstanden hos den enkelte bor i modellen og agere ud fra dette.

Hvis medarbejderen fx ikke kan lide forandringen (niveau 2), er det vigtigt at få kortlagt, hvori den følelsesmæssige modstand består. Er det frygten for at miste sit arbejde, er det frustration over at skulle lære andre arbejdsopgaver osv.

Den forståelsesmæssige modstand (niveau 1) handler meget om awareness, dvs. information, kommunikation, lytte, se ude fra og ind.

Den personorienterede modstand (niveau 3), kan nogle gange håndteres ved at lade en anden komme til.

Det kan være nøglepersoner med gennemslagskraft i virksomheden, som er pro forandringen og meningsdannere.

Lad måske dem kommunikere budskabet, være aktive og synlige i forandringsprocessen.Men glem nu ikke vigtigheden af signalerne fra den øverste ledelse og de budskaber, der kommer derfra. De er meget afgørende.

Modstandskurven

Den anden model handler om modstandskurven:

Modstandskurven

Den fortæller, at størstedelen af medarbejderne (Ca. 70%) ligger i “overbevis mig” kategorien, og det er den skare af medarbejdere, indsatsen skal fokuseres på.

Dem, der løber forrest, er jo med, og dem, der indædt ikke ønsker forandring, skal du i første omgang ikke bruge så meget krudt på.

Vent til senere, og se om du kan få overbevist selv de største skeptikere. Bare de ikke bliver meningsdannere og æder for mange af "overbevis mig" kategorien.

Eksempel fra det virkelige liv

Jeg deltog for ca. 10 år siden i et projekt, hvor en række opgaver blev flyttet fra en administrationsafdeling og ud til de rådgivere, der havde kundekontakt.

Målet var “Datafangst ved kilden”, hvilket betød at rådgiverne fremfor at skrive små gule sedler til en sekretær, der efterfølgende indtastede oplysningerne i et IT-system, så skulle de selv indtaste oplysningerne i en nyudviklet og mere intuitiv løsning.

Det var mange steder en udfordring. Nogle rådgivere kunne virkelig ikke se ideen med at de skulle “sidde og taste noget ind i et edb-system”, og der var spredt modstand i alle organisationer.

Tab af prestige

Da vi så gik helt tæt på nogle af de største skeptikere, kunne vi forstå, at der for mange var prestige i at have en sekretær, der lige ordnede alt det administrative.

Og det tab af prestige betød for mange, at de blev ramt på deres identitet.

Nogle steder valgte man simpelthen at ignorere de værste i starten og fokusere på dem, der tvivlede og måske bare skulle have flere informationer og forstå hvorfor. (Awareness).

Og efterhånden som flere af de største skeptikere overgav sig til den nye løsning, så kom de sidste også med. Måske fordi de til sidst kom til at stå lidt alene med deres holdning.

Brug 40% af tiden på de to første faser

40% af tiden på Awareness og Desire

Fordelingen af tid, der skal bruges i de fem faser, er nogenlunde fordelt således, at der skal ofres næsten halvdelen af tiden på de to første faser.
Lykkes vi ikke med det, er det stensikkert, at vi på et tidspunkt må bakke tilbage og besøge faserne igen. Det er her fundamentet for forandringen sker.
Det er også her, den sværeste disicplin i min optik findes. Nemlig Desire.

Jeg vender tilbage

Læs med næste gang, hvor jeg fokuserer på KAR i ADKAR-modellen og fase 2 af den agile implementering.
Der hvor vi med hyppige leverancer med fokus på forretningsværdi, skal have kunderne til at tage løsningerne i brug og give feedback.
På genkig!

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!