Autonomt team betyr ikke “fri til å velge all slags teknologi”
Hva skal egentlig autonome team være autonome på? En av de uheldige utslagene jeg har sett i flere organisasjoner er at man tolker autonomi som retten til å velge å bruke den teknologien man selv tenker er best — eller kulest. For eksempel at en utvikler i ett team vil bruke Kotlin, mens i et annet team i samme organisasjon bruker de Go.
Det er misforstått autonomi, og gir mange problemer for en organisasjon. Med frihet til å velge teknologi blir det over tid mange forskjellige teknologier å kunne, og du kan aldri være garantert at den personen som kan akkurat den teknologien er tilgjengelig når det trengs. Kanskje har hen til og med sluttet — eller pensjonert seg. Organisasjoner som utvikler egne løsninger må derfor ha en viss standardisering av hvilke teknologier som brukes.
Grunnen til at det oppleves viktig for programmerere å velge teknologi selv tror jeg er fordi det er det eneste de får lov til å velge. Det sitter noen andre og bestemmer hvordan man skal jobbe og hva man skal jobbe med. Og der ligger kjernen i hva et autonomt team skal være:
Et autonomt team som driver med produktutvikling skal være autonome på hva de skal lage.
Fordi: det krever så hyppig utforsking å finne ut hva som vil være nyttig for de brukerne man ønsker seg. I min PhD kalte jeg det at output er dynamisk.
Når output er dynamisk må man finne noe annet å legge til rette for enighet mellom det enkelte team og resten av organissjonen på. Dette kalles ofte for outcome — på norsk “adferdsendring”. Det vil si: hva er det som skal være annerledes når vi har gjort dette. For eksempel kunne Fiskeridirektoratet, da de skulle få laget et saksbehandlingssystem, skrevet noe slikt som: “Vi ønsker å gjøre det lettere å oppdage hvem som gjør ulovligheter innenfor fiskeri og havbruk”.
Et autonomt team skal altså ikke lage hva som helst — men få en tydelig forståelse av organisasjonen vil og hva slags adferdsendring som skal til for å få til det. Deretter jobber de sammen med de som trengs for å lage noe som oppfyller det målet man har.
Fortsatt er det for mange ledere som ser på programmerere som de som “bare” skal bygge det noen andre har bestemt. Det gjør at man får alt for lite utforsking av om det som lages er lurt å lage, og dermed mange penger brukt på unyttig funksjonalitet og unyttige tjenester. Og, altså, uhensiktsmessige sideeffekter som at organisasjonen får mange forskjellige teknologier å forholde seg til.
Og ja, da, jeg vet at mange programmerere synes at det er stas å lære seg nye teknologier, og læringsiver skal man ta vare på. Likevel, som organisasjon må man ha et fornuftig forvaltningsregime med en viss standardisering på teknologi, slik at folk kan bevege seg mellom team uten at læringsterskelen blir alt for høy.
