Når selskapene beveger seg med programvareløsninger fra on-premise til skyen, satte de seg ofte som mål å bli mer «smidig». Dette bør ofte gjelde for alt på tvers av selskapsnivå. Og selvfølgelig overalt på samme tid.
Transformasjon av prosessene kan være lett mulig, i det minste i teorien. Du kan definere scrum-seremonier og overføre folk til nye roller (som scrum-mestere, produkteiere, leveringssjefer og scrum-team).
Du kan ta med verktøy som Jira, Azure ADO og Miro-tavler og gjøre dem obligatoriske å bruke. Men hva med prosessene som kobler verktøyene sammen? Hva med å transformere folks sinn, atferd og måter å jobbe på? Det blir klart at de ikke vil forvandle seg jevnt, og de vil heller ikke bli ferdige raskt. La oss nå se hvorfor.
Innholdsfortegnelse
Hva er et leveringstransformasjonsinitiativ og hvorfor bedrifter gjør det?
En stor del av bedriftene i dag jobber fortsatt i henhold til fosseleveringsmodellen. Det betyr at:
Hele denne prosessen kan ta noen måneder til noen år, og som du kan se, vil brukere se resultatene først på slutten av prosessen. Så etter lang venting kommer sannhetens (eller fiaskoen) øyeblikk.
Hvis noe endres i løpet av den lange tiden og sluttproduktet skal se litt annerledes ut, er det en situasjon som kalles en endringsforespørsel. Designet må gjenåpnes, omarbeides og godkjennes på nytt. Det forlenger hele tidsplanen med en annen del.
Det er klart at dette ikke er smidig på noen måte. Hver endring krever en omstart av hele prosessen før.
Bytter til Agile
Så hvordan kommer vi ut av denne situasjonen og endrer den til å bli smidig? Folket jobber i fosseoppsettet i mange år eller til og med århundrer. De har roller og ansvar de er komfortable med, og de ønsker ikke å endre status quo. Hovedårsaken til det er at å gjøre denne endringen til syvende og sist betyr å miste noe av kraften de hadde frem til nå.
Dette er hovedgrunnen til at en slik endring trekker ut det sterkeste nivået av motstand fra menneskene du kan skape.
#1. Omstrukturering av team
Det første og relativt enkleste å gjøre er å omstrukturere folket til scrum-team. Del dem basert på funksjonsområdene eller en annen logisk splittelse som gir mening.
Klyvingen går som regel greit; problemet starter når du innser at folk fortsatt er bundet til de opprinnelige strukturene. Selv om de allerede er en del av de nye scrum-teamene, er de det praktisk talt ikke. De jobber fortsatt med det gamle oppsettet fordi de fortsatt har ansvar som ikke ble avsluttet sammen med teamrestruktureringsprosessen (fordi hvorfor det skulle være det – ledelse bryr seg ikke så mye om hva som må fullføres, men mest om hva som må startes).
Så, praktisk talt, ender du opp med et scrum-team som ikke er fullt dedikert scrum-team. Det er en gruppe mennesker som nå rett og slett har mer arbeid å gjøre. Det er ikke så mye tid til arbeidet i scrum-teamet som ledelsen forventer.
Samtidig er forventningen at folket skal fullføre sine opprinnelige aktiviteter samt denne nye forventningen innad i scrum-teamene. Det er et oppsett som er fast bestemt på å mislykkes helt i begynnelsen.
#2. Planlegging av Scrum-seremonier
Å beordre lagene til å planlegge flere vanlige samtaler (sprintseremonier) er enkelt å definere og starte. I det minste, forutsatt at scrum-teamene dine ikke består av folk fra 3+ tidssoner (noe som ofte er tilfelle).
Problemet starter når folket ikke vil delta i seremoniene med jevne mellomrom. Avhengig av hvem som mangler og hvor ofte, kan dette utvikle seg til ulike typer problemer. For eksempel:
- Hvis produkteiere ikke deltar på planleggings- og foredlingsseremoniene, har teamet ingen nye historier å jobbe med. Eller beskrivelsen av historiene er så dårlig at resten av teamet ikke kan begynne å jobbe med dem.
- Hvis scrum-mestere mangler på samtalene, mangler teamet grunnleggende scrum-orkestrering og kan gå seg vill over tid.
- Hvis teammedlemmene i utviklingsteamet ofte mangler, kan de ikke synkronisere med hverandre, og kommunikasjonen innad i teamet er mye vanskeligere. Det kreves også flere møter for å ta igjen, noe som tar ut enda en gang fra teamet.
Til syvende og sist er det ikke nødvendigvis folks feil at de går glipp av seremoniene. Det er bare oppsettet som ikke vil tillate dem å være på samtalene (se ovenfor om parallelle tidligere oppdrag).
#3. Lagets stabilitet
Du har kanskje et scrum-team med struktur og seremonier, men hvis det teamet ikke er stabilt over lengre tid – la oss si minst et halvt år ideelt sett vil et år med stabilitet være mitt personlige minimumskrav – så kan et slikt team ikke virkelig utvikle seg og forbedre.
Deretter vil du sannsynligvis aldri nå et helt uavhengig scrum-team som håndterer spurtene som business as usual. Til slutt må du hele tiden utdanne og lære folk i teamet for å forstå scrum-tankegangen og prosessene. Det er et slitsomt problem å ha.
Dette er et svært undervurdert problem, spesielt av ledelsen eller ledelsen i selskapet. Å kalle teamene med mennesker bare «ressurser» og planlegge «utnyttelsen» deres fra kvartal til kvartal er en umiddelbar vei til helvete.
#4. Nye roller for de samme menneskene
En annen hindring å overvinne er å omdisponere eksisterende mennesker til forskjellige nye roller. De som tidligere ledet team med ultimat makt, kan nå bli produkteiere, for eksempel. Dette er en sterk posisjon i et scrum-team, men det kan sees på som en svakere rolle i forhold til eksisterende oppsett.
Plutselig må produkteierne synkronisere med scrum master eller programledere. De er fortsatt ansvarlige for innholdet, men ikke så mye for leveringsprosessene. Denne situasjonen krever at de gir opp noen av ansvaret som folket tidligere hadde og derfor er vanskelig å svelge.
#5. Måter å arbeide på
Denne er interessant, og jeg hører den nå og da ganske ofte – vi må lære nye måter å jobbe på for å bli relevante i det utviklende markedet hvor smidighet er den grunnleggende forventningen. Men hva betyr det egentlig de måtene å jobbe på?
Spør du meg er det klart hva ledelsen mener med det – å oppnå (mye) mer på kortere tid. Etter å ha satt opp scrum-teamene, er forventningen at hvert teammedlem plutselig vil oppnå noen dokumenterte inkrementelle resultater fra dag til dag. Hvis det ikke er tilfelle, vil ledelsen begynne å spørre hvorfor den smidige prosessen ikke fungerer bra.
Rett fra ingensteds forventer ledelsen at hver time skal telle og at scrum-teamene i utgangspunktet ikke har noen ledig tid, bare fordi det uten tvil ikke er plass til det, vil alle scrum-prosessene være på plass. Og det er definisjonen av «nye måter å jobbe på» fra lederperspektivet i et nøtteskall.
Selvfølgelig er denne forventningen ikke bygget på reality-sjekken. Det er illusjonelt å forvente at folk i bedriften begynner å jobbe mer innen samme periode, bare fordi noen daglige prosesser vil endre seg. Jeg mener, noen av dem kunne, selv om det bare var en minoritet. Men selv denne gruppen reduseres ytterligere ved å fylle dem med flere oppgaver samtidig.
Forskjellen mellom mål og virkelighet
Det er ingen tvil om at beskrivelsen av sluttmålet ofte er god, og det gir mye mening. Den går rundt følgende prinsipper:
- Stabiliserte scrum-team jobber med uavhengige backlogs med klare KPIer og OKRer.
- Produkteiere for å bygge opp solide veikart og planlegge prioritert innhold for å levere mot konkrete tidslinjer.
- Definert backlog-innhold med relevante funksjoner allerede detaljert før arbeidet startet.
- Pålitelige testprosesser utført sammen med det vanlige sprintutviklingsarbeidet.
- Regelmessige utgivelser til produksjon – minst en gang i måneden, men ideelt etter hver fullføring av sprint.
- Risikoer og problemer sporing og kommunikasjon mellom de forskjellige scrum-teamene i tilfelle avhengigheter.
Så, når det kommer til virkeligheten, kan jeg fortelle at ingen av punktene ovenfor er enkle å oppnå.
- Du danner scrum-teamene, men de er i stadig endring (fra kvartal til kvartal). Du investerer tid for å lære teamet scrum-prosessene, og når de endelig begynner å akseptere det og endre måten å jobbe på, omorganiserer du teamene for neste periode. Veikart er endret, forskjøvet eller kansellert.
- Produkteiere har ingen reell anelse om veikartdetaljene, og (bare fordi de hadde slike vaner før) vil de tildele oppgavene sine med å bygge opp backlog-innholdet direkte til teamet. Som et resultat har ikke teamet tid til å utvikle innholdet, da de først må finne ut hva de skal utvikle.
- Testprosesser er kun manuelle og krever mange deltrinn og godkjenninger og kompliserte prosesser å følge. Det betyr at testingen ikke kan fullføres innenfor samme sprint som utviklingen gjør.
- Som en konsekvens ligger utgivelsen til produksjon flere spurter bak.
- Kommunikasjon mellom de forskjellige scrum-teamene er kaotisk og ineffektiv, ettersom hvert lag har hver sprint mange aktiviteter å gjennomføre. Faktisk har produkteiere en tendens til å tildele teamet for mye innhold hver sprint. Det er ingen sjanse for at teamet kan fullføre alt, så de er konstant under deadline stress.
Retting av feilene
Etter å ha erfaring fra noen få smidige transformasjonsprosjekter, vil jeg gjerne oppsummere noen av de største feilene jeg har opplevd og gi noen subjektive meninger om mulig å overvinne dem.
#1. Rett ansvar for riktige roller
Hvis du prøver å bøye definisjonen og fordele ansvaret på en annen måte enn det burde vært av scrum/smidig, setter du hele initiativet til å mislykkes.
- Produkteiere skal eie innholdet og vedlikeholde etterslepet. De er ansvarlige for backlog-historiene, og hvis backlog-historiene ikke er godt definert, er det opp til dem å ta grep og fikse det. På den annen side skal de ikke ha noen innflytelse på scrum team people oppdrag eller beslutninger om prosjektbudsjett.
- Scrum-mestere skal ikke ha noe ansvar angående backlog-innholdet. De er med på laget for å orkestrere seremoniene og utdanne teamet i en smidig måte å jobbe på. De bør ikke være sekretær for produkteiere. Tvert imot skal de beskytte utviklingsteamet mot produkteier og eksterne interessenter.
- Hvert scrum-lag skal ha tildelt en leveringsledelse. Denne personen vil koble PO, SM og utviklingsteamet til et brukbart oppsett, definere leveringsprosesser og løse eventuelle risikoer, problemer eller konflikter teamet måtte ha. Leveranslederen er rett person til å avgjøre prosjektets bemannings- og budsjettspørsmål. Denne personen skal bestrebe seg på å bygge et miljø for laget der alle kan yte sitt beste.
- Utviklingsteamets ansvar er å utvikle historiene fra etterslepet. De kan hjelpe PO med å bygge innhold for enkelte historier (hovedsakelig de som er for tekniske), men de er ikke ansvarlige eller ikke engang ansvarlige for historier som bygger opp veikartinnhold.
#2. Stabilt lag
Å investere i teamets smidige utdanning er viktig og må være en rask prosess. Å la denne kunnskapen forsvinne med noen måneders mellomrom er bare bortkastet tid for alle.
De fem første spurtene kan du bruke som en læringskurve for laget for å bli kjent med og øve på de grunnleggende scrum-aktivitetene. Når disse er klare for hele teamet, kan den kontinuerlige forbedringsprosessen til scrum-teamet starte. Men hvis menneskene i teamet endrer seg regelmessig, vil du finne deg selv i en konstant loop av kunnskapsoverføringer og utdanning.
Et slikt team vil sannsynligvis aldri nå fullt ytelsespotensial, og ledergruppen vil fortsette å lure på hvorfor det tidligere (før den smidige transformasjonen) var mer effektivt enn det ser ut til nå.
Så bygg teamet, invester kunnskapen, og når teamet er trygg på de nye prosessene, er det bare å beholde det som det er og utvikle seg videre. Herfra skal den konstante veien mot perfeksjon starte.
#3. RACI-matrise
Det er en god praksis å bygge opp og bli enige om RACI-matrisen (ansvarlig, ansvarlig, konsultert, informert) mellom alle teamene rett før det virkelige arbeidet starter. Dette kan potensielt eliminere mye forvirring rett i begynnelsen.
Det er ganske viktig, spesielt i de tidlige stadiene av transformasjonsinitiativene. Ellers vil folk begynne å stille spørsmål om hvem som skal gjøre hva i hvilken situasjon, spesielt i de som ikke eksplisitt ble adressert via teamets kommunikasjon.
Her er et eksempel på en slik RACI-matrise for noen av ansvarsområdene. Prosjektet ditt kan ha et annet sett. Det er viktig å fange opp de aktuelle.
OppgaveRequestorLeading LeadProduct OwnerScrum MasterDev TeamSprint Planning SessionsC/ICA/IRC/IDeliver Release IncrementN/AIA/IC/IRSprint ReviewC/IIRICSprint RetrospectiveIIA/IRC/IRDefiner BacklogIA/IRAC/I
Konklusjon
Det kan fortsatt være mye å skrive om, da det er mange måter og mange steder hvor den smidige transformasjonen kan føre av sporet. Hensikten var å peke på noen av problemene jeg anser gjentas ofte.
Selve initiativet er en god idé. Det kan imidlertid fort bli et mareritt for alle deltakerne hvis du følger noen grunnleggende regler. Jeg fremhevet noen av dem, men bruk bare sunn fornuft, så går det bra. 🙂
Deretter kan du sjekke ut gode læringsressurser for Agile-sertifisering.