“

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. Jeg er Silvija Seres og tema i dag er agile lederskap. Gjesten min er Signe Marie Hernes Bjerke, en god og gammel venn fra studietiden og en av Norges beste pedagoger på temaet. Jeg gleder meg veldig til å høre deg. Signe. Velkommen.

Signe Marie Hernes Bjerke: Tusen takk, Silvija! Det er stas å få være her med deg i dag. Veldig fint.

Silvija: Ja, likeså. Jeg har egentlig hatt denne samtalen på ønskeblokken min ganske lenge, og det har noe med å avmystifisere et tema som jeg ser egentlig hele offentlig sektor i Norge har blitt kjempe opptatt av. Etter pandemien. Det dreier seg om ny kultur som er litt mere lærende, litt mere fleksibelt og kanskje litt mindre hierarkisk. Både ledelse og gjennomføringsevne, metodikk. Vi håper da du kan hjelpe oss å navigere i dette landskapet, slik at så mange som mulig forstår konseptene og forstår verdien.

Signe Marie: I will do my best. Det er et veldig spennende tema.

Silvija: Det er et spennende og viktig tema. Du, Signe. Jeg skal bare si to ord om selve formatet før vi setter i gang, i tilfelle noen høre på oss første gang i dette formatet. Så LØRN lager vanligvis 30 minutters samtaler om konkrete innovasjons historier, eller “caser” som vi kaller dem. Det er innovasjonsprosjekter. Det er veldig konkret og egentlig ganske sånne bransjespesifikke eller bedriftsspesifikt. Nå er det sånn at vi også lager noen generiske kurs, om du vil, på tema som reiser på tvers av bedrifter og på tvers av sektorer. Og det kaller vi for Fundamentals, før kalte vi det for masters. Ideen er at du leverer en to timers foredrag. Fire foredrag, 30 minutter hver, som er et slags podcastkurs. Det er veldig uformelt. Det er veldig samtalebasert. Det er lett å lytte til, men likevel så skal det inspirere folk til å gå inn og lære mer om et tema som er veldig viktig for dem. Og det er det vi lager nå. Første samtaler dreier seg om en introduksjon til tema med inspirasjon og grunnleggende konsepter. Kanskje litt historikk. Andre samtale på 30 minutter er dine favoritteksempler. Som hjelper folk å huske hvordan dette funker, egentlig. Folk husker heller eksempler. Tredje samtale dreier seg om verktøykassen. Da begynner vi å gi dem noen metoder, kanskje noen teknologier som de kan bruke etter hvert, for å anvende noe av den teorien de har hørt om. Og eksemplene. Det siste et lite verksted hvor vi prøver oss gjennom; hvis vi skulle anvende LEAN på et et lite SMB selskap. Vi kan bruke LØRN som utgangspunkt. “Hvordan ville det sett ut?”. Høres det greit ut?

Signe Marie: Yes. Det høres bra ut det.

Silvija: Veldig bra. Før det så starter vi alltid, før selve den faglige samtalen, med en liten personlig samtale. Vil du fortelle oss hvem er Sigma? Og hvorfor bryr hun seg om lean og agile? Og om i det hele tatt nye ledelsesmodeller?

Signe Marie: Ja, først kan jeg jo starte med å forklare navnet Sigma. Det fikk jeg jo veldig raskt på Universitetet i Oslo, med Silvija. Da vi studerte realfag og sånne ting. Så da ble Signe Marie til Sigma ganske fort. Så mange kjenner meg kun under det navnet, men mange også som Signe Marie. Da blir det begge deler. Og jeg har hele tiden siktet inn på informatikk som hovedfag. Da tok jeg også pensum og holdt kurs hele veien. Jeg aar vært veldig engasjert for “best practise-rammeverk” og har jobbet mye med ITIL rammeverket, som er et best praktisk rammeverk som er brukt over absolutt hele verden. Med sertifiseringer som en utrolig god basis, da for rike organisasjoner for å kunne lære av hverandre med beste praksis. Det handler jo mye om prosesser og tjenester av så gode IT-tjenester som virkelig leverer hva kunden ønsker seg. Og så hadde jeg jobbet veldig lenge med dette rammeverket før jeg tok mitt eget LEAN-kurs. Det var vel rundt 2007 eller noe sånt. Mens jeg hold mitt første kurs i 99 eller noe. Nå begynner det å bli lenge i branjen, Silvija. Lean, det kommer jo fra Toyota. Det er ikke nytt dette heller. Men det ser på det med å skape verdi på en helt annen måte. Den definerer verdistrømmer og ser utfra verdien som genereres: Hvordan kan vi skape den uten at verdiskapingen stopper opp i organisasjonen? Fjerne “waiste”. Når du fokuserer på fra kundens behov til noe verdi er skapt. Og det var det Toyota virkelig fikk til. De skapte sitt eget produksjonssystem med fokus på den flyten. Istedenfor fokus på siloer og ressurser, som som vi gjør her veldig ofte, og som vi har lang tradisjon for. Med det i bagasjen, lean og verktøyene i lean. Også hele kulturen, som preger et sånt miljø hvor vi hele tiden fokuserer på kundebehov. Så begynte jeg å bli mye mer i stand til å hjelpe organisasjoner å forbedre seg. Denne “passion” kommer jo fra det at du virkelig kan skape endring og skape så store forbedringer som du kan med disse verktøyene. Det er dette med agile og DevOps som jeg nå jobber veldig mye med. Det er jo å bruke lean på utviklingsprosessen, altså software-utvikling.

Silvija: Vi kommer tilbake til om det bare er software-utvikling eller også organisasjonsutvikling og generell strategi.

Signe Marie: Ja. Det er jo mye rundt dette begrepet her, med kultur og ledelse og organisasjonsstrategi?

Silvija: Nå skal jeg fortelle deg noe, Sigma. Og så skal jeg spørre deg litt, et litt sånn personlig eksempel på en hobby du har også, til slutt. Det er i 20+ år siden vår tid på Institutt for informatikk og etter hvert også diverse doktorgrader og så videre. Jeg har skammet meg over å være på den teoretiske siden av databehandling. Jeg har jobbet veldig mye med algoritmer og det har tatt meg 20 år å skjønne at det å forstå kompleksitet og store oppskaleringsproblemer som vi lærte da innenfor informatikk, og hvilke metoder du bruker for å få de programmene til å funke, men også de programmene til å tilpasse seg. Problemendringsbildet, ikke sant? Det er noe av det viktigste man trenger nå, for å forstå dette ekstreme komplekse samfunnet i stor dynamikk som vi lever i nå. Det å forstå kompleksitet, det å forstå strukturer og det å forstå mekanismer som fungerer på toppen av de strukturene. Det tror jeg vi har som en gave fra softwareutvikling, men jeg tror det har blitt relevant for samfunnsutvikling og organisasjonsutvikling nå.

Signe Marie: Ja, du får meg til å tenke på to ting der. Det er klart at også virkeligheten vår blir stadig mer kompleks, for den endrer seg også stadig raskere. Både når det gjelder alle utfordringene verden står overfor, og endringer i marked og endringer i metoder. Jeg tror det vi snakker om i dag med Agile leadership, og det å bruke lean tankegang, det er faktisk en måte å bryte ned kompleksitet på. For det trenger vi. Du vet, når vi skal lage IT systemer som skal støtte hvordan vi jobber, i en kompleks hierarkisk organisasjon hvor alle bokser i hierarkiet har sine krav til hva dette IT-systemet skal levere. Det er en som heter Conway som lagde en lov som sa at IT-systemet blir like komplekse som den organisasjonen de skal støtte. Det blir å nedtrekksmenyen med hundre menyvalg for det du skal tilpasse deg alle disse ulike behovene. Og det vi gjør med lean tankegang. Det er egentlig å se på tvers av siloene og bryte ned siloer og se på: hva er det kunden egentlig har behov for? Og nå går dette med softwareutvikling mye mere i mot en strategi hvor det er mer en app-mentalitet. At du finner ut for en kunde eller kundegruppe, hva er det akkurat de trenger som kan gjøre dem begeistret. De får jobbene sine gjort ved hjelp av akkurat denne appen. Ikke sant? I steden for å lage kompleks ting, så skal støtte alt.

Silvija: Forstå organisasjonen før de får brukt systemet.

Signe Marie: Ja.

Silvija: Jeg er helt enig. Men du, vi kommer tilbake til Conway og tankegangen rundt lean. Men jeg har lyst å spørre deg, for å balansere all den kompleksiteten som kommer fra den digitale siden av livene våre. Så holder du på med flere hobbyer, blant annet folkedans, hvor du har fått meg til å danse folkedans på 17. mai. Det er min favoritt del av 17. mai feiring og folkedrakter. Og så lager du opera av og til, for studenter eller. Eller Operaball til og med.

Signe Marie: Ja, Operaball. Det er jo lenge siden at jeg var sånn aktiv med dette her, men i studietiden så laget vi jo en egen studie eller studentforening som vi kalte Tårnseilerne. For det at vi var en gjeng som tenkte at vi skulle lage arrangementer så store at det dette med tårnseilerne. Det er en fugl som bare kan kaste seg ut for store høyder. Så det er liksom bare å gå for drømmen. Og vi skapte Opera Ball, som vi i mange, mange år samlet åtte hundre studenter, ikke bare til en kveld hvor de så opera og hadde ball etterpå, men hele måneden på forhånd så hadde vi dansekurs og maskekurs og kurs i kotyme fra, for eksempelvis Operaen var 1700-tallet. Vi hadde sykurs i linkjoler. Ja, sa det tok helt av. Og så ble vi så god på det at vi også måtte lage litt flere arrangementer. Så vi hadde jo Dovregubbens hall med store promenadekonserter. Og ja. Det var en helt fantastisk gjeng, og vi holder jo sammen, fortsatt. Vi skal blant annet på Opera galskap i morgen med Eir Inderhaug, som var en av disse som vi fikk med på Dovregubbens hall og Promenadekonsert. Da hun fortsatt var ukjent. Det var kjempespennende tider. Jeg var vel med å arrangerte dette er i hvert fall i 15-20 år.

Silvija: Det var utrolig kule ting, Sigma. Jeg husker at jeg har sydd en kjole i mitt liv, og det var min ballkjole på Operaballet som var basert på traviata. Da hadde vi noen sånne italienske 1700-tallsmodeller som vi skulle etterape, og kjolen holdt til akkurat din ene aften. Men det var en helt vanvittig flott aften, med fakler fra gamle operaen i gamle losjen og dans hele natta.

Signe Marie: Ja, og intimkonserter i alle salene med deg i den gamle losen med kor konserter. Ja, det er magisk. Du vet det skal være i februar igjen? Ja, det er noen av våre arvtagere som har tatt dette videre, så det kjører fortsatt.

Silvija: Det er absolutt et veldig godt sunnhetstegn at det lever videre etter dere. Det er fantastisk. Du sa du har vært fascinert av best practice hele tiden, så hvis jeg drar dette her nå over og tilbake til agile og lean. Mitt første spørsmål er at jeg blander de to begrepene, agile og lean. Og så blandede vel, egentlig littegrann med best practice også. Kan du hjelpe oss å rydde opp i de tre begrepene først?

Signe Marie: Ja, skal ta det siste først? Best practise. Det er jo å finne ut: Hva er det de som virkelig får til gode resultater? Hva konkret er det de gjør? Hva kan vi lære av det? Og hvis vi da går over til lean. For der hadde de jo masse beste praksis. Det som var med lean kom jo fra Toyota, men de brukte ikke begrepet lean. De hadde krav på seg i etterkrigstiden om at for å produsere biler, så var de nødt til å tenke annerledes. Fordi de hadde ikke råd til store lagre som Ford, for å produsere for lager og så vente på at kanskje kommer det kunder. De fant en ny måte å jobbe på hvor de først sjekket ut: hva er det kunden har behov for? Og så modellerte de verdistrømmen, som de kaller det, fra kundebehov oppstår, til den er levert. Og så fokuserte de så mye på den verdistrømmen. At de optimaliserte hvert eneste sted, det som vi kaller flytenheten. I Toyotas perspektiv så var det biler som ble produsert. Så i flytenheten, hver gang det stoppet opp. Hver gang det ble en og feil, så lærte de opp hele staben sin til å si at: da må vi si ifra. De hadde noe slik som at de kunne dra i en snor i taket, stoppe hele produksjonen, for å rette feil sånn at det ikke forplantet seg ut til kunden. Så dette fokuset på verdistrøm og flyt. Og flere andre ting med hele kulturen. For å få dette her til. Dette kaller jo de Toyota produksjonssystem. Men dette skapte så stor kvalitet på bilene, at det på 1990-tallet at forskere… De dro vel litt før, men de forsket på hva i all verden er det de gjør? De forskerne som da hadde forsket på dem. De brukte navnet lean når de ga ut bøker for å forklare hva det er Toyota gjorde. Så kom bøkene som “the machine that changed the world” og bøker som definerte lean som konsept. Dette var jo i 90 og 96. Og agile, hvis jeg bare tar jeg overgangen til det. Disse konsertene, den tankegangen med flyt og Verdistrømmer. Den ble nok da adoptert av en del så endel software-utviklere som virker skjønte dette konseptet. Og de stod jo i som et typisk fossefall prosjekter når de skapte software, hvor alle kravene kom inn i starten. Og så ble de satt i et år inn i et rom, og så skulle de levere noe produksjonsstøtte på slutten av året. Hvordan kan vi tenke annerledes? Og på en hyttetur på Utah i 2001 kom en del softwareutviklere sammen og skapte “the agile Manifesto”. Det er samme tankesett. Dette lean og verdistrøm tankesettet: Hvordan kan vi bryte ned software til små biter, funksjonalitet som kan være flyt enheter, akkurat som bilene. Flytenheten gjennom en verdi strøm, sånn at vi først sjekker at dette her er kravet, og så får vi det igjennom og produksjonssetter. I en stund klarte de ikke å produksjonssette, men de klarte det etter hvert. Og så sjekke med brukeren at: er dette det du faktisk ønsket å ha? Og da med fokus på å optimalisere denne verdistrømmen innen softwareutvikling. Så har de også brukt lean tankegangen og lean verktøy i softwareutvikling.

Silvija: Jeg har mange spørsmål her som jeg lyst å be deg om å hjelpe meg med å forstå bedre. Det jeg tenker, når du snakket om fossefallsmetoden. Tanken der er at du deler programmet, kanskje i noen phases eller faser, ikke sant? At du deler produksjonen din. Men så er det sånn at det er veldig lite tilbakekoblinger. Så du gjør ferdig dette, og så går det over til neste fase, og neste fasen får bare forholde seg til det det her. Vannet flyter ikke oppover i fossen bærer nedover, og derfor er det ikke en spesielt lærende prosess. Det Toyota fikk til med denne her end and cord var å liksom kunne melde tilbake så man rensket opp vannkvaliteten lenger opp i fossen. Sånn at man fikk noe form for filtre og informasjon, men det fløt litt mer resirkulerte dem med mere lærende prosess og mindre konserverende.

Signe Marie: I fossefall så har du… Hvis du tenker flytenheten der? Da har du en kjempelang liste med krav på fem hundre ting. Og så skal hele den flyte samtidig ned fossen. At ja, vi lager først alt av software moduler, og så begynner vi å tenke på det tekniske. Og til slutt så skal vi teste ting som er laget for et halvt år siden, og du har ikke noen flyteenhet som er lett å få igjennom for å få raske tilbakemeldinger. Du får ikke tilbakemeldinger før det er gått et år, og da er kompleksiteten så stor at du aner ikke hvem som utviklet denne modulen eller hva som er egentlig feil. Jo mer vi tenker over disse fossefall prosjektene, jo, mer utrolig er det at noen av dem har lykkes. Det er ganske komplekst.

Silvija: Ja. Husker du Bjørn Kirkerud og Simula kursene våre? Simula er en innovasjon fra Norge som jeg her egentlig glemte å snakke om i de siste årene, men verdens første objektorientert programmeringsspråk. Utrolig viktig og flott innovasjon. Og det han prøvde å få oss til å sammen med Ole Johan Dahl og kristne i går, som var et hovedmål til mødrene til prosjektet. Dette konseptet med at programmene blir så fort, så veldig komplekse, at du til slutt ikke kan navigere dem. At det var et sånt ordtak, at “enten kan programmet ditt være så komplekst at det er ingen opplagte feil, eller så kan det være så enkelt at det opplagt ingen feil”. Det er sånn at det det å bryte ned de store tingene inn i mye mindre ting som lever et slags uavhengig liv, som er håndterbare, er det også noe som har med lean og agile å gjøre?

Signe Marie: Det er nettopp det, for at da får du hver håndterbare funksjonalitet. Den lager du, og så ferdigstiller du den. Helt fra behovet blir klarlagt: er det dette virkelig brukeren trenger?, og så sendes det inn til et agilt software-team som for eksempel utvikle ved hjelp av oss, og så bruke Scrum metodikk. Og da har de en product owner som sørger for ja: Dette er nå den prioriterte funksjonalitet som dere skal sette i gang med i neste sprint, og så jobber de for eksempel i to uker slåtter. Og så har de en liste fra product backlog for hvert lag som blir da satt inn i sprint. For hvert lag er bare kun de funksjonaliteten som er viktigst de skal fokusere på. Og så tar de tak i én og én ting av det, og ferdigstiller. Og så får de feedback fra kunde det med en gang: Er det dette her du ønsket deg? “Ser dette bra ut”, og da får du læring. Og på den måten så kan de for det første skape verdi langt raskere for det at det blir litt og litt ferdig. Så verdiskapningen, den venter ikke helt til slutt. I fossefallsprosjektene var vi jo kjempespent: Hva i all verden blir dette nye produktet som lanseres på første desember, nå har de holdt på i et år? Ikke sant? Ingen hadde sett det før da. Mens når det er Agilt så får du hele tiden sett litt og litt funksjonalitet. Og så får du sagt “Yes dette ser bra ut”, og da blir du også langt bedre til å lære. Du kan ta feedback og du kan se: “Okei, dette her funket ikke”. “Vi må ta det tilbake”, og vi kan respondere med endrede kundebehov.

Silvija: Du snakker da om tilbakekoblinger. Du snakker om denne moduleriteten, hvor du bryter det ned i håndterbare chunks, størrelser. Du snakker også om å begrense avhengigheten. Morgan Når det er en stor bolle spaghetti, så er det kjempevanskelig å endre. Du river liksom i ett strå på den ene siden i et drag i en spaghetti på den ene siden så blir det bare kaos hele veien igjennom. Det blir veldig skjøre, veldig forsteinede systemer.

Signe Marie: Ja, og det er vanskelig å respondere på endring. For, gjør du endring ett sted, så kan det få konsekvenser alle andre steder. Og du vet ikke helt hvor. Så det å seg heller minske avhengigheter og sørge for at du skaper ekte verdi. At du har en fin veksling. Jeg studerte kybernetikk tok det som hovedfag. Noe av det som gjør at…

Silvija: Systemteori, ikke sant?

Signe Marie: Ja. Dette å gå raskt. Jeg skal finne ut: hvordan kan jeg få god og høy kvalitet på tilbakemeldinger, raskest mulig, sånn at jeg kan gjøre endringer?

Silvija: Ja, og det du bygger da er et slags Legosystem da, om du vil. Hvor du kan lett dunke eller endre farge på en av blokkene, eller forbedre en av blokkene uten at hele systemet må forkastes.Og så har jeg lyst å spørre deg. Det høres egentlig veldig flott ut i teorien, men i praksis det å bryte ned en kompleks problemstilling i et sett med mindre problemstillinger. Det å virkelig forstå problemet, det er jo det som er så utrolig vanskelig. Så hvordan kommer man i gang?

Signe Marie: Du kan si det er vanskelig, men det er jo også helt essensielt. Hvis du ser alternativet med fossefall, så er den metodikken hvert fall ikke noe bedre. Når du tror du kan gå, snakke med alle ulike avdelinger og få inn alle type krav, og så prøve at noen gruppe setter seg å sortere kravene i “shall have”, “must have” og “should gave”. Så skal man overlevere det til en annen gruppe som skal tolke disse behovene på sin måte. Og så tar det kjempelangt tid før du får feedback fra noen. Så i agile-software-utvikling er alt avhengig av at du har de riktige personene med i teamet, og at du har kunder som virkelig ønsker dette nye produkte,t som kan si noe om behovet. Skal du lage et IT verktøy som støtter leger og sykepleiere på et sykehus, så må du for all del ha ekte folk å snakke med, som kan gi tilbakemelding på: Er det dette vi trenger? Det er jo noe av kunsten.

Silvija: Men finnes det noe regler da. For hva som er håndterbart? Hvor store skal disse komponentene være?

Signe Marie: Jeg tror hvert software-team finner sin egen praksis, og av og til så prøver de å estimere: Hvor stor er denne jobben? For det er ikke alltid man klarer å estimere det på forhånd, eller når det er et krav. Hvor mye koding trenger vi for å få det til? Kanskje det dukker opp flere ting. Det kan være noe så enkelt som å lage en knapp, eller det kan være mer avanserte ting. Og så er det nå at de lærer også. Etter hvert som de jobber på denne måten, så lærer de å bli bedre og bedre på å bryte ned i håndterbare enheter som skal utvikles. Over tid blir de dikte oss dyktig og se på estimere omtrent hvor mye klarer vi på disse to ukene. Det kommer av erfaring i måten å jobbe på det.

Silvija: Det jeg vil til Sigma er at vi snakker om folk som lager software her. Jeg tror at denne metodikken er like verdifull for folk som lager tjenester, som involverer mennesker, eller jeg så hvilken som helst organisasjon som skal gå fra sånne store monolittiske siloer. Som styres med treårs strategier til mere disse selvstyrte tverrfaglige team som leverer på oppgaver. Og det du sier er at dette her er ikke bare outside-in, ikke bare mere modulert, ikke bare mere tilbakekobling og lærene, produksjonsmål metode. Men det er rett og slett en mer fleksibel måte å organisere seg på, og det må ledes på en annen måte også. Forstår jeg deg riktig?

Signe Marie: Ja, der har du jo noe essensen i dette her. Når du sier at det du forstår at dette her kan det jo brukes på alle andre områder, og at det har med ledelse å gjøre, og en helt ny måte å jobbe på. Der kommer vi inn på essensen med. Ja, agil ledelse og mere smidig organisasjoner. Dette er jo konsepter fra lean som er brukt i fabrikker. Og så har vi brukt det innenfor softwareutvikling og DevOps. Men, Silvija, min største bekymring med dette her. DevOps, det er jo noe som gjør at de kan lansere programvare to.tre hundre ganger mange, kanskje flere hundre ganger raskere enn andre organisasjoner. De kan lansere programvare mye raskere, og så går det sjeldnere feil. Enn i tradisjonelle organisasjoner. Og når det går feil, så klarer de å rette det opp to tusen ganger raskere, fordi at da vet de jo hva som har skjedd. Det er et team som følger med på sine features, som de lanserer ut og ser om noe går feil. Og så tar de tak i det med en gang. Men hva skjer når vi får sånne softwarefabrikker, hvis ikke virksomhetene også omstiller seg til en slik hastighet å jobbe i? Hvis ledere på virksomhets nivå skal fortsette og sitte med veldig firkanta måter å jobbe på, og du må ha autorisasjon for alt mulig og holde kontroll. Alt av forskning hittil på DevOps viser at det må en helt annen type ledelse til for å lykkes.

Silvija: Vi kommer tilbake til eksempler på det vi snakker om nå. Litt av målet vi i LØRN har med noen av disse her kursene er å gi folk et slags nytt vokabular. Og å bløffe litt rundt Agile, om ikke annet. Så vi har snakket om best praksis. Vi har snakket om lean. Vi har snakket om Agilel. Og så har du underveis nevnt flere ting, scrum, DevOps og design thinking. Jeg tenker du kanskje kan hjelpe oss å forstå hva de tre tingene betyr, før vi avslutter denne første seansen?

Signe Marie: Yes, hvilken skal jeg starte med? Scrum! Så, da Agile manifesto kom skjønte vi at “Åja, vi må jobbe litt annerledes. Vi må jobbe mer agile”. Så ble det raskt adoptert av en rekke organisasjoner og det som ble best praktisk måte å jobbe med agility på, for softwareutviklere. Den metodikken er kalt Scrum. Den er en veldig enkel metode å forklare, men ganske vanskelig å etterleve. Og forklaringen det er at det er egentlig bare tre roller. Du har en “product owner”, som hele tiden har kontakt med kunden for å spesifisere disse kravene som skal være i produktet. Og så har du teamet, som er, ja, kanskje fem personer. Ikke for stor gruppe, fem seks stykker. De jobber i sprinter på cirka to tre uker fast, hele tiden. Det er en del av scrum metodikken, og de har et møte med “product owner” for å finne ut hva er det vi skal jobbe på i neste sprint? Og så bruker de, så tar de en ting derfra og passer på å få det ferdigstilt. De har begrensning på hvor mye arbeid de skal ha på en gang, slik at de slipper multitasking og heller fokuser på ferdigstilling. Og så demonstrerer de for kundene ved slutten av hver sprint. Det gjerne en Agile coach eller scrum master som hjelper dem med metodikken. De hjelper med det menneske fokuserte, måte å jobbe på, hjelper dem kanskje med å kjøre retrospekt på slutten av hver sprint. Det med: hvordan funket teamarbeid vårt? Målet for scrum master er å gjøre dette teamet mest mulig selvstyrt, så etter hvert så kan det bli mindre og mindre å gjøre for Scrum master, slik at man kan være coach for flere scrum team.

Silvija: Kan bare spørre deg om noe her? Det er to ting jeg sitter å tenke på nå. Jeg husker min første jobb i Fast. Det var min første jobb i mote, privat næringsliv. Jeg var veldig mye akademia og forskning før det. Jeg hadde fått et veldig bra råd av min sjef, og jeg lurte på liksom hvordan jeg skulle angripe alt. Jeg fikk i oppgave å lage “best practices” for søk innen informasjons lønnssystemer, og det hadde vi leverte. Vi skulle dokumentere og hjelpe våre kunder med å jobbe ut ifra en som best practise metodikk. Og så sa han veldig tidlig at: SIlvija. I stedet for å koke havet er det veldig viktig at du har noen suksesshistorier, relativ tidlig”. Som jeg da kan bygge på og lære fra. Jeg tror han var min scrum coach. Det andre som jeg har lyst å nevne er at når jeg hører deg snakke om disse scrum teams. Det ene er at det det skjer såpass nært at alle må skynde seg. Og alle vet hva de skal gjøre. Og det skal skje relativt snart. Av og til når oppgaven er så stor. Så bruker meg en litt på lang tid å komme i gang, å finne retning. Men det er også lettere kan skje å holde hverandre ansvarlig og så at vi vet nøyaktig hva de andre skal gjøre, og at det ligger en sanne team dynamikk hvor du skal levere. Men de andre skal også levere.

Signe Marie: Mhm. Det er klart det. Vi har nå som team felles mål, og vi har klart for oss hva det er vi skal lage denne sprinten. For det sjekker vi ut og stille spørsmål ved med “product owner”. Også dette med å skynde seg. Det er egentlig litt motsatt. Vi vil heller at det skal bli jobb i en “steady pace”. Hvis det blir hastverksarbeid, så blir det jo feil som forplanter seg til dyre ting vi må rette opp når produktet er lansert senere. Så det å se faktiske jobbe i et tempo som er komfortabelt for dette teamet og bygge teamet til å bli sånn ja, gjensidig avhengig av hverandre. De har massevis at practises. For eksempel. Hver gang jeg er ferdig med kode, så har jeg en av mine kolleger til å gjøre en review, som blir å sjekker hverandres ting, ikke sant? Og vi har fokus på hvordan kan vi forbedre måten vi jobb på i temaet? Hvordan kan vi trives enda bedre? Og så får de jo kontakt med kundene. Hver gang de har en demonstrasjon for kunder, hvis de gjør dette er riktig, som er det veldig viktig å god bygge god relasjon til disse kundene. Da kan du få feedback med kvalitet. Og hvis du ikke har sånne scrum løsninger blir det jo som å kjøre en kontroll uten kontrollfunksjon. Da kan det gå i feil retning, som er helt essensiell.

Silvija: Men du, utrolig fint å høre på deg. Hvis vi tar DevOps veldig kort. Og design thinking. Så skal vi snakke mer om hvordan de ser ut, på kundeeksempler. Ok?

Signe Marie: Ja, så veldig kort om DevOps. Agile. Altså den måten å jobbe på, med scrum metodikk. Det ble jo mer og mer populært å jobbe sånn. Med beste praksis. Det ble noe som et hvert de fleste organisasjoner skjønte at det var langt bedre enn fossefall. Men så fikk de ferdigstilt programvare i utviklingsmiljø, og så kommer det til drift. Hva skjer da, Silvia? Når du kommer dit? Jeg skal gjerne ha satt noe i drift i dag. Hva sier driftsavdelingen da?

Silvija: Da sier de “kom tilbake om tre uker når jeg har tid”.

Signe Marie: Ja, og så sier de: “Dette er stor risiko”. Og “dessuten så må vi ha kamp møte på torsdag neste uke”. “Send inn forslaget”. Det har vært ganske rigid før du får produksjonssatt noen ting i sånne tradisjonelle i tre miljøer fordi at kompleksiteten i infrastrukturen på serverrommet har også vært enorm. Bare en liten endring, ett sted, kan gjøre at andre tjenester går ned. Og det har jeg jo erfart selv, da jeg startet på Veritas. Da hadde jeg ansvar for ni webservere, og alle var satt opp forskjellig. Og en servet intranettet, en servet det internett på utsiden. Hvis jeg skal kjøre en patch på ett sted, og det funker der, så ville ikke det være det samme som at det funker på den andre maskinen. Den kunne plutselig gå ned, og da alt var så komplisert. Og det som har skjedd med DevOps, sammen med Cloud Computing, og en hel masse teknologiske konserter da. Dette startet egentlig med en frustrert softwareutvikler, han heter Patrick Bubba og kom fra Belgia. Han jobbet med Scrum så lenge. Det er en frustrasjonen med å ikke få produksjonen satt, og han ønsket at vi skulle kunne tenke annerledes innenfor drift også. Og så satte han i gang.. Egentlig så han på en konferanse. Der var det satt opp som en rundbordsdiskusjon med Agile Tankegang i drift. Han gikk på den, mer der var det jo ikke noen. For han som hadde kalt inn til denne hadde ikke fått noen respons. Dette var vel i 2007 eller noe. Så klarte han å lete opp han som kalte inn. De pratet om dette, om det å få inn mer Agilt i hvordan drifter på. I starten så var det lite interesse rundt det, men så var det vel et som foredrag som Flicker holdt, tror jeg. Det var en Agile konferanse hvor Flicker hadde et foredrag hvor de virkelig spilte ut rollene mellom utvikling og drift, hvordan utvikling kommer inn og endring og så videre. Det var to stykker som holdt dette foredraget. Det ligger på YouTube fortsatt, så du kan finne det. De satt i Scene dette, hvor dette utviklerne ville puste deg ut og drift sitter der og sier stopp. “Dette må vi ha mere fokus på”. Og så begynte, så satte de i gang…De kalte sammen både utviklere og driftsfolk til noe av det som de kalte da “The DevOps stays”. For å få mere fokus på: hva kan vi gjøre for å få software helt ut i produksjonen? Dette var i 2009-2010. Det har jo gått en del år siden. Det har skjedd enormt mye på dette. Hvor leverandører”