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!