DEVOPS

Trenger vi egentlig ledere når vi lykkes med DevOps? Når selvgående, autonome team blir kompetente til å ta beslutninger innen eget fagområde, så må jo lederrollen endres. Ledelse basert på kontroll og styring, er ikke spesielt kompatibelt med raske smidige team, og tradisjonelle virksomheter som forsøker å innføre DevOps uten å endre sin tilnærming til ledelse, vil sannsynligvis feile. Forskningen viser nemlig at «riktig type ledelse» er avgjørende for å lykkes med DevOps, og lederstilene hos de som har lykkes best blir kalt transformasjonsledelse og servant leadership.I episoden forteller Kristine hvordan de i DNB praktiserer servant leadership og hvor bra det er med en leder som jevnlig stiller spørsmålet: «Hva trenger du fra meg i dag for å kunne gjøre en god jobb?». Servant leadership er svært viktig for å kunne utvikle gode team, og det er ikke forbeholdt formelle ledere. Det ivaretas gjerne av scrum-mastere og smidig-coacher, som bidrar til å skape psykologisk trygghet og kultur for innovasjon og læring i teamene de støtter. Fagområdet ledelse er i endring. Overgangen fra tradisjonell ledelse til moderne DevOps-ledelse er større enn mange er klar over. For ledere som har vært vant til styring og kontroll, kan det føles skummelt å praktisere «gi-slipp-ledelse», spesielt hvis du føler at du selv er den beste fagpersonen på et område. Det krever høy tillit å gi slipp. Derfor kalles DevOps-virksomheter ofte for «high-trust»-organisasjoner. Høy tillit i en organisasjon kan skapes. Det i seg selv er en viktig lederoppgave. Med DevOps trengs det mindre kontroll og styring. Til gjengjeld kreves det mer kompetanse på mange andre områder. Ledere må ha kunnskap om Lean og verdistrømfokus, samt forstå hvilke muligheter det ligger i teknologi. Dessuten trenger de masse kompetanse på det å bygge menneskevennlige organisasjoner preget av tillit, psykologisk trygghet og indre motivasjon.DevOps-ledelse er rett og slett menneskevennlig ledelse som tar forskningen rundt motivasjon på alvor. Med slike oppgaver blir det jo morsommere å være leder også! Hør mer i episoden om hvordan en leder kan gå fra å være sjakkspiller til å bli en gartner!Bokanbefaling:Kapittel om ledelse i boken Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, av Gene Kim, Jez Humble og Nicole Forsgren  Lenker:Opptak av DevOps-foredrag på forrige itSMF-konferanse: https://itsmfkonferansen.no itSMF NorgePodkasten er støttet av den ideelle organisasjonen itSMF Norge, som jobber for å fremme god praksis rundt det å skape gode IT-tjenester. https://www.itsmf.no/ Hosted on Acast. See acast.com/privacy for more information.

NAV står midt i en digital transformasjon som har ført til store endringer i organiseringen og måten de driver tjeneste- og produktutvikling på. De har gått fra prosjekter til produktteam, og organisert over 100 tverrfaglige produktutviklingsteam i åtte forskjellige produktområder. Dette har bidratt til økt fart og flyt og raskere innovasjonstakt. Tommy Jocumsen, leder i Seksjon for Utvikling, NAV IT, er gjest i denne episoden.  Hvordan har NAV IT gått frem for å lykkes med DevOps? Hvordan har de klart å endre seg fra å være en prosjekttung IT-organisasjon, til å bli en smidig DevOps-organisasjon?  Vi husker vel alle NAV-skandalen i 2015, om feilpraktisering av EU-regler om sykepenger og store IT-prosjekter som gikk langt over budsjett. Etter skandalen fikk NAV ny ledelse, og inn kom en ny IT-direktør, Torbjørn Larsen, som sa at nå er det på tide å jobbe annerledes! Nå skal vi jobbe mer verdidrevet og tverrfaglig, vi skal gi myndighet til teamene og ta eierskapet til leveransene selv. Lettere sagt enn gjort? Torbjørn Larsen satte en ny kurs for organisasjonen, men siden det handler om mennesker, kultur og ledelse, så har det likevel tatt lang tid å komme dit de er i dag. I denne episoden deler Tommy mange verdifulle erfaringer og læringspunkter. Et viktig steg var å gå fra outsourcing til insourcing: Før 2015 hadde ikke NAV-IT egne utviklere. Prosjektene var bemannet med innleide ressurser. I dag har de et par hundre utviklere og skulle gjerne hatt flere! De digitale løsningene for dagpenger, sykepenger osv. er kjernevirksomhet, og kjernevirksomheten bør du jo ha kontroll på selv. Det er ikke noe du setter bort til andre! Tommy forteller også hvordan de har brukt tankegods fra boka Team Topology for å sette opp verdistrømteam og støtteteam, og hvordan de jobber for å skape fart og flyt for teamene. Det er noe Tommy jobber med til daglig i sosioteknisk team.   Endringene NAV har vært igjennom er som du forstår ganske formidable. På DevOps-språk kaller vi det intet mindre enn en agil transformasjon. Hør om den spennende endringsreisen i ukas episode.  Bok-anbefalinger:·      Team Topologies - Organizing Business and Technology Teams for Fast Flow, av Matthew Skelton, Manuel Pais·      Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, av Nicole Forsgren,  Lenker:Opptak av NAVs foredrag på itSMF-konferansen finner du på ressurssiden: https://itsmfkonferansen.noitSMF NorgePodkasten er støttet av den ideelle organisasjonen itSMF Norge, som jobber for å fremme god praksis rundt det å skape gode IT-tjenester. https://www.itsmf.no/ Hosted on Acast. See acast.com/privacy for more information.

Må du omorganisere for å kunne lykkes med DevOps? Og hvor viktig er det egentlig med en gjennomtenkt virksomhetsarkitektur?Arkitektur handler om å designe en struktur som passer til et formål. Dette gjelder både tradisjonelle arkitekter og virksomhetsarkitekter. Arkitekttegninger for et sykehus er svært forskjellige fra arkitekttegningene for et kontorbygg, som igjen er svært forskjellig fra en modulbasert brakkelandsby. Bygninger må designes ut fra det formålet og funksjonene bygningene skal fylle. På samme måte må virksomhetsarkitekter designe organisasjoner ut fra hva organisasjonen skal oppnå. I denne episoden snakker vi derfor om arkitektur på flere nivå. Det må nemlig til, for å skape en virksomhetsarkitektur som muliggjør autonomi og rask verdiskaping. Det handler hvordan organisasjoner kan rigge seg for DevOps. En nøkkel er å tenke «tjenesteorientert arkitektur», ikke bare for applikasjoner, teknologi og infrastruktur, men også for team- og organisasjonsarkitektur. Tverrfaglig samarbeid kommer nemlig ikke av seg selv. Noen ganger må man riste litt i organisasjonskartet for å bevisst designe for en bedre flyt. Dette er godt forklart i boka Team Topology, som viser en modell for hvordan man designe en team-struktur som legger til rette for størst mulig autonomi.Vi kommer også inn å hvordan selve infrastrukturen designes for flyt, og forklarer begrepene CI/CD Pipeline, DevOps Tool-chain, Cloud-teknologi, monitorering, automatiske tester, teknisk gjeld og en rekke andre viktige elementer i DevOps. Vi snakker også om hvordan DevOps-praksiser er designet for tverrfaglig samarbeid, og har innebygde mekanismer for forbedring av sikkerhet og kvalitet. Denne episoden avslører mange av «hemmelighetene» bak DevOps, og forklarer hvordan det kan ha seg at gode DevOps-team skaper nye tjenester både bedre, raskere, og sikrere enn tradisjonell IT, med langt færre feil og mindre nede-tid. Og hvordan dette i tillegg fører til lavere risiko, mer innovasjon og høyere trivsel. Med andre ord: Langt mer enn et Kinderegg! For å gå tilbake til analogien vi startet med, så ligner vel DebvOps-arkitektur mest på en modulbasert brakkelandsby. :-)Dette forteller Anne-Kristine mere om i episoden. Hør den nå!Våre bok-anbefalinger:Lean Software Development, av Mary PoppendieckTeam Topology, Matthew Skelton og Manuel Pais Lenker:Ressursside med opptak av foredrag fra itSMF-konferansen: https://itsmfkonferansen.noPodkasten er støttet av den ideelle organisasjonen itSMF Norge https://www.itsmf.no/ Hosted on Acast. See acast.com/privacy for more information.

DevOps tar teamarbeid på alvor. For å lykkes med DevOps trenger du langvarige, selvstyrte produktteam med ende-til-ende-ansvar, i motsetning til funksjonelle siloer og kortvarige prosjektteam. I denne episoden vil du få høre mer om hvordan DevOps-team bygges opp, og hvordan de trenger støtte fra gode ledere som setter en klar retning. Du får også høre om forskningen rundt indre motivasjon, og om hva som kjennetegner høyprestasjonsteam. Våre bok-anbefalinger:The Phenix project & The Unicorn Project, G. Kim Reinventing Organisations, av Frederic Lalux Lenker:Ressurssiden til itSMF-konferansen https://itsmfkonferansen.no (ressursside: brukernavn og pw: itSMF)«Mitt første ærend» https://www.aftenposteninnsikt.no/asia/japans-selvstendige-barnPodkasten er støttet av den ideelle organisasjonen itSMF Norge https://www.itsmf.no/ Hosted on Acast. See acast.com/privacy for more information.

De siste tre århundrene har vi gått gjennom flere teknologiske revolusjoner. Hver revolusjon med en ny teknologi å mestre, og hver teknologi med et vendepunkt der teknologien ble kraftfull og moden. Forskeren Carlota Perez hevder vi nå er i vendepunktet for «programvarens tidsalder». DevOps representerer «høyhastighets-IT». De beste innen DevOps lanserer ny funksjonalitet tusen ganger raskere, med tre ganger lavere feilrate, og er i tillegg raske til å rette feil. DevOps handler ikke om teknologi, men om tankesett, og representerer et paradigmeskifte i måten å jobbe med IT på. Mest av alt er DevOps kulturendring som påvirker hele virksomheten. I denne episoden får du høre mer om hva DevOps egentlig handler om. Våre bok-anbefalinger:Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, av Nicole Forsgren, Jez Humble, Gene KimThe Phenix Project & The Unicorn Project, av Gene Kim  Lenker:Carlota Perez sitt foredrag på itSMF-konferansen https://itsmfkonferansen.no(ressursside: brukernavn og pw: itSMF)The State of DevOps report https://cloud.google.com/devops/state-of-devopsPodkasten DEVOPS er støttet av den ideelle organisasjonen itSMF Norge https://www.itsmf.no/ Hosted on Acast. See acast.com/privacy for more information.

DEVOPS er snart ute med første episode! Hosted on Acast. See acast.com/privacy for more information.