En smidig organisasjon, ende-til-ende

Smidig (agile) blir fremdeles nå i 2020 adressert som et “IT-problem” som skal løses gjennom å innføre et eller annet agilt rammeverk i IT-avdelingen. Resten av organisasjonen gjør som regel visse endringer, men fortsetter stort sett som før. Selv om de har forretningsmessige ambisjoner om å bli raskere, mer fleksible eller mer pålitelige, ser vi sjelden helhjertet innsats for å transformere forretningssiden eller ledelsen. 

Agile var i utgangspunktet en bevegelse som i 2001 formulerte et manifest for å hjelpe IT-verdenen ut av et ganske dysfunksjonelt, ineffektivt styringssett. Fokuset for de 17 opphavsmennene var programvareutvikling, som på den tiden begynte å bli virkelig forretningskritisk for de fleste organisasjoner i de fleste bransjer. Nå, i 2020, kan vi bytte ut “de fleste” med “alle”.

Det er kanskje ikke så merkelig at dette manifestet blir tolket som “et IT-problem” som har sin løsning i IT-avdelingen. Problemet med denne tankegangen er at ingen IT-avdeling er frakoblet alle andre avdelinger i en organisasjon. Det settes i gang agile transformasjoner over en lav sko for tiden, men med alt for snevert fokus. Jeg har mange ganger de siste 15 årene vært vitne til all forvirringen, friksjonen og frustrasjonen som oppstår når man forsøker å styre IT med et helt annet tankesett enn det som gjelder ellers. Om ledelsen, salg, HR, forvaltning, finans etc fortsetter å tenke og operere tradisjonelt, kommer man ikke langt. Innføringen av agile blir en skuffelse og ofte reelt sett en forverring, snarere enn forbedring.

Virkelig smidige organisasjoner adresserer endringen i full bredde; Det går “ende-til-ende”, tvers igjennom alle verdikjeder – det berører alle nivåer og alle funksjoner. Først da vil man klare å ta ut det fulle potensialet som ligger og venter. Etter min mening er det nødvendig å angripe organisasjonsdesign med systemtenkning , der man anerkjenner at alt henger sammen med alt. Ting er dynamisk, altså ikke ikke lineært, dette i skarp kontrast til det tradisjonelle synet der man fremstiller organisasjonen som ulike bokser i et kart og tverrgående, definerte prosesser. Vi kan bare glemme å optimalisere enkelte enheter separat. Det vi trenger i dag er akkurat det Peter M. Senge beskrev i den etter hvert legendariske boka The Fifth Discipline, the Art & Practice of The Learning Organization i 1990. Vi er i stadig økende grad henvist til å bygge organisasjoner som er kontinuerlig lærende og som evner å gjenskape seg selv når det er nødvendig. Agile organisasjoner eksperimenterer, lærer og tilpasser seg omgivelsenes dynamikk.

Valg av riktige metoder og rammeverk er viktig, men slett ikke det eneste som betyr noe. Dette er kun én av de 8 bitene i det komplette puslespillet som må legges. De 8 områdene er

Hver og en av disse må basere seg på det samme, smidige tankesettet.

Alle brikkene må være på plass. Ta vekk en og du vil oppleve friksjon, hindringer og frustrasjon.

Spørmålet er: Hvordan kan vi gjennom et smidig tankesett skape en organisasjon som er optimalisert for flyt og kundetilfredshet og som endrer seg raskt når det er nødvendig? Hva krever dette av ledelse, struktur, folk, finans, rammeverk, kvalitet og kultur?

Lederskap

Forutsetning: kompleksitet, dynamikk og usikkerhet gjør det nødvendig å fatte raske beslutninger med begrenset informasjon tilgjengelig

Måten organisasjonen styres og ledes på vil selvsagt ha et stor innflytelse på hvordan en smidig transformasjon vil arte seg. Moderne ledere forstår at det ikke bare er å fortelle/forklare hva som nå forventes – de må selv modellere endringen gjennom egne handlinger. De går foran med et godt eksempel.

Lederskap dreier seg om å stake ut kursen og å formidle denne på en slik måte at alle involverte gjerne vil være med. Formulere langsiktige visjoner, og legge strategier som innbefatter å lære underveis. Think big, start small, move fast er et godt mantra.

Man kan også si at ledelse dreier seg om å prioritere, det mangler aldri på ønsker om behov. Spørsmålet er “hva skal velges bort?” På mange måter handler ledelse om å bestemme hva man ikke skal gjøre, slik at det som er i fokus får mest mulig oppmerksomhet.

En smidig leder forstår at de ansatte må få eie sine egne prosesser, beslutninger og løsninger. Dette fordrer en lederstil som minner om coaching. Interessant nok var det akkurat dette som ble ranket som nummer 1 i en intern undersøkelse i Google (Ranked number 1 a great leader “Is a good coach”.)

Smidige ledere er ydmyke og aksepterer at det er umulig å ha alle svarene på forhånd. Man må våge å ta sjanser og tåle å mislykkes. Hvis man aldri feiler går det for sakte, og det blir ikke innovasjon.

Struktur

Forutsetning: Vi må optimalisere systemet for rask arbeidsflyt med få hindringer og høy grad av samarbeid

Hierarkiske nivåer og funksjonelle “siloer” hindrer rask flyt. Tradisjonelle organisasjoner domineres av overleveringer av arbeid og beslutninger mellom ulike funksjoner og mellom ulike eskaleringsnivåer, noe som i sin tur forhindrer god flyt og rask eksekvering. En smidig struktur gir stor grad av myndighet til sterke, tverrfaglige, ansvarlige team som jobber så direkte som mulig med kundene.

Konsekvensen av dette er et synkende behov for mellomledere. Disse teamene, støttet av produkteiere med myndighet til å prioritere, samt Scrum Mastere eller agile coacher kan operere ganske autonomt. Kravet er selvsagt at de stadig beveger seg i retning av de overordnede målene staket ut av ledelsen.

I smidige organisasjoner blir roller noe mindre viktig, mens det tverrfaglige, tette samarbeidet og den kollektive ansvarsfølelsen løftes opp. Det blir tydelig at det hele er et lagspill der man hjelper til der det er nødvendig, selv om det som trengs er litt utenfor kjernekompetansen. Her vil det være vesentlig at målstyrings- og belønningssystemer verdsetter kunnskapsdeling og samarbeid framfor individuelle prestasjoner.

Mennesker

Forutsetning: Folkene som gjør jobben er den viktigste suksessfaktoren, og de gode, raske beslutningene tas tett på virkeligheten av de som utfører.

Smidige organisasjoner er avhengige av å ansette og utvikle team-orienterte folk som liker å lykkes sammen med andre og gjerne tar et kollektivt ansvar. Noen mennesker elsker samarbeid med andre og følelsen av å lykkes i et fellesskap, mer enn å bare fylle en rolle. Viktig å sette sammen team med folk med en slik instilling. Allikevel er det helt nødvendig å ta gruppedynamikk og den mellommenneskelige faktoren på største alvor. Det er naivt å tro at alle team vil bli høypresterende helt av seg selv. De vil trenge gode coacher (som for eksempel en Scrum Master bør være) som klarer å hjelpe teamene gjennom gruppedannelsen, skape en kollektiv teamfølelse, finne gode måter for konflikthåndtering osv.

Smidige medarbeidere motiveres av å være i stadig utvikling (se Carol Dweck – growth mindset). De er ikke redde for å forsøke seg på nye ting og blir gjerne med på eksperimenter med usikkert utfall så lenge de lærer av det. Denne adferden fordrer en stor grad av psykologisk trygghet (i følge Amy Edmondson er dette en forutsetning for læring), der alt er transparent og ingen forsøker å skjule at de tok feil.

Som Senge skriver om i 5th dicipline er Personal Mastery en avgjørende byggesten i lærende organisasjoner. Sterke, høypresterende team med tilgang til gode agile coacher kan gjerne gis full tillit når det gjelder å bruke tid og penger på selvutvikling.

Kundeforståelse

Forutsetning: Det er kundenes tilfredshet som til syvende og sist vil avgjøre om vi lykkes eller ikke

Den brutale dommen om hvorvidt produktet eller tjenesten lykkes i markedet får vi fra sluttbrukerne. Hvis de får sine problemer løst på en så god måte at de blir begeistret, kommer vi til å gå med overskudd. Ambisiøse, smidige organisasjoner er besatt av disse menneskene. Vi bør forstå kundene bedre enn de gjør selv. Når vi serverer de nye løsninger bør vi alltid spørre oss: Hva er jobben dette produktet skal gjøre for disse personene som er bedre enn det de allerede har. Anbefaler alle å finne inspirasjon fra Clayton M. Christensen sitt Job-to-be-done konsept.

Kundene er sjelden i stand til å forklare akkurat hva de trenger slik at vi bare kan sette i gang og lage det. Vi må sette i gang å lage det basert på en rekke sterke og svake antagelser. Vi vet altså aldri hvor godt vi traff før de tar det i bruk. Da gjelder det å fange opp – i retrospekt – hvor fornøyde de ble og hva vi burde justere på slik at vi treffer enda bedre. Smidige team begynner gjerne med å lage en veldig billig, rask representasjon av produktet – gjerne en prototype – slik at vi kan få verdifull feedback fra kundene. Dette kan gjøres systematisk i sykluser, gjerne kalt “build-measure-learn” som Eric Ries definerte i sin Lean Startup bok.

Budsjettering og styring

Forutsetning: Vi kommer til å støte på hindringer vi ikke kan vite om, og vi kommer til å oppdage interessante ting av betydning mens vi gjør jobben.

Det gjelder å ha en realistisk virkelighetsforståelse og å være ydmyke nok til å innrømme at det vi trodde på i starten viste seg å ikke holde stikk. Noen ganger gjelder det å stoppe i tide og heller bruke ressurser på et helt annet problem. Andre ganger holder det kanskje å justere kursen noe. Uansett – i dagens virkelighet må vi styre mot bevegelige mål og derfor unngå å låse oss før vi er nødt. Vi må tåle å jobbe med et ganske åpent omfang som blir til underveis. Hverken tradisjonelle, årlige budsjettprosesser eller prosjektfinansiering (a´la PMI) vil fungere godt. Gå heller for Beyond Budgeting som opererer med prinsipper, verdier og tankesett som er fullt ut kompatible med agile.

Prosjekter er jo per definisjon en midlertidig, fokusert organisasjon som har et klart mål og slutt-termin. Det skal mye til at et prosjekt ikke detaljerer og låser omfanget i langt større grad enn virkeligheten egentlig tillater. Et bedre alternativ vil for de fleste være å finansiere faste, tverrfaglige team med solid domenekunnskap og som på den måten enklere jobber mot bevegelige mål med et ganske åpent omfang.

Kontraktering av leverandører og innkjøps- og anskaffelsesregler vil – særlig i offentlig sektor – gjøre det vanskelig å være smidig. Disse prosessene er ofte tunge og tidkrevende, og har som forutsetning av vi vet hva vi skal lage. Så det klare rådet til alle IT-avhengige virksomheter vil være å ansette en kritisk masse gode folk selv, og så heller leie inn flinke konsulenter ved behov.

Virkelig smidige organisasjoner er gjennomsiktige. Interessenter kan enkelt se med egne øyne hva som foregår og hva som skapes av verdi. Visjon, strategi, prioriteter, mål, Product Backlogs osv publiseres åpent. Demonstrasjon av nye produktinkrementer gjøres jevnlig og det skjer hyppige leveranser til sluttbrukerne. På denne måten vil fokus dreies fra å følge opp ift milepæler til å fokusere på faktisk skapt verdi. Hvor mange nye kunder fikk vi som resultat av denne nye funksjonen? Hva skjedde med kundetilfredsheten når vi skrev om den modulen? Fikk vi den ytelsesforbedringen vi hadde håpet på med det nye produktinkrementet?

Metoder og rammeverk

Forutsetning: Det finnes ingen ferdig, standard beste måte å jobbe på. Alle team må gjøre sine egne tilpasninger.

Ingen tvil om at dette området har fått mest oppmerksomhet når organisasjoner har forsøkt å “innføre smidig”. Det er opplagt viktig at man velger rammeverk og metodikk som legger opp til iterasjoner og kontinuerlig forbedring, men det er altså ikke nok. Alle de andre områdene må endres i takt med dette. Innfør gjerne Scrum, det desidert mest populære rammeverket. Men en “mekanisk” tilnærming til Scrum, uten at ta med et smidig tankesett og høy håndverksmessig standard bringer liten om noen forbedring.

Det valgte rammeverket må være “lett-vekt” altså ikke gå for langt i å beskrive en detaljert, standard måte å jobbe på. Målet må være å oppnå Empirisk prosesskontroll der gjeldende metoder, verktøy og teknikker stadig forbedres basert på det man erfarer. Hyppige leveranser og rask feedback må være integrert. Og rammeverket må støtte selvorganisering i tverrfaglige team som er i stand til å selv fullføre det de har startet på.

Håndverk og kvalitet

Forutsetning: Det er fullt mulig å oppnå rask arbeidsflyt uten å kutte hjørner, uten å kompromisse på kvalitet

Det er svært stor forskjell på å lage en prototype med formål å teste antagelser og å lage et produktinkrement med forventet levetid på mange år. I begge tilfeller må teamet som gjør jobben velge det riktige nivået av kvalitetssikrende aktiviteter. Vil det være nødvendig å bruke TDD (Test Driven Development) med fullt sett av automatiske tester innbakt, eller ikke? Er det egnet for parprogrammering? Skal vi kjøre formelle code reviews?

Gode, smidige team opparbeider seg kapabiliteter både når det gjelder teknisk eksellense og yrkesetikk. De har et langsiktig perspektiv og de vet godt at det å ta snarveier i dag må vi selv betale for i fremtiden. Drivkraften til denne sterke yrkesstoltheten kommer av det sterke eierskapet som følger av tilliten teamene vises av organisasjonen rundt. Det er deres problem, og om de lykkes eller ei er opp til dem selv.

Alle interessenter må være klar over at ingen er tjent med å akkumulere opp teknisk gjeld i produktet. Selv om de ofte er utålmodige og gjerne skulle hatt leveranser “i går” må de finne seg i at det tar den tiden det tar. Det eneste de kan gjøre selv er å være bevisste på å prioritere godt, slik at den begrensede kapasiteten man rår over benyttes til å skape mest mulig verdi – underforstått at man klarer å velge bort kjekt-å-ha funksjoner som brukerne godt kan klare seg uten.

Kultur og tankesett

Forutsetning: Bedriftskultur vil alltid henge sammen med struktur og et smidig tankesett må ledsages av smidige strukturer.

Med organisasjonskultur mener vi de mønstrene av meninger, verdier, normer, roller og adferd som går igjen og som skaper identitet. Kulturen dannes av historiske hendelser med tilhørende fortellinger, men påvirkes også i stor grad av de rådende strukturer, visjoner og lederstiler. Det vil være håpløst å endre firmakutur uten å samtidig adressere strukturelle faktorer. Craig Larman har vært med på å transformere en mengde store selskaper i retning av agile og har konkludert med at det er umulig å endre firmakultur uten å endre strukturer (se Larman´s laws of Organizational Behaviour). Scrum er et godt eksempel på et rammeverk som fordrer ganske radikale strukturelle endringer og som dermed kan påvirke firmakulturen i retning av agile. Avdelingsskiller, eskaleringsnivåer, belønningssystemer, målstyring osv er eksempler på strukturelle faktorer av stor betydning for innføring av et smidig tankesett.

En smidig bedriftskultur har en del klare kjennetegn:

For det første må alle være innstilt på å ta sjansen på å feile – det må oppleves som trygt å våge på noe nytt og ukjent. Denne tryggheten mangler i de fleste tradisjonelle selskaper, der mye er gjort for å unngå feil. I en slik kultur vil folk (bevisst eller ubevisst) forsøke å skjule feil. Dette er et formidabelt hinder for både nyskapning og læring.

Et annet viktig kjennetegn for en smidig kultur er å anerkjenne at vi stadig er i endring. Med jevne mellomrom ser man seg tilbake og forsøker å finne bedre måter å jobbe på.

Det vil også være helt avgjørende at laveste nivå – tverrfaglige, ansvarlige, utførende team – har myndighet til å ta selvstendige beslutninger – forutsett av man jobbe i riktig, omforent retning og at det er transparent.

I smidige organisasjoner legger de vekt på å ha et growth mindset og de vil bevisst forsøke å ansette medarbeidere med en sterk drift mot å utvikle seg og forsøke nye ting.

Det vil være stort fokus på samarbeid. Ingen sitter alene med et problem – man sitter i stedet rundt det samme (fysiske eller virtuelle) bordet og løser problemer i tverrfaglighet. Derfor er det avgjørende med en kultur for samhandling og deling av kunnskap og informasjon. Belønningssystemer som i stor grad måler prestasjoner individuelt kan være en formidabel “show-stopper” her.

Konklusjon

Du kan ikke kjøpe agile. Du kan kjøpe Scrum kurs og du kan engasjere konsulenter og coacher, men dette vil ikke ta deg langt alene. Hele organisasjonen – med ledelsen i spissen – må ta eierskap til og ansvaret for omstillingen. Det finnes ingen fiks ferdig modell å rulle ut (vel, det er mange som selger slikt og det kan være en besnærende tanke selv om det er dyrt) men det vil ikke fungere. Et smidig tankesett får man gjennom å innse at løsningene må vi finne sammen og at det er de som gjør jobben som også må få selv-organisere rundt felles mål og visjoner. Ledelsen må gå foran og være smidige rollemodeller.

Leave a Reply