Martin Koksrud Bekkelund

Nylig snakket jeg på Smidig om hvor man beveger seg videre fra DevOps, hvordan man får opp farten og lager bedre IT-løsninger ved å være selvforsynt med kompetanse. Her følger både tekst og slides.

I IT-bransjen snakker alle om DevOps om dagen, fagdisiplinen hvor man bryter ned de tradisjonelle barrierene mellom dem som utvikler en løsning og dem som drifter den. Enkelt forklart er målet å forenkle og automatisere utrulling av ny kode, raskt, hyppig og på en trygg måte. Men DevOps alene gir deg ikke alt du trenger for å levere en IT-løsning ut i markedet.

Før DevOps

I et tradisjonelt organisert IT-prosjekt sitter dem som utvikler løsningen og dem som drifter den hver for seg. Ofte sitter de ikke bare i forskjellige avdelinger, ofte sitter de også i forskjellige selskaper på forskjellige steder. En slik tradisjonell organisering impliserer mer prosess og bruk av tid enn om de samme menneskene satt skulder ved skulder. Jeg har selv arbeidet i slike miljøer og det er stort sett frustrerende å se hvor mye kalendertid som går tapt, hvor mye bedre kvaliteten kunne vært i drift og hvor mye mer motiverte alle ville vært.

I et DevOps-miljø, derimot, sitter gjerne utviklere og driftere sammen. Og ofte er gjerne utviklere også driftere, og omvendt. Det skjer ingen formell overlevering mellom utvikling og drift, det skjer som en del av samarbeidet ved å sitte sammen. Sammen eier de kvaliteten i løsningen. Går noe ned eller ikke fungerer, er det ingen som skylder på noen andre. Det er i IT-bransjen i dag lite kontroversielt å utvikle og drifte løsninger på denne måten. Jeg arbeider selv i et slikt miljø i dag, og har vært med på omstillingsprosessen for å komme dit.

Fra DevOps til selvforsynt

Så til poenget: det er ingen grunn til å se på utviklere og driftere isolert. Det er ikke de eneste fagdisiplinene man må beherske for å utvikle nye løsninger og ta dem ut i markedet. Eksempler på andre roller man trenger er (interaksjons)designere, forretningsutviklere, tekstforfattere, markedsførere og selgere, for å nevne noen.

Skal man virkelig være smidig og ha evnen til raskt å levere nye løsninger i markedet bør en enhet eller en avdeling være selvforsynt (self-contained) med alle ressurser som trengs.

Alle man trenger fra en idé er unnfanget, til den er ute i produksjon, må arbeide sammen, med felles mål og felles prioriteter. Spesielt dette med felles prioriteter er viktig. Arbeider man i forskjellige enheter, har man gjerne forskjellige prioriteter. Da er det vanskelig å samarbeide om den samme tingen samtidig, og det oppstår kø og interessekonflikt.

Men når man arbeider sammen er det lett å finne tak i de ressursene man trenger for å vurdere ideer og realisere dem (eller forkaste dem) raskt. Forretningsutvikleren vurderer effekt eller lønnsomhet og tester ut ideen i markedet, designerne skisser raskt opp et forslag til hvordan det kan se ut og utviklerne kommer med teknisk løsningsforslag.

Det er ikke viktig hvilke roller du bemanner en slik enhet med, men at enheten i så stor grad som mulig besitter all kompetansen du har behov for. Du må selv vurdere hva du har behov for, og en person kan om nødvendig besitte flere roller.

Nedsiden

En slik organisering kommer selvfølgelig ikke uten en nedside. I større selskaper oppnår man sjelden stordriftsfordeler. Eksempelvis vil man ikke benytte selskapets IT-avdeling, da enheten selv er IT-avdelingen. Dette er selvfølgelig bra for enheten, men få andre drar nytte av kompetansen utenfor enheten. I slike selskaper bør man tilrettelegge for utveksling av kompetanse mellom enhetene. Da lærer man av hverandre, samtidig som enhetene beholder sin autonomi.

I større organisasjoner må man også sørge for at eventuelle rammeavtaler som inngås er fleksible nok til å dekke de varierte behov selvforsynte enheter måtte ha, enten det er innkjøp av datautstyr eller drift av IT-løsninger.

Dersom selvforsynte enheter arbeider med eksterne enheter som ikke arbeider på samme måte, er det ikke fritt for at det kan oppstå utfordringer i samarbeidet, hvis man ikke har gjensidig forståelse for hvordan begge arbeider.

En selvforsynt enhet må heller ikke bli for stor. Det er vanskelig å angi et eksakt antall mennesker, men overstiger det 30-40 personer danner det seg fort enheter i enheten. Det kan selvfølgelig være helt greit, men da må man aktivt se til at det skjer tilsiktet og ikke danner seg sprikende prioriteter, så man sikrer at alle arbeider mot samme mål.

Det er heller ikke slik at man bare kan ta noen enkle grep og få en tradisjonelt organisert enhet til å bli selvforsynt og arbeide på denne måten. Slike omstillingsprosesser krever ofte mer enn å starte fra grunnen av med en ny enhet.

Hvem passer det for

Å være selvforsynt passer ikke for alle. Det passer i miljøer hvor endringer forekommer hyppig og hvor det er viktig å ha så kort time-to-market som mulig. Man må ha et tankesett hvor endring er regelen og eksperimentering er en del av hverdagen.

Sett fra et ledelsesperspektiv kan dette ved første øyekast virke kontraintuitivt, det er derfor viktig å forankre slik organisering oppover der det er nødvendig. Dette kan for øvrig forklare hvorfor digitalisering av offentlig sektor ofte tar litt tid, men det får jeg komme tilbake til.

Disrupt or die Teknologiledelse