Det første trinnet er ganske åpenbart – Create a sense of urgency . Hvis utgangspunktet ikke er en reell krise, blir det opp til ledelsen å skape en klar, felles forståelse om at hvis vi skal oppnå våre (gjerne ambisiøse) forretningsmessige mål i framtiden må vi optimalisere organisasjonen pådenne måten. Slik vi er strukturert i dag vil ikke fungere godt nok på grunnav yxz.
Neste trinn er Build a guiding coalition. Her gjelder det å inspirere ledertyper rundt om i organisasjonen til å være ambassadører for endringen. En mest mulig tverrfaglig koalisjon fra ulike deler av systemet. Folk som blir hørt og som vil ivre for endringen. Viktig at dette er mennesker som melder seg til tjeneste fordi de ønsker å være med, og ikke bare er utpekt fra ledelsen. Også viktig at det følger med insentiver, slik at man sikrer at denne koalisjonen setter av nok tid til dette arbeidet (for det er arbeid!).
Så kommer Form a strategic Vision . Hvordan kan den fremtidige, ønskede situasjonen beskrives slik at vi får nok momentum i riktig retning. En god visjon er klargjørende, samlende og inspirerende. Men det er fremdeles en visjon og ikke en plan, så en slik visjon bør ikke gå for mye i detalj.
OK, så langt mange fine ord, men hvordan angriper vi dette rent praktisk? En vesentlig jobb, som ofte er undervurdert, er å få en god situasjonsforståelse. Vi må forsøke å se oss selv i speilet – hvordan fungerer vi egentlig akkurat nå? Hva er det som er mest uheldig med dagens praksis i forhold til målet? Hva slags kapabiliteter vil vi måtte tilegne oss for å jobbe effektivt mot visjonen?
Dagens situasjon
Det kan være overraskende mange ulike oppfatninger om dagens situasjon i en organisasjon, og det kan være vanskelig å lage en dekkende beskrivelse av de viktigste aspektene. Et annet problem kan være at det har spredd seg en gjengs oppfatning som ikke nødvendigvis er riktig (gruppetenkning).
Her kan man få uvurdelig hjelp av utenforstående konsulenter/coacher som gjør en kartlegging. Fordelene med å komme utenfra er flere: Man har ingen historikk og vil kunne stille “dumme”, åpne spørsmål uten å mistenkes for å ha en agenda. Og de som har vært rundt og sett mange ulike organisasjoner vil lettere kunne sette fingeren på hva som faktisk skjer av betydning. Det er i utgangspunktet “uendelig” med parametere man kan forsøke å kartlegge, men bare noen få som er av stor betydning for visjonen.
Det er litt for vanlig å hoppe bukk over dette. Det kan være tidkrevende og potensielt ubehagelig å få skriften tydelig på veggen i en slik situasjonsbeskrivelse. Så mange tar snarveien og forsøker seg med rammeverk uten mål og mening. Strategien er kortfattet og sier ikke så mye mer enn “innfør rammeverk x”. Jeg har jobbet mest med Scrum og opplever at mange trekker på skuldrene og sier “vi trenger å bli smidigere, la oss gå for Scrum”. Sender så noen på kurs, oppretter Scrum Master og Product Owner rollene, krysser fingrene og håper det skal bli bedre. Det er litt naivt…
Det samme kan selvsagt skje med Product Operating Model, Team Topologies, “Spotifymodellen”, SAFe, Prince2 Agile, OKR osv osv.
Hvordan konkretisere dagens situasjon
En typisk situasjon i Norge i dag er at man har innført Scrum eller produktteam, har en formening om at det ikke funker så godt og ønsker hjelp til å sette fingeren på hva det er. Som ekstern konsulent kan jeg da ganske enkelt kartlegge en (del av) organisasjonen ved å gjøre korte, strukturerte intervjuer av nøkkelpersoner i ulike roller og team. Jeg vil typisk finne ut slikt som graden av samarbeid i teamene (kommunikasjon, trygghet, overlapp i kompetanse etc), graden av samarbeid mellom utviklere og produktleder, graden av innsikt i kundenes behov, evnen til å prioritere bort ting, evnen til å få utbytte av retrospectiver, ende-til-ende flyt (blokkeringer, avhengigheter, WIP etc), kvalitet (bugs, support, teknisk gjeld) etc..
Det er som sagt nærmest uendelig med parametere som kan beskrive en organisasjon, så for å få mest mulig utbytte av en kartlegging lønner det seg å være målrettet og spørre: Hvilke kapabiliteter er det som er mest relevant/avgjørende for visjonen? På den måten kan en kartlegging bli langt mer treffsikker.
Det finnes mange rammeverk og assessment metoder for å analysere organisasjoner. Marty Cagan har sin Product Organisation Assessment, vi har Flow-Oriented Operating Model Assessment som er knyttet til Team Topologies og ikke minst har vi Org Topologies som er en kraftfull måte å diskutere gapet mellom hvor organisasjonen er og hvor den trenger å være. Personlig er jeg mest inspirert av den siste, samt forskning på prosessforbedring gjennom de siste 30 årene.
Her er en pragmatisk og relevant sjekkliste for å fokusere innsatsen på det som vil være mest avgjørende. Er det:
- 1 Kundeverdi – vår evne til å levere det som virkelig gir kundene verdi?
- 2 Fart og flyt – hvor raskt klarer vi å levere verdi til kundene?
- 3 Læring – i hvor stor grad er vi i stand til å reflektere og lære slik at vi stadig blir bedre?
- 4 Samstemthet – drar er alle deler av organisasjonen i samme retning?
- 5 Tilpasningsdyktighet – hvor enkelt er det å endre strategiske prioriteringer?
- 6 Ansattes engasjement – hvor fremoverlente og motiverte er de ansatte?
- 7 Forutsigbarhet – hvor gode er vi til å levere på det vi lover?
- 8 Effektivitet – hvor effektivt klarer vi å bruke ressursene våre?
- 9 Ekspertise – har vi dyp og solid kunnskap nok kunnskap på kjerneområder?
- 10 Innovasjonsevne – hvor gode er vi til å eksperimentere og lære av feil?
- 11 Driftsikkerhet – vår evne til å operere trygt og sikkert?
- 12 Kvalitet – at vi har en håndtverksmessig høy standard på produktene?
Eksempler
Her kommer noen eksempler der utgangspunktet er veletablerte Scrum- eller produktteam:
En kunde var veldig klar på at de ansatte engasjement var det største problemet (for mange nøkkelpersoner hadde sluttet det siste halvåret). Intervjuer av utvalgte nøkkelpersoner viste at lønn og betingelser var bra, arbeidsmiljøet helt ok, og at hovedgrunnen til at ansatte hadde sluttet lå i to ting: 1. Veldig mye teknisk gjeld (“dårlig kode”) og 2. konstant overbelastning. I neste omgang ble det klart at disse to tingene var relatert. Aldri tid til å lage gode tester, å refaktorisere eller å kjøre code review. Alt for mye tid går med til å rette feil og rydde i koden – man føler seg lite produktiv. Selgerne var rett og slett “for gode” og solgte systematisk mer enn de klarte å levere. Vi kom til at dette var en rotårsak og at det var liten vits i å adressere andre ting enn dette i starten. Rådet om å “be selgerne om å selge mindre” falt imidlertid ikke i god jord i styret. Rett og slett for radikalt.
En kunde rangerte Fart og flyt høyest. De var tilsynelatende godt rigget med flere verdistrømteam og plattformteam samt komponent-team. Det tok ikke lang tid å avdekke at hverdagen var preget av multitasking, høy WIP, mye venting og hyppige, uklare omprioriteringer. De hadde mange designere som gjorde grundig og verdifullt innsiktsarbeid – som organisasjonen ikke helt klarte å kapitalisere på. Product Discovery er lite verdt uten velfungerende Product Delivery. Dette gjorde at vi satte i gang internt innsiktsarbeid for å finne flaskehalser og blokkeringer. Hvert verdistrømteam loggførte blokkeringer og omprioriteringer i en periode og vi fikk veldig interessante tall å jobbe med. De som var coacher og teamledere gikk sammen og brukte innsikten til å foreslå justeringer av teamene. Lang historie kort: Det viste seg at teamene var for “smale” slik at ingen av teamene var rigget for å fullføre noe som helst selv. Det var flaskehalser overalt. Det ble klart at både enkeltpersoner og de ulike verdistrømteamene trengte mer bredde (altså “T-profil”). Dessuten gikk de for større grad av delt kode-eierskap. På denne måten ble det både raskere flyt og en mindre stressende arbeidshverdag der de opplevde å kunne jobbe med fokus over lengre tidsrom.
En kunde oppgav at de hadde synkende omsetning og hadde en visjon om å bevege seg raskt inn i et nytt marked med en delvis endret forretningsmodell. De hadde kjørt en Design Sprint og mente de hadde et ganske solid verdiforslag, men de visste alt for lite om den nye brukergruppa. Dessuten var de veldig usikre på hvordan de skulle rigge organisasjonen for det nye. I dette tilfellet var det begrenset nytteverdi i å samle data om status quo. I stedet rettet vi blikket fremover og fant at det i første omgang var tre ting å adressere: 1. Etablere langt bedre ferdigheter og muligheter innen innsiktsarbeid. Her valgte vi å satse på User Story Mapping og intervjuer basert på Job-to-be-done. 2. Gjøre det lettere å få direkte feedback fra brukere til utviklerne, og ikke indirekte via en produkt/design-avdeling. Tiltaket var å etablere sterke, tverrfaglige team som selv hadde tilstrekkelig kompetanse på interaksjonsdesign og produktforståelse. 3. Bedre analyseverktøy og dashboard for å få rask og direkte feedback fra produksjon.
Disse tre eksemplene er bare et ganske tilfeldig utvalg. Organisasjoner er – ikke overraskende – så forskjellige at det ikke finnes noen ferdig mal. Ingen “beste praksis”. Løsningen er kort fortalt å forsøke så langt det er mulig å forstå hvor man er og hvor man vil, for så å sette i verk tiltak på det som antas å ha størst effekt. Det neste blir jo da å sørge for å jobbe i korte iterasjoner og å lære av erfaring. Kjør helhjertede retrospectiver. Det som til syvende og sist fører til varig forbedring er alltid et resultat av kontinuerlig forbedring. Men dette får bli en annen artikkel.