Hei, og velkommen til Plattformpodden, en podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg som vanlig Audun Faukastrand. Og i dag har Plattformpodden blitt tatt over av Benedicte Fjellanger, for å snakke mer om hvordan plattformteam jobber sammen. Benedicte, hvem er du, og hvorfor har du tatt over podkasten vår i dag? Tusen takk for at jeg får lov å være her. Benedicte jobber i Team Agile. Vi er et konsulentselskap. Vi sier ofte at vi er en konsulentbod, for vi er så små. Vi er fire ansatte i dag. Men vi har laget et selskap som handler om team. Og team som akselererer verdiskapingen.
Det ligger egentlig i teamutvikling, lederutvikling, teamorganisering, produkttransformasjon. Digital transformasjon er paraplyene vi jobber innenfor. Hvor teamet er sentralt. Så da plattformpodden kom, så var jeg kjempenysgjerrig, nettopp fordi dere sier at dere snakker med plattformteam og snakker om plattformer. Men det er lite fokus på teamene som bygger plattformene. Så til slutt skrev jeg en melding og sa: "Dette må vi jo snakke om!" Jeg er så nysgjerrig på å høre mer om plattformteamene, hvordan egentlig dere bygger og utvikler de. Så det var litt av bakgrunnen for at jeg tok kontakt.
Og jeg kjenner jo til Nav, har vært noen år som konsulent her for noen år siden. I dag jobber vi mest med private selskaper som også forsøker å bruke team til å drive utvikling og verdiskapingen fremover. Så dette er kjempegøy. Dette er jo mitt favorittområde å snakke om, og her har vi noe til felles. Jeg håper i dag. Så vi må jo først og fremst ta med lytterne tilbake noen år. For dette er jo en ny podkast, men plattformen har jo levd i noen år. Da tror jeg vi må begynne med deg, Udun. Du som er plattformens oldefar. Oldefar i stadige alle hendelser. En erfaren plattform utvikler og teambygger, da. Hva var grunnen til at dere begynte med et plattformteam?
Det er mange grunner til det. Man må litt tenke tilbake på hvor Nav var. Jeg kom inn i Nav i 2017, og da hadde egentlig Nav jobba med plattformen en god stund. De hadde Eura-plattformen, som ble lagd i forbindelse med et av de mange moderniseringsinitiativene som kom. Jeg tror den starta sånn 2013-14, og den var veldig bra for sin tid. Det var mer sånn web-basert, du gikk inn i forskjellige plattformer for å få deg en. Og det funka fint, men samtidig som Nav gjorde det, så jobba jeg i Finn, og vi hadde egentlig lagd en plattform der. Som var veldig opp mot å få til continuous delivery. Og så fikk Torbjørn og Truls meg til å begynne i Nav,
og da tenkte vi både for å ta Eura-plattformen ut et nytt steg, men også for å klare å skape en driv, bruke plattformen som et verktøy for å vise at i Nav ... I Nav så går det an å lage kjempegode ting, for på den tida så var ikke det så åpenbart at Nav var et sted hvor de ikke kan lage god software. En av grunnene til at vi gjorde det open source, var nettopp det at vi ville vise at det går an å lage god software i Nav. Og så hadde jo Truls mange ganger sagt at problemene for å få til continuous delivery i Nav i starten var egentlig ikke tekniske. Det var teamene og det store rundt der som var det vanskelige.
Men samtidig med å ha fokus på det fra plattformdelen og det å få med seg folk sånn, så klarte vi å snu kulturen med å lage plattform, sånn at det ble mer enkelt og tydelig at her må folk ha tilgang, og folk må kunne deploye selv, og vi må ikke ha de store change-regimene. Og når vi klarte å vise at det var trygt, så begynte ballen å rulle, og da begynte det å gå ganske fort etter hvert. Hvordan så det første teamet der ut? Hvor mange var der, og hvordan organiserte dere? Jeg kom jo inn til en gjeng på fem-seks stykker, tror jeg det var, som hadde jobba med Eura-plattformen lenge.
Satt nede i kjelleren i Sandegata, der Nav hadde kontorer. Og da var det ... Det var ikke så mye organisering. Vi visste sånn omtrent hva vi skulle lage. Så hadde jeg med meg en del bagasje og tanker fra det vi hadde lagd i Finn. Så det likna ganske mye på det i starten. Men da var det veldig lite struktur. Hovedstrukturen var at vi hadde ostedag på onsdager til lunsj, og toastdag på torsdager for å bruke opp overskuddsosten fra ostedag. Det var strukturen. Ellers så var det ikke så mye struktur. Og så begynte vi å vokse, da. Jeg tror vi gikk fra 5 til 10-12-15 i løpet av et par år. Og da begynte omfanget, liksom.
Da måtte man etter hvert begynne å dele opp litt. Da ble det liksom noen som var mer på hardcore-plattform, noen som var mer på sikkerhet, noen som var på utvikleropplevelser og sånn, men det kom først et godt stykke uti. Og den plattformen dere bygget i starten, Nav hadde ikke noe sky i 2016, vel? Nei. Eller vi hadde en internsky. Det var jo Wemer og de to og et halvt datasentrene vi fortsatte. Og på den tida var det veldig uklart om vi kunne bruke allmenn-sky. Så tanken var vel at hvis vi klarte å lage en plattform som i hvert fall relativt enkelt både kunne være on-pram og i sky, så kunne prosessen med å komme seg i sky være én ting.
Og så kunne vi gjøre det at vi gjorde moderniseringa som ga verdi, uavhengig av om vi endte opp i sky eller ikke sky, eller i allmenn-sky eller ikke. Så det var et mål vi hadde, men da visste vi egentlig ikke om det var nåbart. Så viste det seg at det gikk an. Men det tok en god del timer med annen type arbeid enn koding for å få det til å funke. Så da var det en slags parallell virkelighet dere satte opp i starten med dette plattformteamet, som gjorde at dere nettopp sørget for å ... Ha et mål om å kunne kontinuerlig utvikle og produksjonssette ting. Og så etter hvert ... Altså i dag er det jo ikke sånn at det er mange plattformteam. Det er jo et plattformteam som leverer infrastruktur til utviklerne og teamene i Nav.
Eller i Nav-terminologi så er det en klynge, tror jeg det er nå. Vi har områder, produktområder og IT-områder. Og så har vi delt. Hele området rundt plattform er jo mer enn bare Nice nå. Mens Nice som er 20 personer, det er en del av den store plattformgjengen. Men så har de basisplattform og infrastruktur som en annen del av organisasjonen. Men de leverer jo ikke primært til utviklerne lenger. De leverer til de andre plattformteamene i større grad. For det her ser jo jeg et stort problem for virksomheter som ønsker å gå i sky. De fleste bruker sky her og der, men det er egentlig ikke organisert med basis i Team Tapologies,
eller som et plattformteam. Det er egentlig en slags sånn opportunistisk tilnærming til at vi må bruke sky, vi trenger større regnekraft, vi trenger kostnadseffektive, sikre tjenester, og derfor så bruker man sky. Men da møter jo de som bruker sky, ofte de som ikke bruker sky. Og det er jeg veldig spent på. Vil du si litt om hvordan akkurat det møtet var, da du kom inn i Nav, Audun? Ja, altså, mye av ... Det er jo en sånn redsel mot utlandet, egentlig. I skyverdenen, som kanskje spesielt i Nav, er det ... Spesielt da, så grunnen til at vi ikke var sikre, var jo at det ikke var tydelig
om vi egentlig hadde lov. Og så har det vært gjort veldig mye godt juridisk arbeid, som har kommet fram til et fundament for hvordan det er greit for Nav å bruke amerikanskeid sky. I Europa. Og så regner vi jo med at hvis det blir datasentre i Norge som passer med det vi har ellers, så kommer vi til å ta i bruk det. Og jeg så på god gammeldags TV her om dagen at Google har kjøpt en tomt i Skien som de har tatt bort all skogen på for å bygge datasenter, så da skjer vel det en gang eller to. Men det juridiske var en lang prosess som egentlig handla mest om å bli enige, og vi har fått klarhet om de forskjellige ... Hva sier loven, hva sier teknologien, og hvordan kan vi få det til å funke sammen?
Men det var to parallelle virkeligheter en stund? Ja, Nav har fortsatt en omprømmeoperasjon, som er ikke ubetydelig, både på moderne applikasjoner, men også på mye av støttetjenestene. Men vi jobber jo med å komme oss videre der òg. Så det var ganske uorganisert, det var osteonsdag? Ja, ostdag! Vi var veldig effektive i navngivninga. Så derfra og frem til i dag så har det jo rent en del vann i elven, da. Og du er ikke lenger "i nice time", Audun? Nei. Da kommer vi til den vanskeligste delen, at jeg skal prøve å forklare hva jeg driver med til vanlig.
Men hvis vi kan si "jeg er ikke lenger i nice time", så er det en enkel vei ut av det. Det blir så mye spørsmål i ettertid hvis Audun liksom skal begynne ... Nei, så jeg jobber ikke "i nice time" operativt lenger. Jeg jobber med veldig mye forskjellige ting. Det som vi kan ta med oss hvis vi skal rette fokuset mot dagens team, det er jo kanskje både struktur og organisering. Og målgruppen til nice-teamet i dag, hvordan ser det ut i dag, Hans Kristian? I dag, det ... det er fortsatt veldig mye likheter med det nice-teamet som Audun forklarer. Det er en gjeng med ... Veldig med dyktige folk som er veldig selvgående i all stor grad.
Og så har det vært prøvd å liksom shape det opp i forskjellige former og varianter. Og så går det litt sånn tilbake igjen til at det er folk med god selvdisiplin som får ting gjort, da. Og at det ikke alltid trengs så veldig mye ytre rammer rundt det. Men nå i den siste interasjonen har vi tatt i bruk noe som heter shapeup, som er noe fra 37 Signals og Base Camps. David Heimer-Hansen som har skrevet dette. Og egentlig en oppgavestyring på litt sånn høyt nivå. Og du har noen initiativer og en initiativperiode som går ... Eller en fokusperiode, er det vel. Som går over seks uker, hvor man da jobber som regel i par. På én eller to oppgaver, avhengig av hvor store de er.
Før det er da et to ukers cool-down, hvor man kan ta alt annet forefallende. Og så er det en sånn uskreven regel at ting som er av mindre grad, altså bare snakk om timer inntil én til to dager, det må vi bare ta. Get stuffed on. Og det er ikke sånn at vi kan utsette alle disse små oppgavene i seks uker. Vi har tross alt en plattform med aldri så mange team, utviklere, applikasjoner, som kjører på den. Det er førstepri. Den må være oppe. Men så må vi ha fokus på å komme oss videre og den retningen der. Så det er jo våre eminente tech-leads, Frode Jonny, som har vært på podkasten før, samt vår eminente produktleder, Frode-Johnny, som har vært på podkasten før, Vi har nevnte produktleder Thea, som er i front på den skuta der, for å si det sånn.
Og så har vi da etablert et sett med ankere, eller underproduktdirektører. Så vi har et mer formelt, et forankret ansvar for de ulike kontoene. Forankret ansvar for de ulike komponentene i Nice-plattformen, hvor vi har delt alt opp, eller mappet alt opp. I en stor plattform er det mye enkeltkomponenter som er satt sammen. Så er de gruppert litt, og så er det satt en merkelapp om at du har et overordnet ansvar, at ikke det her faller mellom to stoler. Det er i størst mulig grad å sørge for at det day-to-day av ting her blir gjort, ikke nødvendigvis at det skal være den, som gjør alle oppgavene.
Som regel er det jo en person som har mye egen interesse og kompetanse, kunnskap og energi for det området, men også være den som driver initiativet, altså som skriver pitches eller initiativer for å ta dette her videre. Jeg har ansvar for Observability-delen i Nice-plattformen, som er jo da monitorering, alarmering, loginfrastruktur osv., sørge for at vi har en helhetlig historie rundt det, og sørge for at det er naturlig progresjon i den delen òg, på lik linje med resten av plattformen. Vi er ganske ferskt inn i denne siste iterasjonen på organisering,
så det er veldig spennende å se hvordan dette går. Så langt er vi veldig happy og har god driv, og at dette vil nok hjelpe oss og sørge for at vi har en litt mer helhetlig retning. Så jeg er i utgangspunktet veldig positiv til det. Men i bunn og grunn så har du en gjeng med veldig senior utvikla kompetanse, og det er viktig å ta med at dette er et veldig utvikla tungt team. De aller fleste har utvikla bakgrunn, og de aller fleste, eller egentlig alle, er seniorer og veldig selvgående sånn sett. Det er litt spesielt team på mange måter. I hvert fall i Nav-kontekst er det ikke veldig mange andre av den type team. Det jeg også har tenkt på som en av fordelene med Plattformteam,
er at verktøyene når man bruker programmering, er det samme om man lager applikasjoner, som er brukerne, eller om man lager plattform, som er tilbyderen. En ganske naturlig vei er jo å være applikasjonsutvikler en stund, og så bruke den erfaringa du har da. Og så har du på en måte en ganske god magefølelse på hva som skal til for å lage en god plattform. Det er åpenbart en stor styrke. Det kan selvfølgelig være en viss fare for at man blir for baktung og ikke klarer å tenke på ... Men brukerne som vi har nå, har kanskje ikke de samme problemene
som jeg hadde under den forrige jobben min for fem år siden. Så kanskje det er lurt å også snakke med brukeren. Men det er i hvert fall mye tettere på, så det er ganske stor ... Du kan ta mye fra egen erfaring også når du lager plattform. Det syns i hvert fall jeg er en av de store fordelene med å lage plattform. Brukerne er folk som er ganske like deg selv, og det er mye av egen erfaring som kan brukes. Og det er jo kjempespennende å høre om dere kan dele litt mer av det, for du kalte det initiativer eller pitches, som høres ut som prioriteringen til teamet,
som går over en litt lengre periode. Ja. Så det er jo det at det er kanskje en ... Det er større enn en Jere-artikkel, men kanskje litt mindre enn en epic. Jeg vet ikke hva som ... Hvor man da prøver å skissere opp et løsningsforslag. Begynner med en problemstilling og hva er den skisserte løsningen her? Og så har vi en RFC request for comment-periode, hvor man får tilbakemeldinger fra hele teamet før den pitchen blir formalisert. Så er det en slags prioriteringsjobb som gjøres av tech-leadene og produktleder, med å mappe opp hvilke av disse pitchene. Og initiativene skal vi gjøre i denne perioden her, og navn på dem.
Og så vil det gjøres i samråd med de respektive teammedlemmene. Men det er en litt ny måte å jobbe på, hvor man tidligere har vært veldig sånn: Du logga deg på, og hva skal jeg jobbe i dag? Til at nå er det litt mer forhåndsbestemt. I hvert fall den retningen der. Utfordringen her ... eller ... blir om vi klarer å fylle det opp med disse initiativene, nok initiativer. For det er som sagt mye ting som bare er day-to-day-oppgaver òg, og hvordan den balansen der skal gå. Men foreløpig så er jo det veldig en god ... Jeg tror en god analogi som kanskje noen lyttere er kjent med, er type ADR,
Architectural Decision Record, som gjerne er litt mer sånn i etterkant, som var valget vi tok. Og etter hvert som du lager løsningen, så skriver du også en record som er med som en slags historisk dokumentasjon. Disse initiativene er litt mer up front. Og sånn ser vi for oss at det skal være, og får med nok mulig informasjon der. Men det ferdige resultatet kan se for forskjellig ut. Men da ser jeg at "ok, her møtte vi på ulike uforutsette endelser". Eller at vi fant et bedre løsningsforslag. Så ikke noen automatikk at det nødvendigvis blir tatt med tilbake igjen og oppdatert det initiativet.
For meningen er ikke at det skal være et dokument som skal leve noe mer enn akkurat mens vi jobber med det. Og så skal dokumentasjonen inn i der hvor dokumentasjonen hører hjemme, til syvende og sist. Jeg har jo tenkt at denne prosessen er et resultat av at man blir større. Når man går fra 5 til 25, så tvinger det seg fram noen prosesser. Enten at du må dele opp og lage mindre grupper. Men Nice-gjengen har ikke så lyst på det. Alle har egentlig lyst til å jobbe med alt. Og da må man klare å dele kunnskapen, og gjøre det tilgjengelig for alle. Hva er det som skjer akkurat nå? Og også at noen kan komme med bidrag, og du får kompetansedelingen.
Det tror jeg er veldig bra, at man klarer å lage de prosessene som gjør det transparent i en gruppe på 20-25 mennesker. Hva er det som jobbes med, og hvilke valg har vi tatt? Hvis det er noen som har lyst til å være med, så er det noe du kan lese deg opp på. Det er lettere å være med. Det var litt utgangspunktet her. Vi kommer nettopp ut fra en tidligere organisering hvor vi var mer i grupper, og vi delte opp Nice-teamen. Det var en stor gjeng. Naturlig reaksjon på det er å dele opp Divide and Conquer. Da får du nye siloer, får koordineringsutfordringer, du får FOMO. Tendenser til at "her klikker det seg", eller "disse jobber sammen",
og man vet ikke helt hva som skjer der osv.. Å få en bedre transparens, en mer demokratisk prosess på mange måter i hvordan beslutninger gjøres. Og ser jo egentlig det at enkeltpersoner har sine preferanser på hva de pleier å jobbe med, men det å ha muligheten, at det er naturlig at du kan involvere deg og komme med tilbakemeldinger og vite om hvordan utviklingen er i andre deler av systemet. For det er jo ikke sånn at noen deler av plattformen utvikles helt i vakuum. De har jo mye å si på hverandre. Og valg som tas i én del, kan ha impact i en annen del. Og det å vite om her er det ulike initiativer som går,
at de ikke kolliderer med hverandre. At de mest mulig fungerer sammen. Og selvfølgelig at istedenfor at man skal ha tre team med tre forskjellige retninger, så er vi ett team med mer én retning. Det er tross alt utviklende, Jeg ser på Nice som én plattform, og da er det veldig rart hvis deler av plattformen ikke er optimalisert til å spille godt på lag. Og i større grad også det at det fins andre plattformer i Nav som utviklerne må spille på lag sammen òg, at det ikke blir for mye siloer mellom dem. Men det er en enda større utfordring igjen. Men det er også noe man må se på. Veldig spennende. For det er jo min refleksjon.... Min refleksjon er at plattformen ble bygget av applikasjonsutviklere
som kjente på problemer og som ville fikse de litt lenger opp i elven. Men det kan høres ut som at dere vet litt hva brukerne trenger òg pga. det. Og det er jo noe som de fleste team vi møter òg sliter med, det er jo nettopp å ikke tenke som sånn servitørmodus: Hva skal vi servere brukerne våre i dag? Hvilke problemer er det som er viktigst for brukerne at vi løser nå? Og jobbe med tett læring og involvering sammen med målgruppen. Du kan godt dele litt hvordan dere involverer målgruppen til det som prioriteres på NICE. Det er kanskje den største utfordringen vi har òg.
Når vi har 800 pluss utviklere, eller teknologer, som potensielt er ... Hvordan har vi tilstrekkelig innsikt og bakkekontakt med dem? Dette gjøres jo på veldig mange områder. Det er ikke én løsning for å ta alt her. Det som har desidert hjulpet oss mest, og er det viktigste verktøyet vårt, er at vi har en veldig åpen dialog internt. Vi har én kanal for NICE-plattformen. Der går alle henvendelser og kanaliserer henvendelsene vekk fra private meldinger inn i den åpne kanalen, sånn at alle i teamet er klar over at her er det problemstillinger. De andre teamene kan også være med og si at dette er også en problemstilling vi har, og vi har måttet løse det på denne måten. At begge sider av bordet er mer klar over.
"Ok, det visste jeg ikke om." Som er med inn og prioriterer. Vi har jo hatt veldig god nytte av en produktleder. Nå er jeg direktør for alle plattformene i Nav. Som har gjort en kjempegod jobb. Kom inn mer som en data-science- eller analyst-bakgrunn. Det hjelper veldig godt. Dette er litt numbers game på en måte. Det er å få inn tilbakemeldinger, se hvordan ting blir brukt og hvordan man kan se på bruksmønsteret og hvor vi må videre og hvor det eskorterer. Og ha den dialogen. Nå har vi en ny produktleder som er under oppseiling, Thea. Som vi også har stor tro på at er et viktig moment her.
En som har mye dialog med teamene. Ikke eksklusivt og ikke ... Istedenfor at de andre er i teamet, men som har et mer ansvar for det. Litt sånn formalisert ansvar, og som da kan spørre de rette spørsmålene: "Har dere tenkt på dette?" "Hva med sånn og sånn?" "Her har jeg hørt det og det." "Hva tenker dere om det?" Det var jo det som Gøran var veldig flink til, syns jeg. Var rett og slett å ta opp de problemstillingene der til teamet, spørre de spørsmålene der. Og det vi så var at når plattformteamet fikk tilstrekkelig informasjon, så tok de gode valg, i hvert fall fra mitt perspektiv. Og det er kanskje noe som kjennetegner disse som plattformteamet i Nav.
At her er de fleste tilbøyelige til å endre meninger. Hvis jeg har hatt én oppfatning, og så blir presentert med data som tilsier noe annet, så er de aller fleste tilbøyelige til å se at "her er det en utfordring". I hvert fall erkjenne at "her er det en utfordring". Så har vi gjerne litt diskusjon på hvorvidt dette er noe som Nice-plattformen skal løse. Det er også noe vi har vært veldig tydelige på, og det er ikke noe fasitsvar der heller. Men vi er veldig enige internt at Nice-plattformen er for applikasjonsutviklere, applikasjonsteam. Det er primært for customer. Det er utviklet i Nav. Det er ikke for hyllevare. Hver gang vi får inn problemstillinger, "hvordan kan vi integrere med dette?",
"imøtekomme det", så er stort sett svaret at det må kjøre et annet sted. Dette er Nav sin applikasjonsplass for utviklingsplattform. Har man det i bakhodet, så er det lettere å svare på andre spørsmål. Problemstillinger som handler om at her utvikler de egen software, men de støtter likevel på utfordringer, så er det mye mer aksept for at ok, dette er potensielt satt inn i Scope, og så må vi få litt mer klarhet i omfanget. Er dette en sånn one-off, hvor vi bare må si at sånn kan dere løse det på egen hånd, men det er ikke egentlig stort nok til at vi kan løse eller lage en generell løsning for alle. Men hvis det er noe vi ser at her er det andre som har utfordringer, eller vi tror at dette vil være til hjelp og til nytte for andretimene,
så er det selvfølgelig mye mer aksept for at dette skal vi lage en generell løsning, for å unngå at teamene må finne opp hjulet på nytt og på nytt, eller det samme hjulet. Så det er liksom det som hele tiden har ligget til grunn helt fra oppstarten, sånn som jeg har tolket det, med at dette er målet. Og at det er andre plattformer i Nav òg, og det skal det være òg. For vi skal ikke prøve å utkonkurrere alle. For vi har masse hyllevarer, masse legacy i sostfare og masse andre ting som bør bli bedre servet andre steder vi skal serve de egenutviklede applikasjonene. Jeg husker, jeg tror kanskje dette var i 2018. Thoughtworks Intekra hadde et ... Et element i Adopt som het "Treat your internal platforms as products".
Jeg husker første gang jeg leste det, så var det de gangene du liksom ... Noen som er flinke til å uttrykke seg, klarer å skrive kort og konsist det du har tenkt på lenge! Det er veldig gøy. Akkurat det skjedde da. For det passa så utrolig godt med hvordan vi hadde lagd plattform i Finn, når vi lagde Fjas, og hvordan vi lagde plattform i Nav når vi lagde Nice. Det er så mange elementer av god, gammeldags produktutvikling. Vi har hatt veldig nytte av i plattformen, og egentlig alle mulige typer produkter, det at det er et navn, f.eks. En logo, vi har klistremerker og hettegenser, og cardigans og capser,
og sokker, og alt mulig rart, som gjør at det blir en del av identiteten. Og vi jobba ganske mye med at det innenfor ekstremt smale definisjoner av kult, skulle være kult å bruke nei, sånn at ... For i starten så var det jo en kost å skrive seg om for å ta det i bruk. Og så har vi blitt vagt kjent for at vi brukte kake. Jeg anbefaler Samsons sjokoladekake, for den metter veldig mange. Alle som hadde én applikasjon i Prod på Nice, fikk kake. Og det var både fordi det ga noen et mål, men da tok vi alltid bilde av teamet som hadde kake. Da fikk de andre se at dette er jo det folk gjør, de migrerer til Nice.
Og da skapte vi mer blest om det. Og så har vi prøvd masse andre ting for å opprettholde den kontakten. Nice hadde en gang noe som het Key Account Managers. Nice Account Manager - Nams, som egentlig var dedikerte personer, som hadde ansvar for å følge opp ett område. Den store kanalen med 1000 medlemmer, det er ikke alle som syns det er greit å komme med sånne spørsmål de er redde for er dumme i det. Så det å ha mindre miljøer, det skapte mer trygghet og ga mer innhold. Så prøvde vi andre ting. En liten stund hadde vi vår egen interne stack overflow.
Et produkt vi kjøpte sånn at folk kunne stille spørsmål, vi kunne bruke strukturen rundt spørsmål, det funka ikke så bra. Folk ville heller bruke Slack og sånn. Så vi har prøvd, testa ut ting, som man skal i produktutvikling, hva som funker, og så har vi fortsatt med det som funker, og stoppa med det som ikke funker, eller det som er veldig dyrt og ikke funker. Sånn som stackover-flow er. Men hele tiden handler det om å, som dere var inne på, å forstå problemet til brukeren. Og som jeg husker Frode og Jonny var inne på, når er det man skal si nei?
Fordi man kan ikke bli en bestillingsmottaker heller. Plattformen handler jo om å ha meninger, og ikke bare løse alt som alle trenger. Og en av hemmelighetene til i hvert fall Nice og sikkert mange andre plattformer, er at den sier noe om hva som er lurt å gjøre, men den setter ganske få begrensninger på hva som er mulig å gjøre. Så hvis noen team trenger å gå utenfor, så går det an. Det er mye mindre magi involvert, men det er ingen som stopper deg fra det. Da får du noen ganger noen som finner ting som man ikke hadde tenkt på som plattform selv, og så går man videre i den, og så tar man noe lurt som et team gjør,
innlemmer det i plattformen, og så blir det magi for alle de andre igjen. Og så blir det veien å gå videre. Men jeg tror det er litt psykologisk òg, for det er veldig forskjell, og det merker jeg selv òg. Og på mine barn òg. Hvis jeg sier at du må gjøre dette her, eller at her er det man kan gjøre, men dette er lurt, og man kan faktisk få lov til å ta litt sånn ... Vil du ha sånn eller sånn genser på deg i dag? Litt begrenset mage, uten å skyte seg helt i foten, så har man mye å vinne på det. Det tar jeg når jeg var utvikler før også, så det å møte på en driftsavdeling som sa nei, for det er ikke sånn vi gjør det her, det fører til at du kommuniserer mindre.
Driftsavdelingen får ikke inn de behovene der de faktisk har løst problemer. Hele den endringen ... Jeg snakka med en av de flinkeste drifterne som sa at det var en perfekt dag for han, det var når ingenting skjedde. For da har ikke noe gått galt. Alt har bare vært akkurat som før. Mens for utviklerne er det en perfekt dag når det har skjedd masse. Og de to tingene er ikke så lett å få til å funke sammen. Og så føler jeg at verden har gått i den retningen at mye skal skje. Delen er vunnet. Det er fremgang som skal gjøres, men det kan ikke være Facebook "move fast and break everything". Men det går an, da. Det er det som plattformtankegangen egentlig har gitt oss.
Det er ikke lenger et motsetningsforhold mellom å ha fart og stabilitet. Det går an å ha fart og stabilitet samtidig, og standardisering. Det er ganske digg. Det er utrolig lærerikt å høre på dere. Når du sier det er produkter dere egentlig bygger, så blir jeg nysgjerrig på ... Siden vi skal snakke om teamet, da. Hvordan egentlig dere bruker læring og forbedring til 20 personer som et team? Har du eksempler på hvordan dere gjør det? Vi har jo mye strukturert læring, i hvert fall etter at vi har fått produktledere tilbake igjen òg. Det ene er at det gjøres regelmessige brukerundersøkelser. Det er jo litt sånn ... Alle er litt lei av surveys, men det er nå jeg ... Det er jo rett og slett bare å få brukerne våre til å klikke seg gjennom
og svare på noen spørsmål: Hva syns de faktisk om plattformen og de ulike delene? Og hvordan føler de at det hjelper dere i hverdagen, eventuelt om det er paintpoints? Så få det litt strukturert. Nice scorer stort sett bra. Og det er litt frustrerende òg, for det hjelper oss ikke helt å vite hvor er det vi har ... Vi har ikke de store forbedringspotensialene. Det høres litt selvskrytstig ut. Men det krever mer kreativ tankevirksomhet: OK, hvor er det vi skal videre? Men det er en positiv ting. Så har vi selvfølgelig internt dette med team helsesjekk, som vi også har fått på plass nå. Det er en slackpot som et annet team i Nav har laget, som vi kan gjenbruke.
Som hver uke, hver fredag, stiller spørsmål til alle i teamet: Føler du psykologisk trygghet eller arbeidsbelastning? Det er noe sett med spørsmål der. Og så er det sånn grønt, oransje, gult, fargekode, som vi får på mandag i morgen, ut ifra de svarene der, og hvilken trend går det. Så rett og slett for å se at den interne ... At vi er ... Og da igjen, tror jeg nok uten at jeg har sett tall for alle i Nav, så er vi i hvert fall i toppsjiktet på de med intern psykologisk trygghet. Takhøyden, få lov til å ... Og det ser vi også igjen med de ... Vi har én lukket kanal som bare får teamet, og helt, helt team anliggende. Og hvor trygg de aller fleste er på å dele at "vet du hva, i dag har jeg en dårlig dag".
Og får sympati og får liksom rom til det. Er ganske ... For meg veldig ... Jeg har ikke jobbet i team med så høy psykologisk trygghet før, så det er kjempekjekt. Og siden jeg er mest remote av alle de remote, helt over i bagen, så er det kjempeviktig at teamet fungerer godt sammen på den måten. Ja, det var nytt for meg at dere er jo helt remote. Dere møtes ikke så ofte. Nei, vi har vel en dag i måneden ... Nå blir det kanskje endringer med fokusperiodene. At det var kanskje sånn at vi skulle møtes på en retro, og så møtes etter to uker. Vi har endt cooldown for en planleggingssesjon av de neste seks ukene. Men frekvensen blir det samme, fikk jeg forklart. At det blir én i måneden. Selv om det blir på litt andre intervaller, de to.
Dette er jo noe som ble mye tydeligere etter korona. Der så var jo alle på hjemmekontor, men noen av teamene har i større grad kommet tilbake med nice team og har egentlig strukturert og formalisert hvordan de kan jobbe fulldremålt. Og det tror jeg de er. Usedvanlig fornøyd med. Det har vært skrevet artikler om hvordan nice team jobber, men de bruker jo sum. Har en lobby navnet Froom, for det var Frode sin sum, som er der alle møtes på morgenen. Og så har man sånne breakout-rooms der man går ut for å jobbe i par. Hvis man ikke gjør det, så sitter man i lobbyen.
Det jeg alltid syns er morsomt, er at man kan sitte fem stykker med Zoom på i lobbyen, Fordi man jobber hver for seg, og det er jo egentlig akkurat sånn det er i et landskap, eller et ... Med lyd og bilde? Ja. Mulig man skrur av lyd, jeg vet ikke ... Jeg pleier å ha lyd på, selv om jeg sitter og jobber med andre ting. For da kan du snakke sånn ... Gjerne muter gjerne min mikrofon, så ikke de får hosting og sånt, men at jeg hører hva andre sier. Og så har veldig mange noe sånn push to talk, at de har en showcut for å unnvise. Å unnmute seg og snakke.
Så kommer man dit når det er lunsj og sånn. Men den støyreduserende i Zoom er helt vanvittig bra. Nice canceling-biten der. Vi har prøvd noen andre verktøy, og det går som regel litt på latency, men veldig mye på nice cancelling. Selv om du har barn eller dyr på besøk på hjemmekontoret, er det sjelden gravemaskiner utenfor. Er det noen dyr på besøk? Det hender, det! En fisk svømmer forbi kontoret. Det er jo noe så dyrt hjemme. Vi må tilbake til det månedlige møtet, for da ble jeg nysgjerrig. Da møtes dere fysisk, da. Hvordan blir det et verdifullt møte for dere som team?
Dette er liksom på papiret, da. Som regel, eller det som ... Det som har blitt, er det at det månedlige møtet har blitt oppslukt av at det er andre fysiske ting som skjer i løpet av måneden. Da brukte vi den dagen til at det var en eller annen happening. Av og til har vi takt-days eller internkonferanser, at det skjer ting på kontoret på Helsfyr. Men det blir nok litt mer formalisert nå enn når vi går inn på denne her. Eller begynt med denne shapeup-biten. Og det har vi hatt. Vi har hatt gjerne kvartalsmessige samlinger. Hvor vi hadde gjort en større retro. Hvordan går det med teamhelsen, da.
Hvis den teamhelsen er oransje eller rød, hva gjør dere da? Det har ikke skjedd. Jeg er veldig spent på hva som skjer. Men nå har vi som sagt en felles administrativ leder. Ikke noe personalansvar, ikke noe faglig ansvar. Og så har vi en produktleder. Og så har vi selvfølgelig tech-leadene våre, pluss at vi har Gjøran i helt overordnet på ... Så det er mange støttespillere her som kan ta tak. Og det har jo skjedd at det har skjedd enkeltbiter, ikke sånn ... hva skal vi si ... At her er alt i rødt, eller hva det er sant. Så har det stort sett både teamet og, med litt hjelp fra, fra de utenforstående, har ordnet opp. Men jeg har i hvert fall ikke opplevd det.
Nå har jeg ikke jobbet så fryktelig lenge på mitt andre år, har ikke opplevd at det har vært den type hendelser som måtte kreve ekstern bistand. Min favorittdel av podkasten er når folk deler feil. For det er veldig lærerikt for andre å kunne høre hva som gikk feil, men hvordan man egentlig reparerte det, og hva man lærer. Så Audun, hvilke feil er det du vil dele som du tror er nyttig for andre? En ting jeg tenkte på, som er tilbake i finntiden, men det henger ganske godt sammen med det vi har snakka om i dag også, for da var det også et plattformteam som prøvde å lage en ny plattform, og som hadde ansvaret for å holde det stabilt.
Og da prøvde vi på flere forskjellige prosesser og prioriteringsverktøy for å klare å strukturere jobben, for vi var også en del mennesker. Og da klarte vi aldri å finne ... Eller vi prøvde å lage så mye prosess, og vi var så opptatt av å lage ting at vi ... Endte opp med en prosess som aldri tok inn over seg at mesteparten av jobben kommer inn fra sida. Gjerne på DM til en eller annen person, og så blir det aldri noe inni noen tavle, eller noe som helst. Og så får du sånn skyggespill av en tavle der alt du skulle gjort, står, og så har alle dårligere samvittighet, og så har du enda dårligere standup-møte hvor alle snakker om det de ikke gjør, istedenfor det du gjør. Vanlig team når du får ting i prod., har nok litt det samme,
men plattform er veldig sånn "er det noe gærent her?". Drevet. Det var jeg og Kjartan som gjorde den feilen da, i hvert fall. Så hvis noen skulle lagd et plattformteam i dag, hvilke tips ville du gitt dem da? Det er jo da å klare å være tydelig på at mye av jobben kommer fra brukerne, og det kommer plutselig. Og det kommer plutselig, og det haster, og det er ofte personbasert. Og det er vanskelig å få folk til å gå utenfor at de kjenner en veldig godt og sier det til han/hun. Så det er ... Og da får du en, hvis du prøver å designe en prosess som ikke tar det inn over seg, så blir det bare tull. Herlig. Du da, Hans Christian? Jeg har vært konsulent lenge før jeg begynte i Nav. Og plattformteamet i Nav. Og da var det spesielt én...
Et engasjement hvor vi kom inn som var et rent bestillingsverk. Det var et prosjekt, vi skulle bygge plattform på plattformprosjektet. Flere av de. Og spesielt en av de hvor vi aldrie egentlig fikk brukerne i tale, vi fikk aldri snakket med applikasjonsutviklerne. Og skulle egentlig lage noe som moderniserer en plattform som var on-pram ute i sky, Men ikke egentlig bygge den, vite hvem vi bygget den for og hva de faktisk trengte. Og det tok fryktelig lang tid. Den ble vel til slutt realisert lenge etter at jeg ikke var med i det teamet lenger, og har vel blitt ... Begynt et nytt forsøk, som er mer en produkttankegang. Men det er jo den der produkt ... Minimum viable product, eller platform ... Tinnest viable product.
Nei, Tinnest viable platform. Ja! Som handler om hva er den minste plattformen vi kan lage, som gir verdi for noen. Og så å ha god dialog med den noen. Og så utvide, da, slik at det blir en plattform som gir verdi for litt flere. Håper en eller annen god podkast kan plotte til det. Ja, det hadde vært veldig ... Følg med! Så igjen ... Og det var litt i kjølvannet av spesielt det prosjektet der, at du virkelig så det med her styrken av ... Eller hvor det internt i hjernebarken ... Hva er det folk snakker om når de snakker om produkt? Jeg har jobbet sånn før det òg, men virkelig så forskjellen der.
Men Benedikte, jeg har lyst til å spørre deg et spørsmål. Hva har du lært i dag? Jeg har lært utrolig mye. Jeg skrev ned 20 personer. Det er imponerende at dere er et team med 20 personer. Det er jo "two pizza rules" som vi har lært opp gjennom årene. Det jeg syntes var veldig kult, er hvordan dere har holdt team dynamic og samarbeidsform i takt med læringen dere har gjort fra tidlig start til i dag, med å ikke ha for mye prosess, ikke ha for mye verktøy. Ikke bruke for mye tid på ting som ikke gir verdi. Det er det jeg tenker. Dere består av en gjeng med seniorfolk som er veldig nysgjerrige og villige til å utvikle seg.
Det tror jeg òg er en av nøklene til at dere kan være så mange, og gitt at dere også har testet å bryte inn når du jobber i mindre grupper, som blir siloer. Der driter vi i det. Vi må kontinuerlig holde den samarbeidsformen i takt med det behovet. Det syns jeg var kjempeinspirerende å høre om hvordan dere helt praktisk gjør det. Jeg har så mange spørsmål under vei, sant? "Hvorfor er dere femte stykker i den timen?" Det er jo en middels norsk bedrift, på en måte. Så det var ekstremt lærerikt. Og hvordan ... Det høres ut som det er veldig lav terskel å ta opp ting. Både den Zoom-lobbyen og alt det uformelle som legger til rette for kommunikasjon, transparens og det å involvere ... Brukerne deres på en ekstremt lavterskel måte.
Så det er min hovedlæring. Kutt prosess. Kutt koordinering og siloer. Og egentlig løs behovene kontinuerlig, og ta ting litt så det kommer. Jeg tror det er min hovedlæring, da. Så ja, det var kjempespennende. Og jeg kommer gjerne igjen om en stund, hvis jeg mener at dere bare snakker om plattformene! Tusen takk til deg, Benedicte Fjellanger fra Team Agile, som tok over som host for denne episoden av Plattformpodden. Mitt navn er som alltid Hans Kristian Flåtten, og med meg har jeg Audun Faukastrand, og teknisk produsent er vår eminente Tore Græsdal. Nyeste episode finner du alltid på plattformpodden.no eller i din lokale podkastapp. Del gjerne denne episoden med en kollega og få god karma i retur. Takk for oss.
Ha det bra!