Efterhånden som virksomhederne bevæger sig med softwareløsninger fra on-premise til skyen, sætter de sig ofte som mål at blive mere “agile”. Dette bør ofte gælde ideelt for alt på tværs af virksomheder. Og selvfølgelig alle steder på samme tid.
Transformation af processerne kunne let være mulig, i det mindste i teorien. Du kan definere scrum-ceremonier og omplacere folk til nye roller (såsom scrum-mestre, produktejere, leveringschefer og scrum-teams).
Du kan medbringe værktøjer som Jira, Azure ADO og Miro boards og gøre dem obligatoriske at bruge. Men hvad med de processer, der forbinder værktøjerne? Hvad med at transformere folks sind, adfærd og måder at arbejde på? Det bliver klart, at de ikke vil forvandle sig glat, og de vil heller ikke afslutte hurtigt. Lad os nu se hvorfor.
Indholdsfortegnelse
Hvad er et leveringstransformationsinitiativ, og hvorfor gør virksomheder det?
En stor del af virksomhederne arbejder i dag stadig efter vandfaldsleveringsmodellen. Det betyder at:
Hele denne proces kan tage et par måneder til et par år, og som du kan se, vil brugerne først se resultaterne i slutningen af denne proces. Så efter lang ventetid kommer sandhedens (eller fiaskoens) øjeblik.
Hvis noget ændrer sig i løbet af så lang tid, og slutproduktet skulle se lidt anderledes ud, er det en situation, der kaldes en ændringsanmodning. Designet skal genåbnes, omarbejdes og gengodkendes. Det forlænger hele tidsplanen med en anden del.
Det er klart, at dette ikke er adræt på nogen måde. Hver ændring kræver en genstart af hele processen før.
Skifter til Agile
Så hvordan kommer vi ud af denne situation og ændrer den til at blive agile? Folk arbejder i vandfaldsopsætningen i mange år eller endda århundreder. De har roller og ansvar, de er komfortable med, og de ønsker ikke at ændre status quo. Hovedårsagen til det er, at denne ændring i sidste ende betyder at miste noget af den magt, de havde indtil nu.
Dette er hovedårsagen til, at en sådan forandring trækker det stærkeste niveau af modstand fra de mennesker, som du overhovedet kan skabe.
#1. Omstrukturering af teamet
Det første og relativt enkleste at gøre er at omstrukturere folket til scrum-teams. Opdel dem baseret på de funktionelle områder eller enhver anden logisk opdeling, der giver mening.
Spaltningen går normalt glat; problemet starter, når du indser, at folk stadig er bundet til de oprindelige strukturer. Selvom de allerede er en del af de nye scrum-hold, er de det praktisk talt ikke. De arbejder stadig på det gamle setup, fordi de stadig har ansvar, der ikke blev afsluttet sammen med teamomstruktureringsprocessen (fordi hvorfor skulle det være det – ledelse bekymrer sig ikke meget om, hvad der skal afsluttes, men mest om, hvad der skal startes).
Så praktisk talt ender du med et scrum-hold, der ikke er fuldt dedikeret scrum-hold. Det er en gruppe mennesker, der nu simpelthen har mere arbejde at gøre. Der er ikke så meget tid til arbejdet inde i scrum-teamet, som ledelsen forventer.
Samtidig er forventningen, at folket afslutter deres oprindelige aktiviteter samt denne nye forventning inde i scrumholdene. Det er et setup, der er fast besluttet på at mislykkes lige i begyndelsen.
#2. Planlægning af Scrum-ceremonier
At beordre holdene til at planlægge flere regelmæssige opkald (sprintceremonier) er let at definere og starte. I det mindste, forudsat at dine scrum-hold ikke består af folk fra 3+ tidszoner (hvilket ofte er tilfældet).
Problemet starter, når folk ikke vil deltage i ceremonierne på en regelmæssig basis. Afhængigt af hvem der mangler og hvor ofte, kan dette udvikle sig til forskellige slags problemer. For eksempel:
- Hvis produktejere ikke deltager i planlægnings- og forfiningsceremonierne, har teamet ingen nye historier at arbejde videre med. Eller også er beskrivelsen af historierne så dårlig, at resten af teamet ikke kan begynde at arbejde med dem.
- Hvis der mangler scrum-mestre ved opkaldene, mangler holdet grundlæggende scrum-orkestrering og kan med tiden gå tabt.
- Hvis teammedlemmerne i udviklingsteamet ofte mangler, kan de ikke synkronisere med hinanden, og kommunikationen inde i teamet er meget sværere. Der kræves også flere møder for at indhente det, hvilket tager endnu en tid fra holdet.
I sidste ende er det ikke nødvendigvis folks skyld, at de går glip af ceremonierne. Det er bare opsætningen, der ikke vil tillade dem at være på opkaldene (se ovenfor om parallelle tidligere opgaver).
#3. Holdets stabilitet
Du har måske et scrum-hold med struktur og ceremonier, men hvis det hold ikke er stabilt over længere tid – lad os sige mindst et halvt år ideelt set, et år med stabilitet ville være mit personlige minimumskrav – så kan sådan et team ikke rigtig udvikle sig og forbedre.
Dernæst når du nok aldrig et helt uafhængigt scrum-team, der håndterer spurterne som business as usual. Endelig bliver du nødt til konstant at uddanne og lære folk inde i teamet for at forstå scrum-tankegangen og processerne. Det er et udmattende problem at have.
Dette er et meget undervurderet problem, specielt af ledelsen eller ledelsen af virksomheden. At kalde teamene af mennesker bare for “ressourcer” og planlægge deres “udnyttelse” fra kvartal til kvartal er en øjeblikkelig vej til helvede.
#4. Nye roller for de samme mennesker
En anden hindring at overvinde er at omplacere eksisterende mennesker til forskellige nye roller. Dem, der tidligere ledede teams med ultimativ magt, kan nu for eksempel blive produktejere. Dette er en stærk position i et scrum-team, men det kan ses som en svagere rolle i forhold til det eksisterende setup.
Pludselig skal produktejerne synkronisere med scrum master eller programledere. De er stadig ansvarlige for indholdet, men ikke så meget for leveringsprocesserne. Denne situation kræver at give afkald på nogle ansvar, som folk tidligere havde, og derfor er svære at sluge.
#5. Måder at arbejde på
Denne er interessant, og jeg hører den i ny og næ ret tit – vi skal lære nye måder at arbejde på for at blive relevante på det udviklende marked, hvor agility er den grundlæggende forventning. Men hvad betyder det helt præcist de måder at arbejde på?
Spørger du mig, er det tydeligt, hvad ledelsen mener med det – at nå (meget) mere på kortere tid. Efter at have oprettet scrum-holdene er forventningen, at hvert teammedlem pludselig vil opnå nogle dokumenterede trinvise resultater fra dag til dag. Hvis det ikke er tilfældet, vil ledelsen begynde at spørge, hvorfor den agile proces ikke fungerer godt.
Lige ud af ingenting forventer ledelsen, at hver time tæller, og at scrum-holdene stort set ikke har nogen ledig tid, bare fordi der formentlig ikke er plads til det, vil alle scrum-processerne være på plads. Og det er definitionen af ”nye måder at arbejde” fra ledelsesperspektivet i en nøddeskal.
Selvfølgelig er denne forventning ikke bygget på realitetstjekket. Det er en illusion at forvente, at folk i virksomheden begynder at arbejde mere inden for samme periode, bare fordi nogle dag-til-dag-processer vil ændre sig. Jeg mener, nogle af dem kunne, selvom det kun var et mindretal. Men selv denne gruppe reduceres yderligere ved at fylde dem med flere opgaver på samme tid.
Forskellen mellem mål og virkelighed
Der er ingen tvivl om, at beskrivelsen af slutmålet ofte er god, og det giver rigtig god mening. Det handler om følgende principper:
- Stabiliserede scrum-teams, der arbejder på uafhængige backlogs med klare KPI’er og OKR’er.
- Produktejere til at opbygge solide køreplaner og planlægge prioriteret indhold til at levere i forhold til konkrete tidslinjer.
- Defineret backlog-indhold med relevante funktioner, der allerede er detaljeret inden arbejdet startede.
- Pålidelige testprocesser udført sideløbende med det almindelige sprintudviklingsarbejde.
- Regelmæssige udgivelser til produktion – mindst én gang om måneden, men ideelt set efter hver sprintafslutning.
- Risici og problemer sporing og kommunikation mellem de forskellige scrum-teams i tilfælde af afhængigheder.
Så når det kommer til virkeligheden, kan jeg fortælle, at ingen af ovenstående punkter er nemme at opnå.
- Man danner scrum-holdene, men de ændrer sig konstant (fra kvartal til kvartal). Du investerer tid i at lære teamet scrum-processerne, og når de endelig begynder at acceptere det og ændre deres måde at arbejde på, omorganiserer du teams til næste periode. Køreplaner ændres, flyttes eller annulleres.
- Produktejere har ingen reel anelse om detaljerne i køreplanen, og (bare fordi de havde sådanne vaner før) vil de tildele deres opgaver med at opbygge backlog-indholdet direkte til teamet. Som et resultat har teamet ikke tid til at udvikle indholdet, da de først skal finde ud af, hvad de skal udvikle.
- Testprocesser er kun manuelle og kræver en masse deltrin og godkendelser og komplicerede processer at følge. Det betyder, at testen ikke kan afsluttes inden for samme sprint, som udviklingen gør.
- Som en konsekvens heraf halter release til produktion adskillige spurter bagud.
- Kommunikationen mellem de forskellige scrum-hold er kaotisk og ineffektiv, da hvert hold har hver sprint en masse aktiviteter, der skal udføres. Faktisk har produktejere en tendens til at tildele teamet for meget indhold hver sprint. Der er ingen chance for, at holdet kan gennemføre det hele, så de er konstant under deadline stress.
Ret fejlene
Efter at have erfaring fra et par agile transformationsprojekter, vil jeg gerne opsummere nogle af de største fejl, jeg har oplevet, og give nogle subjektive meninger om eventuelt at overvinde dem.
#1. Det rigtige ansvar for de rigtige roller
Hvis du forsøger at bøje definitionen og fordele ansvaret på en anden måde, end de burde være af scrum/agile, sætter du hele initiativet til fiasko.
- Produktejere skal eje indholdet og vedligeholde efterslæbet. De er ansvarlige for backlog-historierne, og hvis backlog-historierne ikke er veldefinerede, er det op til dem at tage affære og rette op på det. På den anden side bør de ikke have nogen indflydelse på scrum team people opgaver eller beslutninger om projektets budget.
- Scrum-mestre har intet ansvar med hensyn til backlog-indholdet. De er med på holdet for at orkestrere ceremonierne og uddanne holdet i en agil måde at arbejde på. De burde ikke være sekretær for produktejere. Tværtimod skal de beskytte udviklingsteamet mod produktejeren og eksterne interessenter.
- Hvert scrum-hold skal have tildelt en leveringsføring. Denne person vil forbinde PO, SM og udviklingsteamet til et brugbart setup, definere leveringsprocesser og løse eventuelle potentielle risici, problemer eller konflikter, som teamet måtte have. Leverancelederen er den rette person til at tage stilling til projektets bemandings- og budgetspørgsmål. Denne person skal stræbe efter at opbygge et miljø for holdet, hvor alle kan yde deres bedste.
- Udviklingsteamets ansvar er at udvikle historierne fra backlog. De kan hjælpe PO med at bygge indhold til nogle historier (hovedsageligt dem, der er for tekniske), men de er ikke ansvarlige eller ikke engang ansvarlige for historier, der bygger skabelsen af køreplanens indhold.
#2. Stabilt hold
At investere i teamets agile uddannelse er vigtigt og skal være en hurtig proces. At lade denne viden forsvinde med få måneders mellemrum er bare spild af tid for alle.
De første fem spurter kan du bruge som læringskurve for holdet til at lære og øve de grundlæggende scrum-aktiviteter. Når disse er klare for hele teamet, kan den kontinuerlige forbedringsproces for scrum-teamet starte. Men hvis personerne i teamet ændrer sig regelmæssigt, vil du finde dig selv i en konstant løkke af videnoverførsel og uddannelse.
Sådan et team vil sandsynligvis aldrig nå det fulde præstationspotentiale, og ledergruppen vil fortsat undre sig over, hvorfor det tidligere (før den agile transformation) var mere effektivt, end det ser ud til nu.
Så opbyg teamet, invester viden, og når først teamet har tillid til de nye processer, skal du bare beholde det som det er og udvikle dig videre. Herfra skal den konstante vej mod perfektion starte.
#3. RACI Matrix
Det er en god praksis at opbygge og blive enige om RACI-matricen (Ansvarlig, Ansvarlig, Rådgivet, Informeret) mellem alle teams lige før det rigtige arbejde starter. Dette kan potentielt fjerne en masse forvirring lige i begyndelsen.
Det er ret vigtigt, især i de tidlige stadier af transformationsinitiativerne. Ellers vil folk begynde at rejse spørgsmål om, hvem der skal gøre hvad i hvilken situation, især i dem, der ikke eksplicit blev adresseret via teamets kommunikation.
Her er et eksempel på sådan en RACI-matrix for nogle af ansvarsområderne. Dit projekt kan have et andet sæt. Det er vigtigt at fange de relevante.
OpgaveAnmoderLevering Lead ProduktejerScrum MasterDev TeamSprint PlanlægningssessionerC/ICA/IRC/IDeliver Release IncrementN/AIA/IC/IRSprint ReviewC/IIRICSprint RetrospectiveIIA/IRC/IRDefiner BacklogIA/IRAC/I
Konklusion
Der kunne stadig være meget at skrive om, da der er mange måder og mange steder, hvor den agile transformation kan føre af sporet. Formålet var at pege på nogle af de problemer, jeg anser for at blive gentaget ofte.
Selve initiativet er en god idé. Det kan dog hurtigt blive et mareridt for alle deltagerne, hvis man overholder nogle grundregler. Jeg fremhævede et par af dem, men brug bare din sunde fornuft, så skal du nok klare dig. 🙂
Tjek derefter gode læringsressourcer til Agile-certificering.
