2000+ lyttinger
Kundeforventninger
Å praktisere DevOps
Utviklingsmetoder
CALMS
Kulturendringer
Automatisering
LEAN
Måling, deling og sikkerhet
Del denne Masterclass
Dette lærer du om i denne Masterclass
Bibliotek
Om LØRN
© 2024 LØRN AS
“
Velkommen til LØRN.Tech – en læringsdugnad om teknologi og samfunn med Silvija Seres og venner.
Silvija Seres: Hei og velkommen til LØRN fundamentals i DevOps med Marley Kristin Singarajah. Velkommen til deg også Marley.
Marley Kristin Singarajah: Tusen takk Silvija. Veldig gøy å være her.
Silvija: Veldig hyggelig å ha deg. Vi har fått veldig varme anbefalinger på deg som en av Norges beste praktikere på DevOps. Du har jobbet med store norske og store internasjonale bedrifter og har også jobbet med noen mindre bedrifter og har etter hvert et veldig anvendt, men også helhetlig syn og erfaring med DevOps. Så det håper jeg at både jeg og våre lyttere kan lære fra i denne samtalen nå.
Marley: Tusen takk. Store ord. Så håper jeg kan levere underveis også.
Silvija: Du, jeg skal bare si veldig kort hvordan denne samtalen er strukturert for de som lytter til oss for første gang. Dette er et digitalt minikurs i fire deler, hvor første leksjon dreier seg om en introduksjon til temaet. Hva er greia med DevOps? Del to dreier seg om dine favoritt eksempler for å gi folk bilder på hvordan dette funker, fordi mesteparten av våre studenter er lyttere og ikke seere. Nummer tre leksjon dreier seg om en liten verktøykasse hvor vi prøver å hjelpe folk å komme i gang. Hvor finner man noen gode sjekklister, metoder, konsepter, lesestoff for å begynne å gjøre dette selv? Og leksjon nummer fire er et mini verksted hvor du hjelper meg som en SMB leder et selskap som har teknologiplattform som sitt kjerneprodukter og å begynne å tenke mer DevOps. Høres det greit ut?
Marley: Det ser veldig bra ut, så regner jeg med at det blir en artig samtale.
Silvija: Og det gjør det. Det blir alltid litt overraskende også, og det er det som gjør det både lærerikt og morsomt. Så Marley, før vi starter med DevOps. Kan du fortelle oss kort om hvem er Marley og hvorfor bryr hun seg om DevOps?
Marley: Ja, det kan jeg gjøre. Jeg er egentlig teknologi i bunn. Utdannet fra universitetet i Agder. Og startet karrieren min som utvikler i Capgemini. Men jeg var ekstremt nysgjerrig, så det jeg gjorde var å prøve veldig mange forskjellige roller innenfor det som heter applikasjonsdrift og applikasjonsutvikling. Og rundt 2014 så fant jeg det som kalles for DevOps. Jeg falt egentlig helt pladask for temaet. Mest fordi jeg synes det inneholdt alt av både hvordan tenke som en god leder? Hvordan legge til rette gode prosesser og hvordan lage gode systemer og god teknologi, da. Som støtter opp under det å skulle drive fremtidens selskaper. Så siden 2014 så har jeg egentlig jobbet mye med DevOps. Både med sånn teams utviklingsnivå, men også da litt mer på strategisk nivå.
Silvija: Si to ord om deg selv personlig også. Har du noen eksentriske hobbyer eller er det noe som jeg kan huske å spørre deg om neste gang vi møtes sosialt?
Marley: Ja, jeg har jo egentlig veldig mange hobbyer, men den morsomste er kanskje gaming. Jeg er veldig glad i å game. Nå venter jeg egentlig på at versjon del 2 av Horizon skal komme ut. Jeg tror den kommer ut i februar. Og da blir jeg nok borte noen kvelder for å sitte å game.
Silvija: Du Marley, jeg driver med sånn tante-gaming. Jeg driver med Farm Hero og Flash of Clans og sånn.
Marley: På mobilen da eller?
Silvija: Ja på mobilen. Men jeg har jo fire unger som lever litt i denne her etter hvert VR verden sin og det er veldig mye. Jeg vet ikke hva. Jeg vet det var Fortnite for en stund siden. Fortsatt morsomme ting som Minecraft og Roblox og sånt. Men hva er Horizon?
Marley: Horizon er et mer eventyr fantasy spill. Det er vel egentlig det jeg er veldig glad i. Så jeg følger en karakter også kan man gå en tur, også må man slåss litt. Så er det da å følge eventyret og følge helten gjennom det hele. Så kjempegøy. Så blir du veldig bergtatt av historien. Det er litt som å lese i en bok bare at du er med.
Silvija: Ja, så gøy. Er det noen sosiale former av virtuelle team også eller hvordan går det?
Marley: Ikke på Horizon. Det er det ikke. Det er ikke multiplayer. Jeg er ikke hard-core player. Så det går mest i PlayStation.
Silvija: Ja, men du den skal jeg sjekke med jentene mine rett og slett.
Marley: Gjør det. Hvor gamle er de?
Silvija: De er 10 og 12.
Marley: Men da tror jeg de vil like veldig godt Kena i stedet. Den vil jeg anbefale.
Silvija: Vi sjekker Kena. Når vi først er her – jeg lover å slutte å snakke om gaming etter hvert. Men det var en sånn utrolig vakkert spill. Min første utrolige forelskelse med spill på mobil var Monument Valley. Har du sett den?
Marley: Ja, er ikke det den…
Silvija: Det likner på sånne Escher tegninger, hvor det er en jente som må løse gåter og komme seg gjennom et vanvittig vakkert landskap. Men det er egentlig geometrisk tankegang som skal på plass etter hvert. Og 3D-manipulasjon. Jeg har ikke møtt en jente som ikke har blitt bergtatt av det spillet.
Marley: Nei, den er veldig fin. Og så er det ekstremt fin og nydelig musikk i tillegg. Hvor langt har du kommet, da?
Silvija: Det er to utgaver og vi har løst begge. Og vi har løst begge to ganger. Vi blir aldri lei.
Marley: Da har dere kommet mye lengre enn meg. Jeg er halvveis i første forsøk.
Silvija: Det må vi se på sammen neste gang vi møtes. Men nå Marley, DevOps. Hvis du skulle forklart meg over en middag uten at jeg sovner. Hva er greia med DevOps? Hva ville du sagt?
Marley: Ja, ja, da tror jeg egentlig jeg ville starta med hvorfor? For jeg tenker at det meste burde ha en sånn hvorfor. Hvilken verdi er det det vil gi. Og her kan vi egentlig trekke linjene til hvordan er det markedet funker i dag. Hvordan er det egentlig brukerne er i dag. Veldig mange er utålmodige. Sånn som hvis vi spiller Farm Valley. Hvis det hadde begynt å gå 2-3 minutter for tregt, så hadde du blitt irritert. Og da er det ikke sikkert du hadde spilt det igjen. Så brukerne i dag forventer mer av selskaper enn det de gjorde før. Samtidig så er det ekstremt mange buzzwords der ute å går. Man snakker om AI, blockchain også videre. Så er det veldig få som tenker over hvordan man skal praktisk ta det inn i selskapet på en måte som gjør at det genererer verdi raskt. Så hvis du spør meg hva DevOps legger til rette for og hvorfor så er det for å ta noe fra en idee til et produkt på raskest mulig måte. Og få det til å drifte så man kan kontinuerlig videreutvikle det man har i produksjon. Ga det mening?
Silvija: Ja, men men det høres ut som en god idé, men litt for abstrakt ide. Det er en metode for utvikling av spesielt, som da sørger for at produktene er veldig gode og effektive. Men hva er det som er spesielt?
Marley: Ja. Jeg er kanskje ikke helt enig der i at det kun er en metode for utvikling. Fordi for meg så er i hvert fall at det startet som det som skulle bryte siloen mellom utviklerne og operations og å få dem til å snakke mer sammen. Men så har begrepet egentlig bare vokst og vokst, og det er fordi man ser at det holder ikke bare med at utviklere og operations snakker nå må få med oss alle.
Silvija: Ja. For nå sa du noe som er veldig viktig som vi skal pakke ut for folk som ikke er software folk. Du snakker om utvikling og operations. Og et de problemene som vi ser ofte i software er at det finnes en gjeng som er fantastiske utviklere. De lager noe som ser innmari bra ut. Men så er det en annen stakkars gjeng som driver med drift av denne løsningen deres som kanskje får et mareritt av dette når det ikke fungerer akkurat som det skulle i forhold til kunder. Når det oppstår problemer som det er veldig vanskelig å fikse. Så det er noe med at ikke bare skal du bygge dette, men du skal leve med det. Og du skal leve med det på en måte som utvikler det kontinuerlig og helhetlig. Og det er kanskje der vi er inne på det konseptet og derfor heter det DevOps fordi det er development and operations i en eller annen sammenflettet prosess.
Marley: Helt riktig. Og det var sånn det startet. Men så har man jo sett at det er så mye mer det som må til for å få akkurat utviklere og driftere til å være sammen. Sånn som å se på arkitektur, se på ledelse. Så for meg handler DevOps mye mer om en kulturendring og endre kulturen i selskapet og hvordan lederne tenker fremfor at det kun handler om utviklerne og driftene som sitter for seg selv, da.
Silvija: Og det det du sa nå hvis jeg skal igjen pakke det litt ut av software verden. Dette er da kulturendring og en helhetlig ledelsesfilosofi som da går på at ikke bare skal du ha folk som bygger noe veldig tett på eller blandet med folk som drifter det, men du skal også ha design eller arkitektur i det du bygger på en måte som gjør det fleksibelt og som gjør det modulært og som gjør det mulig å utvikle over tid uten å rive ned hele greien. Og ledelse må også tenke ut i fra disse prinsippene. Og det er ikke så veldig farlig om det er lean eller scrum, men at det finnes denne tankegangen om helhetlig fleksibilitet.
Marley: Det er helt riktig. Man sier jo veldig ofte at det det består av fem komponenter. Og klarer man de fem komponentene så har man kommet ganske langt. Det er jo kultur som vi var inne på. Så lean and agile. Også er det det som har med automatisering som kanskje er mer den harde tekniske delen å gjøre. Men mye går på måling og det å få feedback for å finne ut hvordan man skal holde liv i det som er i produksjon. Eller hva er det brukeren trenger som neste. Og det siste går på å dele kompetanse. Og gjøre det både internt i teamet av designere, utviklere, men også de rundt deg bedre med at man deler sine erfaringer.
Silvija: Kan vi pakke ut hver av de fem? Og så vil jeg egentlig kommentere at det snakkes forferdelig mye om bærekraft for tiden. Det er blitt det hotteste temaet de siste 12 månedene. Og et av bærekraftsmålene – og bærekraftsmålene har gått fra å hete SDG’er, Sustainable, Development Goals til å hete ESG hvor det er Environment, Society Governance. Så de ønsker å minne oss på om at dette dreier seg ikke bare om klima og karbonavtrykk, men også om governance og society. Society går mye ut på dette her med rettferdig og utviklingsdyktig samfunn. Men governance går ofte på økonomi og innovasjon og sånn. Men ett av disse ESGene dreier seg om informasjon, samarbeid og deling. Man kunne nesten gitt dem DevOps filosofien som en oppskrift på hvordan man sørger for å få til denne 17 ESGen. Og det er gyldig utenfor software også. Det har jeg lyst å høre deg litt om. Hvis du kan hjelpe meg med å pakke ut disse fem tingene. Du sa kultur? Utviklingsmetode, lean også videre. Automatisering, måling og deling. Forstod jeg deg riktig?
Marley: Du forstod meg riktig. Så vi kaller det for CLAMS hele det begrepet med de fem punktene. Så Culture, Lean og Agile, Measurement eller måling kan du si. Automatisering og til slutt er det det som handler om deling. Så jeg er veldig enig i at de prinsippene og veldig mange av de tankene innenfor DevOps filosofien kan brukes til og med i markedsføring hvis man ønsker det. Og hjemme også forresten.
Silvija: Hjemme også?
Marley: Ja, man kunne jo tenkt kontinuerlig forbedring, for eksempel i parforholdet da. Og man kunne hatt visualisering av hvor effektive er vi på morgenen. Hvordan kan vi effektivisere oss selv. Så det er jo mye av prinsippene man også kan ta med inn i hvordan man styrer privatlivet.
Silvija: Ja. Eller prosjekter langt utenfor software som du også sa. Jeg tenker om man skal løse oppgaver innenfor skriving eller innenfor mange områder hvor dette fungerer. Hvis vi tar kultur. Kan du si noen ord om det? hva tenker man rundt kultur?
Marley: I kultur sånn som jeg tenker på det så handler det om å skape kultur hvor folk føler seg trygge. Hvor det er stor takhøyde og rom for å gjøre feil. For det er jo gjennom feil at man lærer og kan forbedre. Så skape en kultur hvor det er flat struktur. Hvor hver og en føler seg sett og hørt. Så man kan si mye av moderne ledelse ligger i den kultur biten, da.
Silvija: Trygghet, tillit under ansvar og så videre. Supert. Hva med da A? CLAMS, forstod jeg det riktig nå?
Marley: CLAMS, ja. Det stemmer.
Silvija: C er culture. L er?
Marley: Lean and agile. Jeg tror veldig mange kjenner til de prinsippene rundt både smidig og med flyt effektivisering med lean. Så det er jo metoder som også ligger i DevOps prinsippene. Hvor man tenker at skal man enable DevOps så er mye av tanken også i lean og agile veldig bra å ha med.
Silvija: Og det dreier seg om å bryte ned det prosjektet i mindre biter. Lære fort.
Marley: Bedre samarbeid mellom forretning og utvikling og å tenke også kontinuerlig på hvordan man utvikler og bygge nye løsninger da.
Silvija: Support CL, A. Automatisering?
Marley: Ja, fordi tradisjonelt, når det kommer til for eksempel testing og sånt, så gjøres det jo veldig manuelt, og det gjøres mot slutten. Så man lager kravspekk, man utvikler det, også tester man det. Men hvordan skal du egentlig vite at kravspekken eller det du utvikler er riktig? Før gikk man inn i en manuell prosess og testet det. Og det er veldig mange som har sett at det går kanskje greit å utvikle, men man finner veldig mange feil når man kommer til den delen som har med testing og prøve og gjøre QA. Så det DevOps sier er egentlig Shift Left, tenk testing og kvalitet fra starten og i alle ledd. Og forsøk å automatiser så mye som mulig fordi det er enklere å gjøre menneskelige feil. Så automatisering går egentlig på å bare legge inn testing som en del fra start til slutt for å faktisk få til den raske farten man ønsker i softwareutvikling.
Silvija: Det både du og mine tidligere samarbeids eller samtalepartner om DevOps bruker begrepet Shift Left. Jeg bare lurer på om vi skal pakke ut det begrepet for ikke-software folk. I mitt hode så tolker jeg det intuitivt med at man tenker en liste og ofte i programmering så går man gjennom lister. Og den listen går da fra venstre til høyre. Så hvis du skal gå ett steg tilbake eller tidligere i tidsforløpet så sier man Shift Left. Har jeg det riktige bilde i hodet nå?
Marley: Det er helt riktig. Så du kan jo si at test ofte kanskje er steg 10, det siste steget man gjør før man kan si at man er i mål. Men det har man funnet ut av at er ikke så lurt. For det koster å skulle rette på feil jo lenger ned i sjekklisten man kommer. Så la oss heller starte med å putte det inn mellom hvert eneste punkt i sjekklisten da.
Silvija: Ja. Kult. Okei, så CLAM. Hva er M?
Marley: M går på måling. For en ting er jo når man har laget sin bolk og puttet den ut i produksjon. Men hvordan skal man vite at det går bra med den? Hvordan skal man vite at det som man har satt ut i produksjon er det brukerne vil ha. Så Measurement går på å måle. Måle både det som har med stabilitet, det som har med kvalitet å gjøre. Men også målinger som går på hvordan bruker brukerne dette produktet. Hva er det de liker og hva er det de ikke liker? Hvor mange penger er det som går igjennom for å kunne mer datadrevne besutninger.
Silvija: Vi pleier ofte å si i ledelsen at what’s got measured gets done. Men her er kanskje tankegangen enda et steg lenger om whats get measured gets proved?
Marley: Ja nettopp. Og et godt eksempel der er jo også det store sikkerhetshullet som skjedde rett før jul med Log4j.
Silvija: Du må fortelle oss om det.
Marley: Ja, det var en sårbarhet i en av de her bibliotekene som veldig mange bruker. Og det har vel ikke vært så store sikkerhetshull siden Heartbleed som er et helt annet sikkerhetshull. Men det som skjedde var jo at det skapte kaos blant alle selskapene fordi her måtte man rydde opp i denne avhengigheten. Men hvordan skal man gjøre det om man ikke vet hvor i koden eller hvor i boken det er du har sårbarheter. Så de beste hadde da lagt inn monteringer og måler på også biblioteker og avhengigheter og de fant jo ut av hvor sårbarheten lå på 15 minutter og fikk fikset det. Mens andre selskaper slet og brukte tre-fire dager eller enda lengre på å forsøke å få fikset den sårbarheten. Så det er et eksempel på hvorfor monitorering er viktig. Det er ikke bare for å forbedre nødvendigvis, men også for å ta de tiltakene som man må når krisesituasjoner oppstår.
Silvija: Ja, så det jeg hører deg si er at en ting er at det er veldig mye glede man får av det for å rett og slett forstå status og dermed også forbedringsmuligheter. Men at det også er veldig mye lettere å se avvik når du har noe å måle mot og da kan du håndtere avvikene veldig effektivt.
Marley: Ja, det kan man. Tenk hvis vi hadde hatt det på korona, da.
Silvija: Og hadde vi visst hva vi måler, men bare det å koble sammen systemene litt bedre ville vært fantastisk. Jeg har akkurat fått innkalling for tredje vaksine. Men jeg har hatt omikron i desember. Og det er litt interessant fordi det er ganske opplagt at systemet for vaksinering og innkalling der ikke snakker sammen med dette registeret for sykdommer.
Marley: Ja, ikke sant.
Silvija: Ja, men det bringer oss hele tiden tilbake til evnen til å tenke helhetlig. Og den helhetlige tankegangen når man bygger software systemer dreier seg i veldig stor grad om å kunne koble teknologi med business behov også.
Marley: Ja, det gjør jo det. Og hvordan skal man vite at det man lager skaper verdi. Eller hvorfor skal man lage noe hvis man ikke kan enten gevinst realisere på det eller tilfredsstille brukere? Så det å koble på forretning og å få det også inn i hele bildet er jo en stor del av DevOps tankegangen.
Silvija: Ja, jeg tror egentlig at akkurat det spørsmålet du nevner nå om hvordan skaper vi unik verdi og hvordan kan vi forbedre vår evne til å skape unik verdi er en utrolig viktig strategisk spørsmål som må forstås også av de som bygger software for de løsningene. Inntil nylig så var det litt holdning hos gode teknologer om at de vil ha en spekk og du får fortelle meg hva du vil ha også skal jeg bygge det for deg. Men den har vi gått bort fra.
Marley: Man har det. Og det har jeg for eksempel eksempler fra der hvor jeg er nå og leder et team. Hvor det jeg gjør som en sånn leder er å fortelle dem hva problemet er og hva som er viktig for selskapet og hvilke rammer vi har å forholde oss til, mens selve hvordan skal vi løse og hvordan kan vi gjøre det bedre er det de som bestemmer og de som er med på å eie. Så den eierskap delen er jo ganske sentral både i smidig, men også veldig i DevOps.
Silvija: Ja, okey. CLAMS. Nå er vi på S.
Marley: S. Ja, det handler om å dele. Å dele kompetansen man har. Akkurat som kanskje vi to gjør nå, eller internt i et selskap gjennom for eksempel kompetanse-lunsj eller interne konferanser. Og det er jo fordi at når vi deler så gjør vi hverandre bedre. Vi deler erfaringer som da kanskje fører til at man ikke går i de samme fellene alle sammen.
Silvija: Veldig bra. Så vi skal tenke helhetlig og på en kontinuerlig utviklende måte på tvers av fem dimensjoner. Det ene er kultur som støtter en sånn type utvikling, og så er det lean og agile og det er fleksibel utvikling som lærer fort og ikke gjør sånne monolittiske greier. Vi skal automatisere blant annet testing, men også det som kan automatiseres sånn at det igjen gir oss større utviklingskraft, men også tidligere å finne feil. Måle ting fordi det gir oss bedre status oversikt, men også oversikt over avvik eller utviklingsmuligheter. Og dele kompetanse igjen for å kunne tenke helhetlig og for at både vi skal lære, men også andre prosjekter skal kanskje få litt drahjelp fra det man selv har utviklet. Du? Det er en myte som jeg lurer på om du kan hjelpe meg å adressere. Folk mener at sikkerhet og DevOps ikke går sammen. Hva mener du?
Marley: Jeg mener at det egentlig bare er en myte. Selvsagt er måten man tenker sikkerhet tradisjonelt mye med den DevOps saken går ikke sammen. Men akkurat som vi sier at med testing så må vi på en måte Shift Left og starte å tenke testing tidlig. Så gjelder det egentlig det samme med sikkerhet. Begynne å tenke sikkerhet tidlig og legge inn sikkerhet som en del av sjekklisten for automatisering og raskere feedback. Så jeg er veldig enig i at DevOps med tradisjonell syn på sikkerhet ikke går hånd i hånd, men med et moderne syn på sikkerhet vil jeg si at hvis DevOps handler om kvalitet og stabilitet, så er det å tenke på sikkerhet også ganske sentralt i det.
Silvija: Ja, og moderne syn på sikkerhet går egentlig ut på at det er ikke brannmurer og masse antivirus som redder verden, men det igjen er nesten en immunitets tankegang om at du må oppdatere ting ofte og du må være bevisst på sikkerhetshullene, eller om det er menneskelige feil du helst skal unngå eller systemene skal være sånn at det er lett å være sikker i dem.
Marley: Ikke sant. Og sånn som Netflix. Noe av det de gjør kaller de for Monkeys som går rundt å forsøker å finne ut hvor sikkert er systemet i ny og ne. Mer som en sånn brannøvelse. Så sånne type mekanismer er også mer på å gjøre oss bedre til å håndtere sikkerhet.
Silvija: Veldig bra. Helt på slutten av denne første samtalen vår Marley. Det høres ut som en veldig god idé dette med DevOps. Hvordan skaper man kultur i en bedrift som skal starte med dette her? Det begynner fra toppen, og hvordan begynner det fra toppen?
Marley: Ja, hvis du hadde spurt meg hva vil du si er det største hinderet i DevOps så vil jeg egentlig si at det handler om mennesker og lederskap. Så jeg tenker skal man skape en kultur rundt DevOps, så la oss egentlig som ledere tilrettelegge for at det er greit å gjøre feil. Å la folk få lov til å starte i det små. Også ha den der i stedet for store prosjekter med planer, bare starte og finne ut hvordan det går med de testene de gjør også forberede de litt og litt.
Silvija: For litt av problemet her hvis jeg skal være ganske uformell er at jeg tror at når vi skal sette i gang store kulturelle endringer så skal vi koke havet med en gang. Og da kommer vi aldri av flekken. For det er så vært og det er så komplekst og det er så uforståelig. Men det å begynne i praksis også begynne å gjøre det. Også kjenne litt etter hvor energien er hos folk og hvordan får vi og hvem er det som bryr seg og hvem er det som vil rulle dette ut. Finne noen prosjekter som passer også kjøre av gårde også lære fra det og snakke godt om det.
Marley: Ja, veldig enig der. Det er mange som går i den fellen hvor de lager en svær plan for en DevOps transformasjon og sier at om ett år så er vi i DevOps. Men så har vi det andre som tar mye mer approach med at vet du hva, la oss starte med en liten pilot. Se hvordan piloten går også bygger vi det ut. og jeg er mye mer fan av den tilnærmingen der. Hvor vi heller lærer underveis enn å tenke at vi har forutsatt alt fra starten av.
Silvija: Ja, for det er et problem som ligger enda tydeligere og enda en Shift Left her. For en ting er at selskapene sier at om et år skal vi være DevOps, men før de sier det så må de ansatte fem DevOps folk og fem DevOps hoder er ikke så lett å finne?
Marley: Nei, hva legger du i DevOps folk der Silvija?
Silvija: Det finnes stillingsannonser der ute hvor folk leter etter DevOps, mens de burde kanskje se på de hodene de har i bedriften og se på hvem er det som kan tenke seg å anvende denne kule metoden og la oss prøve det?
Marley: Jeg er veldig enig der. Jeg har også sett at det finnes en del utlysninger etter DevOps team og DevOps personer. Men hvis DevOps er en filosofi og at det handler mye mer om kulturendring, hvordan kan man da si at en person er DevOps? Så skal man få til det DevOps teamet som jeg tror mange snakker om så handler det kanskje mye mer om å se på de utviklerne, de testerne, de designerne og de på drift som man har og finne ut av hvordan kan jeg sørge for at disse deler kompetanse på tvers og blir et team som da gjør det samme.
Silvija: Superkult. Jeg liker også at vi lander egentlig på at DevOps er en filosofi. Nesten en religion som har noen grunnprinsipper. Vi har omtalt disse CLAMS. Kultur, Lean, Automatisering, måling og samarbeid. Også er det noe med å øve på det. Det er i utøvelsen at filosofien får mening.
Marley: Ja, det var egentlig veldig godt oppsummert vil jeg si.
Silvija: Ja, veldig bra. Da sier jeg kjempe tusen takk Marley for en spennende, inspirerende og lærerik samtale så langt. Og vi møtes om et par minutter for å snakke om noen gode eksempler på selskaper som har hatt glede av å anvende denne filosofien for utvikling og ledelse.
Du har nå lyttet til en podcast fra Lørn.Tech – en læringsdugnad om teknologi og samfunn. Nå kan du også få et læring sertifikat for å ha lyttet til denne podcasten på vårt online universitet Lørn.University
“
“
Velkommen til LØRN.Tech – en læringsdugnad om teknologi og samfunn med Silvija Seres og venner.
Silvija Seres: Hei og velkommen til LØRN Fundamentals. En masterclass om DevOps med Marley Kristin SIngarajah fra Gnist. Marley vi glemte å nevne Gnist. Du må si to setninger om Gnist Consulting før vi går i gang med leksjon to.
Marley Kristin Singarajah: Det er egentlig et nisjeselskap som ble opprettet våren 2019. Så rett før korona. Og er veldig verdibasert. Så verdiene våre er vitenskap, nysgjerrighet og frihet. Og vi følger da alle prinsippene og ledelsesfilosofiene innenfor DevOps i hvordan vi levder i selskapet. Og vi har ambisjon om å bli en av de fremste teknologi ledelses selskapene.
Silvija: Kjempekult. Hvor mange er dere?
Marley: I dag er vi 19, så når vi startet så var vi tre. Med Ellen Marie, en fantastisk dame som daglig leder. Og Petter som gründerne. Så har vi jo vokst og vokst og i dag er vi en kjempefin gang på 19 stykker.
Silvija: Jeg er også en veldig stor fan av Ellen Marie. Så du er i veldig gode hender.
Marley: Ja, og dere to kjenner jo hverandre med litt fra før. Gjør ikke dere det?
Silvija: Fra Oda. Men du, nå skal vi snakke om eksempler. Leksjon to dreier seg om at du velger tre-fire-fem historier. Norske eller utenlandske. Men historier som du har nær kjennskap til og som skal inspirere flere til å se seg selv i deres sko. Så det vi inviterer deg til nå er å fortelle hva var problemet og hvordan ble løsningen til og kanskje hva er de morsomste læringspunktene fra den prosessen. Her er litt sånn at prosessen er målet også i seg selv.
Marley: Jeg, ikke sant. Det jeg kanskje ønsker å få frem med historiene mine er mer at det finnes ikke et fasitsvar på hvor og hvordan du begynner med DevOps. Det kan komme som en del av et utviklings initiativ. Det kan komme som en del av mer toppledelsen. Det er så mange ulike innfallsvinkler og sånn sett finnes det ikke en silver bullet, men mye mer mange forskjellige historier på best practices som har vokst opp gjennom tiden. Et eksempel der er der hvor jeg er i dag hos Ruter. Hvor triggeren for det å skulle gå over til DevOps kom av at man så at den plattformen som Ruterbillett appen eksisterer på i dag, som jeg tror veldig mange har kjennskap til. Den var ikke godt nok rigget for ny type innovasjon. Det var vanskelig å få inn ny funksjonalitet selv om det var et ønske fra brukerne. Det var et ønske fra andre kollektive selskaper. Så for å imøtekomme det markedet ønsker, så startet man egentlig før jeg kom inn et initiativ for å splitte hele backenden til tre nye moderne mikro tjenestebasert arkitektur.
Silvija: Det betyr egentlig å splitte en sånn spagettisaus av masse avhengigheter i en monolittisk løsning til mange små boller som snakker veldig godt sammen.
Marley: Ikke sant og heller bruke en ny type teknologi. Altså i stedet for å bruke en rusten hammer, så gå over til en hammer som er mye mer moderne. Så her begynte det jo mye mer som en sånn okey markedet trigget dette. Hva kan vi gjøre? Jo vi må bytte om vår arkitektur og vår bunnplattform. Jeg kom da inn inn i august 2019. Mitt første oppdrag gjennom Gnist sånn sett. Og det som var på den tiden var at temaet ikke funket. Og det var egentlig mye kommunikasjonssvikt sånn sett mellom de ulike delene av organisasjonen og hva teamet egentlig skulle gjøre. Så måten jeg brukte DevOps prinsippene på her var jo å forsøke å skape et sammensveiset team med å bruke teknikker som Teams, Canvas, og prinsipper som fører til bedre utviklingspraksis. Samtidig som man på en måte også så på hvordan man kan lære av resten av organisasjonen i disse metodikkene. Så vi får flere ting som følger de samme prinsippene. Og det hadde nok ikke vært mulig uten lederne der. Jeg tenker da på Caroline Mortensen og Marit Rosenvinge som er godt i front og har troen på at den måten vi tenker å løse produktutvikling på for Ruter er veien å gå.
Silvija: Så her må jeg pakke ut en del ting. Det ene som jeg synes er veldig viktig å nevne her. Dette dreier seg også om en teknisk evoulusjon hvor man går fra disse monolittiske plattformer som bor i en server-kjeller til skybaserte mikro tjenestebaserte bibliotek baserte løsninger hvor man leker lego mer enn at man snekrer et hus. Og man må forstå hvordan lego egentlig funker best i denne sammenhengen. Og der snakker du om en ny moderne hammer. Men det er overkommelig læring for de fleste utviklere. Og de fleste utviklere synes det er kjempegøy å få lov til å være med på den type utvikling.
Marley: Ja.
Silvija: Så også sa du at dette dreide seg i veldig stor grad om å sveise sammen teamet, og det gjør man kanskje ved å gi dem en strategisk forståelse av oppdraget.
Marley: Ja, det er både dét. Men jeg tenker også at det handler veldig like mye om det sosiale. Noe jeg tror veldig mange nordmenn er dårlig på er å bli kjent med sine kollegaer. Og faktisk forstå hvem er kollegaen bak leveransen. Så jeg brukte egentlig mye tid på å ta dem med ut. Og på en måte spille bowling eller hva det skulle være. Veldig enkle triks, men trikset som er med på å skape tillit som gjør at det å ta de tøffe diskusjonene på jobb går fint fordi man kjenner hverandre fra privaten likevel.
Silvija: Og korona gjør ikke dette og hybrid arbeidsliv gjør ikke dette enklere. Derfor må man være ekstra bevisst på at teamet må etter hvert kjenne hverandre ganske godt og ha en god rolleforståelse for å kunne nettopp operere effektivt i et sånt nettverkssammenheng, da. Også snakket du om at dere også informert resten av organisasjonen om hvor dere skal og hvordan for å få både støtte, men også for at dere skal kunne levere i det hele tatt?
Marley: Ja, vi hadde jo om vi hadde MatPrat hvor vi introduserte temaet. Snakket høyt om det med prosjektledere, teamledere, og det var jo ikke bare meg. Det var jo da også Caroline Mortensen og Marit Rosenvinge som var med på den reisen med å forsøke å lære opp og være promoters av konseptet.
Silvija: Ja, okey. Og så sa du også dette med at ledelse var sentrale, ikke sant? Der nevner du to blant flere. Og det tror jeg er et poeng vi kan ta en liten runde til på. For vi tar en risiko ved å gjøre ting på nye måter. Alle organisasjoner har en etablert prosess mer eller mindre formalisert. Det er den prosessen folk blir målt på. Det er sånn budsjetter bygges. Det er sånn man leverer og det er sånn man får anerkjennelse for å ha levert. Så det å innføre nye leveransemodeller, men også nye strategiske verktøy er en ledelses risiko. Men den er overkommelig sier du?
Marley: Ja, jeg vil jo si at DevOps har sin kost. Det har jo det. Det er en investering som man må være villig til å ta. Men DevOps er jo ikke noe nytt nå. Det er mainstream. Det har vært til i over ti år og har kommet veldig mye forskning ut om hvorfor det er bra og alle selskaper der ute som gjør dette. Så i dag vil jeg si at det er ikke en like stor risiko å skulle gå over til denne filosofien som det kanskje var når det var nytt og kult for noen år tilbake. Det var en ting jeg skulle legge til. Men det som det vil si er at man ikke får det til med mindre ledelsen er med og støtter og backer underveis.
Silvija: Veldig bra. Da har vi snakket litt om Ruter. Jeg tror du nevnte Sparebank1 og Nav også når vi varmet opp.
Marley: Ja, det stemmer. Deres historier er jo synlige der. De har vært på veldig mange scener og fortalt om deres reiser. Og Sparebank1 var jo en av de som var tidligst ute. Og da startet det også som en mer arkitektur endring. Men det jeg synes var morsomt med deres reise er at samtidig som de da splittet den arkitekturen, så prøvde de også å prøve å forme ting. Og man prøvde å få inn prosesser. Og i starten funket det jo ikke. Vi gjorde jo alt feil. Men man ga ikke opp. Og man tenkte mye mer la oss starte et sted også tar vi å kontinuerlig forbedrer. Også har det vært reisen dems. Så ja, vi hadde et mål om å gjøre arkitekturen bedre, men resten er mer sånn som har gått seg til. Så det har ikke vært noe femårsplan på at om fem år så er vi der. Men det har heller vært en ambisjon og et ønske om t vi skal komme et sted.
Silvija: Reisen blir til mens man går, ikke sant. Og det du sier her er at vi skal være smidig og modulær på software arkitektur. Så må man etter hvert også være smidig og modulær på organisasjons arkitektur. Og dette her er alltid veldig vanskelige endringer, fordi det jeg merker er at folk vil jo vite hva jobben er og hva oppgavene er og hva tittelen er. Men den er jo litt i fluks når du jobber smidig. Og det er viktig å bygge en sånn trygghet og forståelse for dette her for at det skal funke organisatorisk.
Marley: Og hva var det du legger i fluks Silvija? Eller hva mener du?
Silvija: Nå snakker jeg med mitt lille selskap i hodet, men jeg tenker det skjer egentlig også i store software avdelinger når man skal lage ny arkitektur. Når du ansetter folk så får de en tittel og de får en oppgave. Og hvis du planlegger utviklingen av software plattformen, så lager du fortsatt 12-måneders planer og folk har roller og oppgaver og sånn. Men dette er i endring på grunn av denne leane og DevOps modellen hvor du finner ut at noe passer bedre til noe annet. Det er et mye større hull et annet sted. Dette haster mye mer. Dette har blitt flaskehals. Og dette med å kunne flytte på folk. Det er eierskap, men det er også mulig forflytning av eierskap. Det er ganske krevende å lede og motivere.
Marley: Det er jo det. Men vil du si at man har et alternativ som er bedre i dag?
Silvija: Og der tror jeg du har slått spikeren på hodet i nå. Jeg tror at alternativet er å bare fortsette å gjøre sånn som man alltid har gjort ting, og da har man i hvert fall null utvikling.
Marley: Ikke sant? Og da stopper man jo opp. Man sier at et system som står stille, den dør til slutt.
Silvija: Og noe av det som jeg tror er vanskelig å formidle tydelig nok til folk utenfor software verden er at disse systemene våre når de blir store og når de blir tilstrekkelig gamle sånn som de var bygget på gamle måter blir så kjøre. De blir så sårbare for alle minste endringer som kan skape helt utenkelige feil fordi det er så mange avhengigheter fordi man ikke tenkte modulært og fleksibelt og skalerbart sånn som du beskriver. Så dette er et såkalt teknologisk gjeld som venter alle organisasjoner som ikke går over til denne nye smidige arkitekturen og en DevOps tankegang. Men Sparebanken Sør, der oppfatter jeg at på Ruter var det noen veldig spennende perspektiver spesielt på ledelse og den menneskelige siden av DevOps. På Sparebank1 så var det dette med at man ikke begynte med å lage en femårsplan, men man bare startet også ga man ikke opp selv om det var to-tre vanskelige runder.
Marley: Ja, ikke sant. Det er jo Vidar Moe og jeg husker ikke navnet på han andre selv om han er superflink.
Silvija: Vi legger det til i notatene våre.
Marley: Ja, det var jo deres brainchild å skulle gå denne veien. Og selvsagt i starten så tenkte de også at la oss begynne med betaling. Det vanskeligste domene tror jeg. Men gjennom domene så fant de ut at okey, det er kanskje ikke der vi skal starte. La oss heller starte her. Så de har hatt en drøm, også har de tenkt la oss teste. Også testet, også sett at det funket ikke helt. Så har de testet noe annet i stedet. Jeg tror også det er viktig å påpeke i denne historien at ledelsen har jo vært med og gitt den founding og gitt dem tid og ro for å få teste det ut og få dette lille barnet til å blomstre internt.
Silvija: Ja, og hva med NAV?
Marley: NAV synes jeg egentlig er veldig artig. Det startet vel egentlig med Thorbjørn Larsen som gikk inn og hadde hele den dobbel fart for halv pris tankegangen.
Silvija: Du må ha peiling for å kjøpe peiling.
Marley: Ja, for å få det til. Og det synes jeg egentlig Thorbjørn Larsen var flink til for å få inn de rette menneskene. Så han fikk inn Ola Furu fra Capgemini. Han fikk inn Stig Aur, Kathrine Jansen, alle som var veldig tro mot den nye måten å skulle lede på. De fikk inn Truls og Audun som to veldig anerkjente og veldig flinke eksperter. Så det han gjorde var å samle folk som hadde samme type tro som han. Og når du har de kjemperne. De som går som first runners og får med resten. Da er det jo også litt enklere å skulle få til endring enn om du må stå der helt alene. Og det synes jeg de har vært smarte med. De har innsett at i store prosjekter funker det ikke. Vi må gjøre det annerledes. De har innsett at de selv må ta eierskap over IT. IT er ikke noe som kan outsources til noen andre. Og de har brukt det i stedet for å følge rammeverk slavisk. Det er mange som for eksempel ser på Spotify som sånn skal vi gjøre det. Eller så ser man på rammeverk som Safe eller Less og prøver å få det inn. Så har de funnet ut at vi må nesten ta denne reisen ut i fra vår kontekst og ut i fra å løse våre problemer. Så la oss hente inspirasjon fra ulike verktøy også lager vi det vi tror på, noe som jeg tror var kjempesmart av NAV å gjøre.
Silvija: Jeg er veldig glad i Torbjørn Larsen, og har vært veldig fascinert av egentlig han i en nesten sånn Martin Luther King rolle. han har vært rundt Lean og DevOps forsåvidt i offentlig sammenheng. Fordi det å endre disse store IT avdelinger og IT-prosjekter med enorme budsjetter er kjempevanskelig. For ikke bare er den gamle arkitekturen veldig skjør og ekstremt kompleks. Det er masse regulatoriske og institusjonelle avhengigheter som er vanskelig å fikse. Også er det også litt farligere å gjøre feil med disse offentlige tjenester. Både fordi risiko straffer seg så veldig i disse settinger. Så det som jeg vil tenke litt sammen med deg på eller få din reaksjon på er disse kjempene som du nevner. Med kjemperen Thorbjørn i forsetet egentlig. Jeg synes for å være helt ærlig at vi ikke har nok anerkjennelse for denne kampen. For det er neste generasjon som får veldig mye anerkjennelse for en god og solid arkitektur og gode utviklingsmuligheter også videre. Men det er faktisk veldig krevende å være den lederen som står på første rad og brøyter vei for en hel enorm organisasjon og helt ny kultur. Hva tenker du?
Marley: Jeg er veldig enig der. Jeg tenker litt hvordan hadde det vært om hadde det vært noen andre der inne som skulle prøvd å gjøre samme jobben. Endring er jo ganske tøft å stå i. Spesielt som den første som skal ut der å fortelle om noe. Og iblant for meg når jeg er i oppdrag og prater med ulike kunder, så føles det jo litt ut som at vi snakker to forskjellige språk og kommer fra to ulike planeter. Så jeg kan jo tenke meg at Torbjørn Larsen og hele den gjengen – de første som var med på dette og turte å satse på det har stått i en del stormer for å NAV til å komme der de er i dag. Så skal jeg ikke påstå at de er ferdige. De har fortsatt en vei å gå. Men de har kommet så enormt langt som gjør at de som kommer i andre rekke nå har en mye enklere jobb foran seg vil jeg si.
Silvija: Og jeg har snakket med noen utrolig flinke folk blant annet i designavdelingen til NAV og IT avdelingene. Det er så store prosjekter, og det er så komplekse greier og jeg synes de er utrolig flinke. Men det du ser er at det finnes noen som jobber med disse sentrale løsningene. Også hadde organisasjonen hatt så stor glede og nytte av at dette spredte seg til alle distriktskontorer, til andre funksjoner. Så det er her denne delingen og samarbeid og spredning kommer til. Og det er ikke lett det heller.
Marley: Nei, det er jo ikke det. Det er jo noe som må planlegges. Så man må ha de drivkreftene internt i selskapet som ønsker å bruke tid på å spre det glade budskap både internt og eksternt. Og det var der han blant annet hadde Audun Faukland og Truls Jørgensen. To stykker som faktisk gikk på turne fra kontor til kontor. Jeg tror historien deres også ligger ute på både JacaZone og Smidig Meetup kanalen.
Silvija: Den skal jeg sjekke. Og så tenker jeg at det er sånne historier vi må få ut av JavaZOne og Meetup kanaler. Det finnes så vanvittig mye spennende i disse dev-festene og diverse Github eller hvor det er man møtes for de som allerede er konverterte. Men det å spre dette til folk som ikke vet om de kanalene og som er gode ledere, leter etter et eller annet som er mer moderne i forhold til den nye ledelsen de vet de må ha. Og få disse verdene til å møtes. Det er noe av det vi prøver å gjøre her i LØRN. Jeg tror at noe av den forståelsen som skal til for å lage ting som skalerer i en veldig kompleks verden. Som endres på uforutsigbare måter. Det har vi egentlig kommet ganske langt med i software verden. Det er det vi kan. Det er det vi bygger og det er det vi har lært å optimalisere. Og akkurat samme problemstillinger tror jeg nå finnes i politikk. I helseledelse, i strategisk arbeid, i alle industrier. Og jeg tror det er veldig spennende å se hvordan disse konseptene som Lean, DevOps, Design Thinking også videre begynner å spre seg. Fra software til alt.
Marley: Ikke sant. Jeg er veldig enig. For mange av de prinsippene både smidig og design thinking og også DevOps er jo ikke kun laget for at dette funker bare på utvikling. Det funker bare på IT-selskaper. Jeg ser jo at prinsipper som visualisering da, det å visualisere progresjonen. Det å få opp en backlog er jo like relevant i politikken eller i markedsføringen som det er i IT selskaper. En kollega av meg jobber nå innenfor kringkasting med et team som jobber med signaler som går inn og ut. Og det har jo egentlig ikke noe med kode å gjøre i det hele tatt. Men selv der så har de jo brukt prinsipper fra DevOps inn.
Silvija: Og dette er veldig fremoverlent ledelse. Fordi det viser en nysgjerrighet. Jeg har tenkt litt på en tradisjonell MBA, en lærer der, organisasjonspsykologi og det er finans og marketing og makroøkonomi. Men det er veldig få MBAer hvor du lærer en kombinasjon av nye verktøy, som faktisk er de mest relevante ledelses verktøyene nå.
Marley: Ikke sant? En form for der du kombinerer teknologi og forretning med god ledelse og hva god ledelse betyr. Det er akkurat det med ledelse og lederskap jeg merker er et fag jeg brenner veldig for. For det finnes altfor få av de gode lederne som virkelig forstår den nye måten å tenke på. Så tenker jeg at ledelse er like mye et fag som hva enn annet fag vi skulle ha.
Silvija: Bra. Du Marley, er det noen andre eksempler du tenker har noen veldig gode poenger uten at du nødvendigvis nevner det med navn?
Marley: Ja. Veldig mange av eksemplene vi har nevnt nå er jo fra IT på en måte. Det har vært det som har vært triggeren. Men fra mer Telecom bransjen så har jo triggeren vært prioriteringer og det at man ikke har helt skjønt hva man egentlig leverer av verdi. Du har sikkert hørt om OKR. Altså Objective and key results.
Silvija: Jeg har en masterclass på det.
Marley: Ja. Da kan kanskje folk høre på det, da. Men der startet man jo heller å se på DevOps endringen fra den siden. Hvordan få porteføljestyring til å fungere. Hvordan lage et løp hvor man hele tiden prioriterer det viktigste først i stedet for å prioritere alt på en gang. For ofte er det også et problem. Man løper etter prioriteringer i stedet for å ha fokus på en og en ting og få det gjennom som er veldig innenfor Lean.
Silvija: Ja, det er veldig mange overlapp her. Det er veldig spennende hvordan både Lean og DevOps henger sammen med OKR og tjenestedesign. Men tankegangen er å prøve å tilpasse ledelse til denne VUKA verden. Volatility, uncertainty, complexity and ambiguity. Og det er den verden vi er nødt til å lære å leve i. For det gamle kommer ikke tilbake.
Marley: Nei, hun kommer ikke tilbake. Og så vet vi ikke hva som venter heller.
Silvija: Nettopp. Takk for en inspirerende og lærerik samtale i denne leksjon to. Vi møtes om noen få minutter i leksjon tre hvor vi skal snakke om verktøykasse.
Du har nå lyttet til en podcast fra Lørn.Tech – en læringsdugnad om teknologi og samfunn. Nå kan du også få et læring sertifikat for å ha lyttet til denne podcasten på vårt online universitet Lørn.University
“
“
Velkommen til LØRN.Tech – en læringsdugnad om teknologi og samfunn med Silvija Seres og venner.
Silvija Seres: Velkommen til LØRN Fundamentals om DevOps med Marley Kristin Singarajah. Dette er leksjon tre, og nå skal vi snakke om noen anbefalte verktøy. Det kan være tips and tricks, det kan være metoder, det kan være sjekklister, prosessverktøy. Og hva kan vi beskrive for folk Marley som kan hjelpe dem med å begynne med DevOps?
Marley Kristin Singarajah: Ja, det finnes jo litt ulike type verktøy. Hvis vi tenker mer på å skulle ta til seg mer kunnskap rundt hvordan det er man skal organisere disse teamene. Hvordan få til flyt? Så er jo bøker som Team to Policies, til The Phoenix Project. Dare to read vil jeg også si. Veldig gode bøker for å forstå litt mer av mentaliteten og forstå hvordan faktisk strukturere det.
Silvija: Du kan jeg spørre deg, The Phoenix Project har jeg fått anbefalt så mange ganger nå, og den har jeg ikke fått lest. Kan du beskrive veldig kort hva er dette Phoenix prosjektet?
Marley: Ja, det er en helt fantastisk bok. Når den kom ut så var den helt revolusjonerende fordi den er skrevet som en historie. Så du kan ta den med på ferie og sitte å lese den.
Silvija: Og den er faktisk lesbar. Det er ikke sånn at du liksom piner deg gjennom buzzwords*.
Marley: Nei, den er veldig lesbar og det som er at du vil også kjenne igjen karakterene som kommer. Du vil kjenne igjen kanskje prosjektlederen eller deg selv som leder. Eller den eksperten. Så alle disse karakterene går igjen.
Silvija: Kritikeren?
Marley: Kritikeren ja. Også er hele poenget det at det går veldig dårlig med det selskapet i boken. Han som da har tatt over som CTO trenger å ta noen raske grep for å få snudd om hele løpet og gjøre selskapet bedre og hvordan. Så får han en sånn Yoda lignende fyr på besøk i blant for å gi han noen tips underveis, da. Så en form for smidig coach kan man kanskje si. Så den kan jeg absolutt anbefale for å egentlig forstå litt av mentaliteten. Jeg snakker mye om at det er en filosofi. Men det høres jo veldig vagt ut. Så hvis man virkelig vil forstå hva er målet og hva går filosofien ut på? Hva er tankesettet? Så tenker jeg at The Phoenix prosjektet er en veldig god introduksjon.
Silvija: Det høres ut som en veldig, veldig god idé for kommende påskeferie for eksempel. Det er noe med at jeg tror at vi mennesker tar til oss kunnskap veldig mye bedre hvis det finnes noen personer og en historie og en dynamikk i det. Og det husker vi også på en helt annen måte enn om det bare er en liste med ting du burde gjøre og kanskje noen tall som viser at dette har funket før.
Marley: Ja ikke sant. Veldig enig. Også er det også litt mindre tørt enn om det skulle vært en sånn teoretisk bok om DevOps. For det finnes jo også. Men helt sånn praktiske verktøy, så har vi noe som heter DevOps modenhetsmodell som er en sjekkliste som man gå gjennom for å finne ut hvor moden er egentlig enten teamet mitt eller avdelingen min, eller selskapet mitt på dette område. Og da å få feedback tilbake på hvor er det jeg er god eller hvor er teamet mitt god og hvor er jeg mindre god. Og hvor er egentlig flaskehalsen. Så det er også en fin innfallsvinkel til å finne ut av hvor skal man egentlig starte for å gjøre endringer mot filosofien man ønsker å gå mot.
Silvija: Ja, denne modenhetsmodellen. Er det en bok vi finner på Norsk, eller?
Marley: Det er…
Silvija: Vi legger ved linken i denne jukselappen vår som hører til denne fundamentals. Men det er en bok som man kan lese og bruke noen verktøy fra den boken, eller?
Marley: Ja, det er en artikkel som er skrevet fra det globale arkitektur forum. Men den beskriver ting veldig bra. Og selve modenhetsanalyse hvis man googler den, så finnes det utrolig veldig mange forskjellige versjoner av den også.
Silvija: Ja, og den sjekker da hvordan tenke ledelse og hvordan planlegger man? Hva er det man må finne ut av når man skal fylle ut en sånn en?
Marley: Ja en ting er ledelse. Den andre er prosesser. Hvis det er for team så har den sjekkliste som går på team-helse, også har den også ting som går på hvordan er egentlig utviklingsprosessen. Hvordan er driftsprosesser? Hva med sikkerhet? Den går gjennom mange ulike deler, så kan man velge om man vil ta hele eller om man ønsker å ta bare en liten del av hele undersøkelsen. Så kan man selvsagt få inn en Gnist for eksempel å komme til å gi noen råd hvis man ønsker det.
Silvija: Ja, og så har du nevnt Team Canvas, tror jeg. Den har jeg lyst å høre litt om. Og så har du nevnt verdistrømsanalyse. Det har jeg også lyst å høre om. Kan du beskrive de to verktøyene for meg?
Marley: Ja, hvis man ønsker å ta ende til ende ansvar for et produkt, så må man jo…
Silvija: Hva betyr det?
Marley: Å ta ende til ende ansvar tenker du? Det betyr at du har et team, et autonomt team som har alle kompetanseområdene som må til fra det kommer inn som en idee til det er ute i produksjon. Så du har produkteier, kanskje en teamleder, en designer, utvikler, en fra drift og eventuelle andre roller som må til for å levere på akkurat den verdikjeden det er snakk om.
Silvija: Så når vi sier i LØRN at vi har ende til ende ansvar for å produsere digitalt kunnskapsinnhold for våre kunder, så inkluderer det planlegging, behovsanalyse, produksjon, post-produksjon, nye produkter, distribusjon, målinger. Så fra idee til ikke bare slutt produkt, men også en kontinuerlig levetid for det produktet. Inkluderer det også ende-til-enda?
Marley: Ja, det også.
Silvija: Til ingen ende på en måte.
Marley: Ja, en det er kanskje bedre å si det på den måten. Fordi hvis man sier start til slutt så høres det nesten ut som et prosjekt. men det er jo ikke et prosjekt her. Det er jo mye mer at det går kontinuerlig.
Silvija: Ja, okey. Så vi lager ende til ende produkter og autonome team betyr at dette er team som klarer å fungere uavhengig av resten av organisasjonen?
Marley: Ja det er målet. Så den verdistrøms analysen for eksempel er en fin teknikk for å finne ut av hvordan er mine verdikjeder i dette selskapet. Både på et mer forretningsnivå som går mer på hvordan er det jeg tjener penger eller får kunder inn, til mer på IT-nivå på hvordan er det vi får inn et behov og får det ut igjen på den andre siden. Og gjennom verdistrømsanalyse så kan man identifisere disse flaskehalsene som skaper trygghet i prosessen og finne ut av hva skal jeg gjøre for å få bort flaskehalsen. Litt omfattende prosess. Det skal det sies. Men det gir mye verdi hvis man orker å gå gjennom alle stegene som er i verdistrømsanalysen.
Silvija: Ja, og her er det egentlig oppdrag som å prøve å forstå forskjellige typer flyt som dette produktet er avhengig av.
Marley: Ja, det går rett og slett på flyteffektivitet. Hvordan kan jeg fjerne alle deler som ikke gir meg den tempoen jeg ønsker i selskapet.
Silvija: Og fjerne flaskehalser eller sorte hull. Supert. Hva var Team Canvas?
Marley: Team Canvas vil jeg anbefale alle å gjøre. Uansett om det er på ledergruppe nivå eller om det er på teamnivå. Men det er rett og slett fire ulike kvadrater som tar for seg mer av hvordan er det vi som en gruppe mennesker skal jobbe sammen. Hvilke verdier skal vi ha. Hvilke regler skal vi ha. Hva er egentlig målet vårt med å være sammen. Veldig elementær øvelse, men det jeg merker hver gang jeg er ute å har de team canvas assosiasjonene er at det binder teamet mye mer sammen fordi man får også snakket litt ut om konflikterende verdier. Så hvis min var frihet og din Silvija var kontroll, så har vi allerede der en konflikt i hva du verdsetter og hva jeg verdsetter. Og da kan vi ha en samtale rundt det for å finne ut gitt disse to ytterkantene, hva skal vi gjøre for å sørge for at vi begge klarer å samarbeide.
Silvija: Du dette er et kjempegodt poeng og vi kommer tilbake til dette når du skal hjelpe meg å tenke langs disse linjer for lille LØRN. Men det er ikke bare konflikterende verdier, men det kan også være uenighet i ambisjonsnivået. Og noen av disse verdiene er det sikkert veldig sunt å ha samtaler rundt.
Marley: Ja, veldig enig. Og ikke minst bruken av beskrivelsen av mål. Fordi vi sier jo at det finnes en del buzzwords, og DevOps betyr noe for meg og kanskje noe annet for deg. Så det å også bruke Team Canvas til å tydeliggjøre og definere hva vi sammen mener med et ord er jo kjempelurt. Ofte lager jeg også teamkontrakter ut av Team Canvas på slutten som gjør at folk skriver under på kontrakten.
Silvija: Og så tror jeg også den avklaringen i forhold til forventninger som man har til hva man skal jobbe med, hvordan man skal jobbe med det. At jo jo tidligere jo ærligere man har de samtalene jo bedre for alle parter egentlig. Og det er der jeg føler at vi mangler litt vokabular og vi mangler litt struktur også ender vi opp med helt vage greier om at det virker som en veldig hyggelig person som sikkert leverer bra, men hva betyr det for oss. Og er vi enig om hva det betyr som er veldig vesentlig her.
Marley: Enig. Ord kan veldig ofte misforstås.
Silvija: Og så er det noe med at hele denne øvelsen da er nødvendig fordi du snakket om tillit i team og at dette her skal være høyt funksjonelle team.
Marley: Ja, ikke sant? Og hvordan skal man egentlig da klare å bli et høyt presterende team som har tillit til hverandre om man ikke har snakket om disse områdene til å starte med. Det er nesten som å inngå et ekteskap ser jeg for meg.
Silvija: Ja, og det foreligger et felles ansvar. Og jeg tror noe av det som er veldig vanskelig i kanskje litt sånn konfliktskye Norge – jeg vet ikke om du er helnorsk kulturelt eller om du er en blanding? Jeg er i hvert fall en blanding og jeg har litt ungarsk blod og litt serbisk og jugoslavisk oppdragelse. Også egentlig mye Norge, men blandet med litt forskjellig i etterkant. Og det å kunne snakke direkte om forventninger. Det å gi direkte tilbakemelding. Hva er kritikk og hva er konstruktiv tilbakemelding også videre. Det er også veldig personlig. Og der tenker jeg at i Norge hvor det egentlig – sånn jeg forstår det og det er mulig jeg misforstår det, er ganske vanskelig å bryte konsensus. Jeg savner litt mer positiv friksjon. Agree to disagree, but then joined forces at the end, ikke sant. Og den dynamikken tror jeg er nødvendig når vi skal løse fort på møter vi aldri har gjort, med problemer vi ikke har forstått enda. Og jo mer man forstår teamet sitt og jo mer man stoler på hverandre, jo større sjanse er det for at man kommer gjennom denne utrolige ekspedisjonen.
Marley: Jeg er veldig enig. Jeg har jo også en veldig multikulturell oppvekst gjennom må være født i Sri-Lanka, men bodd i Norge mesteparten av livet. Så jeg kjenner meg veldig igjen i at veldig mange har en konfliktskyhet. Man skal ikke skille seg så veldig ut føler jeg veldig ofte. Men vi i et team så må det være lov til å ha litt temperatur når man snakker om de ulike ideene og vise at dette er noe jeg brenner for. Og det er noe av det Team Canvas prøver å trigger som en del av øvelsen. Det at man blir godt kjent. Som minner meg om en litt sånn artig historie. Jeg har jo et team med veldig mange ulike personlighet hvor han ene er fra Tyrkia. Så oppstod det en liten konflikt mellom to av mine norske i teamet og han. Hvor de norske ikke helt forstod hva som var greien. Så tok jeg en prat med han og skjønte at for han så var det å diskutere og vise engasjement var en del av det å være et team. Det var hans passion.
Silvija: Jeg kjenner meg veldig igjen. Det er litt sånn hos meg også. Det oppdraget er så spennende, og man må bare stole på at relasjonene holder fordi man er sammen om et utrolig oppdrag. Og at uenigheter bør brukes konstruktivt. Det er på felles perspektiver som flettes sammen. Men til syvende og sist har jeg også lært at kjempeflinke folk kan fort være litt primadonnaer. Det er helt OK å være eksentrisk. Det er ikke lov å være negativ. Og det er veldig stor forskjell på det å være litt ekstrem og litt eksentrisk med det å være negativ. Jeg tror at hvis vi alle drar – selv om vi drar i litt forskjellige retninger. Så lenge vi har nok krefter som drar det sammen så har vi en kjempesterk vektor. Men hvis vi drar det i helt motsatt retning, og hvis vi stopper opp hverandre, så blir det ikke noe særlig bra.
Marley: Nei, det gjør jo ikke det. Også er det også noe om at hvis vi er alt for like og alltid er enige, så blir det heller ikke noe bra. Hvor kommer da de eventuelle nyskapende ideene fra hvis alle skal tenke helt likt og ikke tørre å gjøre noen endringer. Så noe jeg også bruker sånn sett i min verktøykasse er jo det man kaller for en team kapabilitets modell for å kartlegge alt av kompetanse og finne ut av hvor er det vi er like og hvor er det de er ulike, og hvordan kan vi dele kompetanse mellom de ulike i teamet? Som da går på siste prinsippet av DevOps. Altså sharing.
Silvija: Ja, jeg tror Marley at vi driver å går rundt en grøt som er igjen litt større enn DevOps. Det dreier seg om hvordan leder du når du ikke helt vet hva problemet er. Du vet hvert fall ikke hva løsningen skal bli. Og du har kanskje ikke alle verktøy på plass heller for å løse det. Og det eneste som er sikkert og som vi ble enige om før er at du kan ikke bare håpe at problemet går over, eller at du inkrementelt forbedrer dagens løsning med 5% og et eller annet. Og det å nettopp kunne løse disse ukjente problemene med ukjente verktøy for helt nye kunder er der denne DevOps filosofien prøver å bidra.
Marley: Helt riktig. Og er det ikke litt spennende å kunne bruke en sånn type filosofi til å løse problemene som mange egentlig ikke har svaret på. Det krever selvsagt som vi har vært inne på en god del av ledelse. Det krever at man gir tillit. Det krever at man tør å investere som Torbjørn Larsen gjorde blant annet. Men man går jo da inn i en litt mer eventyrverden tenker jeg.
Silvija: Fortellinger er veldig viktige. Det å skape bilder. Du nevnte visualisering og jeg tror at det å visualisere fremtiden og tørre å velge blant scenarioer er utrolig viktig her også. Det er kjempe risiko for ledere fordi tenk om du velger feil. Men så tenker jeg tenk om du ikke velger noen ting. Folk aner ikke hvor de skal. Så kan du si noen ord om visualisering?
Marley: Det kan å gjøre. Visualisering gjøres på litt ulike nivåer. Men tradisjonelt sett når man var i team, så er det sånn at noen kommer og spør hva er status. Hvordan går det med denne leveransen? Er vi snart i mål? Og hvordan ville du følt det Silvija hvis du hadde hatt en leder som konstant kom å spurte hvordan det går med leveransen in. Er du snart i mål?
Silvija: Jeg ville tenkt at jeg antagelig underkommuniserer hva jeg holder på med, og at vi har egentlig veldig lite forståelse av hvordan strukturene her skal fungere.
Marley: Og i tillegg så hadde du kanskje blitt litt forstyrret. Det hadde mistet ditt fokus fra det du holder på med. Og det hadde tatt tid å komme tilbake inn i fokuset. For veldig mange utviklere er det hvert fall sånn at det å skulle utvikle krever ekstrem fokus. Det krever at du får lov til å få mulighet til å sitte for deg selv uten å hele tiden bidra i ulike typer møter her og der. Men som leder så har man jo behov for status mellom progresjon. Man har behov for å vite hvor er risikoen. Så visualisering hjelper egentlig både deltakerne i et team, men også ledelsen til å forstå hvor er vi. Hva er det egentlig teamet holder på med. Uten at de må gå å plage en utvikler eller plage et team medlem for å få den oversikten. Så kan du bygge det opp. Du startet kanskje på teamnivå, men det er knyttet til et annet initiativ som kanskje er på avdelingsnivå som igjen er knyttet mot en strategi eller en retning som bedriften har, så du til slutt får et trappetrinn av visualisering.
Silvija: Med det jeg forstår deg på er at det ikke er nødvendigvis at man forestiller seg noen scenarioer også videre, men at man lager noen gode dashboards som er skreddersydde og som virkelig formidler hvor prosjektet skal og hvor langt vi er kommet på vei. Og eventuelt hvor blinker det rødt.
Marley: Ja, for du var kanskje mer inne på visualisering av fremtidsbildet?
Silvija: Ja, men vi trenger begge deler. Også innenfor lille LØRN. Og det kommer vi også tilbake til. For dette med å lage gode performance og analyseverktøy både for utvikling, men også for drift er utrolig vanskelig. Og for å få dette til så må man ha en god omforent forståelse av hva vi leverer. What does good look like også videre. Og det er ikke bare bare å gjøre det heller.
Marley: Nei, det er jo ikke det. Men man må jo starte et sted, og veldig ofte det jeg starter med er å si til folk kan ikke dere bare få opp det dere driver med i dag på et board. Så starter vi der. Også bygger vi det ut. Og i forhold til monitorering og den biten der så tenker jeg som man gjør i produktutvikling der man tenker MVP. Altså hva er det minste som gir verdi som du kan få ut. Og sånn tenker jeg også med det som har med monitorering, automatisering og visualisering å gjøre. Hva er det minste man kan lage som gir noe. Så bygger vi det ut etter hvert som vi lærer og etter hvert som vi henter inspirasjon fra andre bøker. For eksempel Bora metrikkene er noe som mange bruker nettopp til å få ut den type målinger som vi ønsker, da.
Silvija: Hva betyr Dora?
Marley: Dora, det kommer fra en bok som heter Accelerate. Det er kanskje en mer teknisk bok enn The Phoenix Project. Og står for fire ulike metrikker som du kan måle. Jeg husker ikke alle fire, men lead og entertainer er en. Hvor raskt går det å fikse en feil. Finne en feil og fikse en feil. Det kan være nummer to. Og hele tanken er å finne den type metrikker som ikke nødvendigvis måler hvor mye feil du egentlig har i produksjon, men heller måler ting som gjør at du endrer behaviour.
Silvija: Så i stedet for å vise deg et statisk sett med mål hvor jeg synes ofte at hvis man bare teller antall feil man har funnet og fikset, så løser det ikke det opprinnelige problemet, men det er kanskje alt for mange feil. Eller det tar alt for lang tid å fikse dem for eksempel. Men det å vise at antall er maks antall feil man har også til en hver tid, og det har noe med en prosent av antall linjer kode eller noe som gir mening med kompleksiteten. Og det tar alltid mer enn to uker å få det fikset eller oppdaget begynner å tyde på en veldig effektiv produksjon og driftsteam.
Marley: Ikke sant. For vi vet jo at feil vil oppstå. Det er helt naturlig. Så hvorfor fokusere på at det er så mange feil når vi heller kan se på hvor raske er vi til å fikse de når de først kommer?
Silvija: Ja. Dette minner meg litt om situasjonen i callsenterbransjen hvor de måler antall oppringinger og antall minutter med kunder også videre. Men det beste produktet og det beste selskapet har et callsenter som kanskje ikke har så veldig mye å gjøre faktisk. Men det er veldig bra. For det betyr at du fikser feilene når de oppstår, så kanskje en relevant metrikk her ville vært hvor mange er det som ringer inn med samme feilen og over hvor lang tid? For det tyder på at feilen er der og er veldig kostbar uten at noen fikser det.
Marley: Ja, ikke sant. Artig. Jeg har ikke tenkt på at dette også kan gå inn der. Men det er jo absolutt noe som kan gå inn i callsenter og også kanskje markedsføring. I stedet for å måle på hvor mange reklamer er det jeg får ut, kanskje finne de metrikkene som gjør at man endrer hvordan man tenker markedsføring i stedet.
Silvija: Ja, eller at det leder til reelt og strategisk viktig oppførsel og handling hos de som er mottakere. Hvilken effekt har dette her til syvende og sist. Jeg synes vi måler litt for mye av det som er lett å måle i stedet for å måle det som er virkelig vesentlig.
Marley: Og det samme kan vi også kanskje si – nå beveger vi oss kanskje inn i noe farlige greier, men jeg tenker også på politikk da. Når vi tar beslutninger der. Hvor mye av de beslutningene er basert på data og analyse? Det må da være noen som kan gi den type analyse og data man trenger for å ta mer datadrevne beslutninger i stedet for magefølelse eller konsensus.
Silvija: Jeg tror at dessverre så er det noen som har funnet ut hvordan de gjør det. Og det er er sånne Cambridge Analytica bedrifter, men våre egne politikere kunne også vært litt mer data smarte. Og ikke for å lese okey, hva ble media bildet av det jeg sa i går og hva ble reaksjonene av folket. Men tenke over hva er det jeg virkelig ønsker å endre og hvor er det skoen trykker aller mest der og hvordan blir den prosessen og hvordan kan jeg oversette det til effekt på samfunnet. Der føler jeg at det er litt for lite kobling til data, da.
Marley: Det er det. Kanskje vi skulle foreslå noe datadrevet politikk eller noe som endrer det synet.
Silvija: Eller politikk må være verdi drevet, men det burde være data-smart. Så det skremmer meg også når folk begynner å snakke om at nå skal vi begynne å bruke kunstig intelligens for den kan fortelle oss mye mer. Men for meg er det grunnleggende galt. For politikk må være drevet av hva folk vil. Ikke hva en AI forteller dem ville vært bra for velger tallene eller noe sånt. Men vi må likevel bruke AI for å hjelpe oss å forstå hvordan går det i det ene scenarioet og hvordan går det i det andre scenarioet for å forstå om det vi virkelig vil er bekreftet på noe vis.
Marley: Jeg er veldig enig der. Jeg tenker enten AI eller data i forhold til analytics kan gjøre er å kanskje spare deg tid for å måtte grave i ulike typer dokumenter. Mens har du den dataen så har du et grunnlag som gir deg noe. Også må man jo også da tenke på hva er det folk vil. Også tenker man menneske delen av det som har med politikk å gjøre. Men da har du det dekket det som har med data og det som er harde fakta inn i beslutningen.
Silvija: Marley, vi har snakket om flere verktøy her. Det viktigste var kanskje verdistrømsanalyse som var en strukturert måte å tenke på dynamikk og flyt gjennom systemet. Man prøver å fjerne flaskehalser og forstå sorte hull og forstå hvor er det vår prosess ikke fungerer godt nok. Eller produkt. Så snakket vi også om diverse team utviklings og samkjørings verktøy. Blant annet canvas. Og du nevnte noen andre navn her. Men det dreier seg om å både forstå og diskutere sånne ting som verdier, regler og mål med teams. Så snakket vi om noen verktøy for å visualisere for eksempel status og utviklingsplaner for produksjon. Og der er det også veldig mye spennende rundt noen gode metrikk systemer eller målings prinsipper for å måle det som er viktig og ikke det som er lett å måle. Også glemte jeg å nevne noen av disse bøkene som du nevnte, men The Phoenix Project er hvert fall på top of my list og den skal leses i løpet av ikke så lang tid.
Marley: Så bra. Jeg er veldig spent på hva du tenker om boken.
Silvija: Jeg elsker sånne bøker, så jeg kommer sikkert til å digge den. Men tusen takk for nok en spennende samtale. Vi møttes om en kort stund, for å ta et bitte lite mini verksted på hvordan kan LØRN bli DevOps smart.
Marley: Det blir spennende.
Du har nå lyttet til en podcast fra Lørn.Tech – en læringsdugnad om teknologi og samfunn. Nå kan du også få et læring sertifikat for å ha lyttet til denne podcasten på vårt online universitet Lørn.University
“
“
Velkommen til LØRN.Tech – en læringsdugnad om teknologi og samfunn med Silvija Seres og venner.
Silvija Seres: Hei og velkommen til LØRN fundamentals i DevOps og gjesten vår Marley Kristin Singarajah fra Gnist Consulting. Marley, vi har hatt tre samtaler i denne firedelte digitale kurs opplevelsen som vi kaller masterclass eller fundamentals. Den første var en introduksjons tema. Andre leksjon var dine favoritt eksempler. Tredje var en verktøykasse som inkluderer bøker og noen metoder. Og nå er vi i den siste fjerde leksjonen som er egentlig bare ti minutters samtale hvor jeg får litt gratis consulting.
Marley Kristin Singarajah: Det blir gøy.
Silvija: Og så kan våre lyttere tenke at det snakke om deres bedrift og ikke lille LØRN. Jeg tror mange SMB ledere hvert fall vil kjenne seg igjen i en del av de problemstillingene som jeg stiller deg. Og situasjonen vår er at vi har en plattform. Den kalte vi for LMS inntil nå nylig. Learning Management System. LØRN har en todelt strategi eller business modell. Halvparten av inntektene våre om dagens hoveddel av det vi gjør er egentlig produksjoner for bedrifter hvor vi samler deres beste historier og sprer dem internt for å samle og forene. Og eksternt for å tiltrekke talenter og kunder og partnere. Men i tillegg til denne produksjonen så går alt dette inn i et bibliotek og dette biblioteket er en salgs Spotify for læring som nå heter LXP. Ikke LMS lenger. LXP står for Learning Experience Plattform. Og det vi ønsker er at læringen for voksne skal både bli smart på nye digitale formater som folk har som quiz, som TikTok videoer også videre. Men også litt gøy. Litt spill. Litt personalisert. Så det vi får når vi går inn på Amazon eller Netflix eller Spotify burde være noe av det som møter oss når vi skal inn å lære. Og vi lærer fra historier og vi lærer fra innhold som må produseres ganske fort. Mye fortere enn det universiteter gjør i dag, fordi verden endres så veldig fort.
Marley: Så en form for gamification og litt sånn ny tenkning rundt deres plattform, da?
Silvija: Riktig. Og da er mitt spørsmål egentlig en veldig sånn åpen greie. Hvor kommer DevOps inn i bildet for meg? Jeg har et software produkt. Vi er 10-15 personer i teamet. Tredelt mellom salg, produksjon og teknologi. Hva kan jeg gjøre med DevOps?
Marley: Veldig godt spørsmål. Det første jeg ville ha spurt om for de som ønsker å gå den veien er hva er driveren. Hva er det du ønsker å oppnå. Og her høres det jo ut som det er veldig klart. Dere har en tanke om å gå fra der dere er i dag til en litt mer ny form for plattform. Nummer to som jeg kanskje hadde sett på da er hvordan dere jobber i dag. Jobber dere sammen i disse tre delene eller er dere kryssfunksjonelt team? Hvordan er egentlig flyt effektiviteten? Er det mye overleveringer fra de ulike delene eller er det mye mer sømløst sånn at man ikke bruker så mye tid på handover og den delen?
Silvija: To kommentarer her. Svaret på den første er at vi går fra en litt administrativ plattform fra du var registrert, du tok dette kurset, nå tok du dette kurset, her er et sertifikat, ha det bra. Til sånn “”åh, nå tok du dette kurset. Nå har du sort belte i AI og vi anbefaler deg denne spillelisten og denne spillelisten, og dine venner utfordrer deg med en tredje spilleliste og det er influencere som mener noe””. Det dynamiske medie universet. Så plattformen skal bli mer gamefied og personalized og AI driven, men på et høyere nivå så går vi fra et prosjektbasert selskap til et plattform basert selskap. Så jeg er litt usikker på hvilke av de to nivåene bør vi egentlig diskutere når vi snakker om DevOps. Det er mitt første spørsmål. Kanskje vi skal ta det først også kommer jeg tilbake til krysspunkt funksjonalitet.
Marley: Ja. Jeg tenker begge deler er viktig. Både det som har med plattform nivået og hvordan skal vi egentlig rigge det sånn at det går av seg selv?
Silvija: User experience.
Marley: Ja ikke sant, men også nivået over. Fordi jeg hører at ambisjonen er veldig stor. Men hvordan skal vi få bryte det ned til noe som er lite sånn at dere kan starte. Så det ville vært mitt andre sånn – hvor starter vi? Hvor finner vi vår lille pilot som gjør at vi kan begynne å teste ut ambisjonen deres.
Silvija: Ja, og det gjør vi ved å dele plattformen i spor. Også er det et spor om studenter, et spor om forretningskunder, et spor for de som faktisk kommer inn med innhold til plattformen som tredjepart også er det litt sånn universitetsledelse. Og der tenker jeg at vi har fått til en utrolig spennende modell. Kjempeflink CTO. Veldig bra team som egentlig jobber DevOps og Design Thinking og Lean. Hele greien. Men det andre spørsmålet som du hadde om kryssfunksjonelle team synes jeg er veldig krevende. For vi er et veldig lite team. Og på den ene siden er det nesten litt for mye overlapp i oppgaver og det er armer og ben i startups. Vi kan ikke ha folk som fokuserer på en ting. Det er ikke nok av oss. Men likevel det å ha strukturerte koblinger. At ikke alle skal være med på alle møter fordi det har vi ikke tid til. Så hvordan lager man denne flyten på rolle nivå i organisasjonen synes jeg er et super relevant spørsmål.
Marley: Ja. Jeg liker egentlig ikke å si dette, men det finnes jo egentlig ikke et fasitsvar. Men jeg er jo helt enig i at når det er et gründer selskap som er et startup selskap, så er det nok mye mer allerde kryssfunksjonelle enn de store selskapene. Men teknikker som for eksempel visualisering, flyteffektivitet. Hvor er det dere har deres flaskehalser? Hvor er det det stopper opp? Det er jo kanskje da neste steget å gå inn på når både målet mot å gå mot DevOps er definert. Alle vet hvor visjonen er. Man har et team som jobber. Man har en plattform som man kan jobbe ut i fra. Så hvor er egentlig de neste flaskehalsene som legger en stopper for å nå visjonen, da.
Silvija: Jeg synes det er et veldig, veldig godt startpunkt og tenke litt på hvor er det vi snubler over oss selv og hvor er det vi ikke har et tydeligere ansvars og eierskapsforhold. Men steget før det tror jeg er også noe som er litt utfordrende. Og vi lider fortsatt litt av gründer syndromet. Vi holder på å fikse det, men det er jeg som har en enorm visjon. Men det å formidle det så hele teamet er med på det og former det er også veldig krevende. Hva slags råd har du i forholdt til dette med å samle seg strategisk rundt en visjon sånn passe demokratisk. Fordi med full demokrati blir det bare kaos. Hvis alle vil forskjellige ting og man klarer ikke helt å bli enig. Vi hadde folk i ledelsen som ville noe helt motsatt av meg. Det er veldig forvirrende for teamet. Så hva tenker du der om samkjøring?
Marley: Det tenker jeg og er veldig viktig. Også er jeg helt enig i at det er en balansegang mellom å gi full tøyle til at alle skal være involverte til en hver tid. Til det motsatte hvor det er Silvija som bestemmer alt. Men det jeg hører er at dere har kommet i en fase med eierskap. Folk må begynne å få eierskap til den visjonen. Føle at de er med på å definere retningen de også. Så du vil jo alltid være ansvarlig som leder for retningen din. Men er du da villig til å la de andre slippe til for å være med på å finne ut av hvordan skal vi nå den retningen?
Silvija: Ja, i aller høyeste grad. Bare ambisjonsnivået er høyt nok.
Marley: Så jeg ville satt opp en workshop da for å dele. Dette er min versjon. Dette er det vi skal nå. Hva tenker dere? Få med folk og hvor. Og kanskje få laget de første OKR eller noen ambisjoner. Men dette er første mål. Hva skal vårt første mål være da? Det kan jo resten være med på å bestemme. Også etter tre måneder se om vi klarte å nå det første målet til den store ambisjonen vår.
Silvija: Ja. Du er helt på riktig spor. Og vi jobber nå med disse strategiske workshopsene og jeg tror det som er vesentlig igjen før det er å oppbemanne til denne minimum necessary level. Også være litt realistisk på hva som er en sånn minimums nødvendig nivå, for der tror jeg veldig mange startups og små organisasjoner står litt i en sånn umulig spagat mellom det å holde kostnadene nede og det å likevel ha nok ressurser til å skape vekst. Og dette dreier seg i veldig stor grad om en veldig god organisasjons arkitektur først og fremst. Og det å tørre å jobbe aktivt med den arkitekturen har vært noe av det viktigste vi har gjort og noe av det viktigste jeg tror vi har en stor jobb igjen på.
Marley: Det er veldig kult å høre hvordan dere har jobbet. Det virker jo som at en kontinuerlig forbedring er en del av kulturen allerede. At dere tar gjerne en sjekk på hvordan er det vi jobber. Hvordan er vår arkitektur. Hvordan kan vi forbedre som neste steg og ha det litt mer kontinuerlig enn andre selskaper.
Silvija: Ja, jeg tror det. Jeg tror det funker. Også er det veldig slitsomt for folk også. For det jeg hører er at folk synes det blir veldig mye endring. Denne kontinuerlige endringen som jeg tror er en nødvendighet nå har sin psykologiske kostnad. Og der er vi kanskje tilbake til noe av det du snakker om at det er litt med disse sosiale belønningene som er en nødvendig del av ligningen når man lever i disse ekstreme endringstider.
Marley: Veldig enig. Bare for å få folk til å tenke på noe annet. Et sånt tips jeg fikk veldig tidlig når jeg starte tsom smidig coach, fordi jeg ble jo så ivrig på å forsøke å implementere alle de verktøyene og alle de prosessene vi hadde. Så fikk jeg et tips fra utvikleren min om at kan vi ikke bare innføre en eller to. La det få lov til å gå litt tid. Også kan vi ta å innføre flere etter hvert. Og det tenker jeg også er ganske viktig. Ja, man skal endre seg og det er viktig å gjøre det steg for steg. Og i den prosessen kan det også være lurt å la det gå litt rom. La det gå litt tid før man putter på flere endringer. ,
Silvija: Ja, supert. Hva er det viktigste vi ikke har snakket om Marley? Er det noe du har på hjertet som vi har glemt å ta opp?
Marley: Jeg tror vi har tatt opp det meste, men det jeg kanskje har lyst til å påpeke en sånn ekstra gang i forhold til om det nå DevOps, smidig eller hva som helst i den sfæren er at alle de fokuserer veldig på det som har med kontinuerlig forbedring å gjøre. At det egentlig er det som er kjernen. At det handler om å bare starte. Også forbedre etter hvert. Så for selskaper som ønsker å gå mot DevOps så tror jeg den tankegangen der med å starte et sted også forbedre det er ganske viktig. Og nummer to, det vi egentlig har snakket veldig mye om at dette er en endring for ledelsen. Og endring for hvordan ledelse drives. Så for ledere der ute så tenker jeg det kan være lurt å se på hvordan det er med fasiliterende ledelse og finne ut hva må jeg endre i mitt lederskap for å få til dette.
Silvija: Supert. Kontinuerlig endring og kontinuerlig helhetlig ledelse og en god filosofi til å støtte det opp. Både med verktøy, men også med prinsipper. Tusen takk for en lærerik samtale om DevOps, Marley Kristin Singarajah.
Marley: Tusen takk for at jeg fikk være her. Det har vært veldig artig å få lov til å diskutere tema med deg.
Silvija: Og tusen takk til dere som lyttet også.
Du har nå lyttet til en podcast fra Lørn.Tech – en læringsdugnad om teknologi og samfunn. Nå kan du også få et læring sertifikat for å ha lyttet til denne podcasten på vårt online universitet Lørn.University
“
Du må være Medlem for å dokumentere din læring med quizes og motta læringsbevis. Prøv et
Allerede Medlem? Logg inn her
Du må være Medlem for å dokumentere din læring med quizes og motta læringsbevis.
Allerede Medlem? Logg inn her
