– Man kommer ikke fremover uten å løsne tøylene
Gunn Severinsen satt på bussen fra Gøteborg til Oslo da Norge stengte i mars. Til tross for det dramatiske tidspunktet, mener hun timingen var god for oppstarten av kompetanse- og innovasjonsselskapet Squeed i Norge. Bedriften med 100 ansatte har allerede kontorer i Stockholm og Gøteborg. Viktigheten av gode it-løsninger ble ikke mindre med pandemien. I stedet økte antall prosjekter og flere konsulenter ble engasjert.
Å lære andre å jobbe smidig er Squeeds spesialitet. Målet er å kunne bidra til å skape varige verdier. For å lykkes kreves det teknologi og en smidig tilnærming, både på systemnivå og i ledelsen. Først da kan det legges til rette for å skape team som presterer på høyt nivå.
– Dette høres både logisk og enkelt ut, men når det gjelder utførelse kan det være vanskelig, sier Gunn Severinsen.
Må gi slipp
En av utfordringene for bedrifter som ønsker å bli mer smidige, er at ledere har problemer med å gi slipp på kontroll og detaljstyring. Dersom ledelsen ikke våger å gi teamene tillit til å treffe egne beslutninger, og dermed overlate noe av kontrollen til dem, blir det vanskelig å lykkes, mener Severinsen.
– Det er et skille mellom de som er gode, og de som lykkes.
DevOps er en blanding av utvikling (Dev) og operasjoner (Ops), og et sett med praksiser for å automatisere og integrere prosessene mellom programvareutvikling og it-team. Det bygger bro over gapet mellom utviklings- og driftsteam, som historisk fungerte i siloer. Smidig utvikling i denne sammenhengen innebærer altså at man må ha på plass både metodikk, arkitektur, prosesser, dokumentasjon, kode, infrastruktur – og et team som dekker ulike roller – der medlemmene er avhengige av hverandres kompetanse.
Etter flere tiår med prøving og feiling innen it-utvikling, oppsto det agile (smidig eller tilpasningsdyktig, journ.anm.) begrepet tidlig på 2000-tallet, med mål om å finne bedre metoder for programvareutvikling. I løpet av de siste tiårene har vi opparbeidet mye erfaringsbasert innsikt som viser at smidig utviklingsmetodikk fungerer og gir effekt.
– Før DevOps hadde man planleggingsintensive prosjektmodeller, der det også var mye koordinering av utførelsen. Kartet stemte ikke alltid med terrenget, og fokuset på avvik tok mye tid og energi. I dag har de fleste forlatt disse modellene. Man driver i stedet etter det vi kaller agile prinsipper og med DevOps. Det betyr at de har et tankesett, der de ser på problemstillingen utenfra og inn. Da starter man med brukerbehovet. Enten det handler om folk, produkter eller prosesser, er tanken at man jobber for å legge til rette for forbedringer slik at verdien for brukerne økes, forklarer hun.
Teamet må dekke de ulike rollene, og må ha bred kompetanse. Men dette er ikke nok, ifølge Severinsen. Organisasjoner som velger denne veien må også ta noen prinsippvalg: Brukerfokus, realisering av produkt fremfor prosjekt, investering i kulturen og å skape varige verdier.
Små team
For å lykkes må ikke teamene vokse seg for store. Ideelle team består av mellom syv og ni personer. De kan ikke bli større, presiserer Severinsen.
– Disse teamene er helt avhengige av samarbeid med andre. De må ha definerte oppgaver, og ikke minst må de ha fått tillit til å utføre dem. Man må levere hyppig, teste, forkaste og godkjenne. Og arbeidet med forbedringer må skje på kontinuerlig basis, sier hun, poengterer hun.
Man må levere hyppig, teste, forkaste og godkjenne. Og arbeidet med forbedringer må skje på kontinuerlig basis
Dersom teamene er avhengige av en funksjon i et annet team, er det viktig at de kan gå direkte til det andre teamet for å få hjelp. Veien om ledelsen må unngås.
– Det er dette som ikke er enkelt. Ofte har man eldre løsninger og systemer å forholde seg til – teknologiske og kulturelle faktorer. Det er viktig at man har gode prosesser for godkjenning, og målene. Ting må være forankret høyt nok opp i organisasjonen. Ufordringen er at det er lett å gå inn i gamle mønstre. Gammel vane er vond å vende, påpeker hun.
Må forankres i ledelsen
Teamene må få lov til å samarbeide direkte med andre team, og de må få mandat til å øve seg på å treffe beslutninger på egenhånd. Det handler om å lære av beste praksis, og også om å bygge egne erfaringer.
– Mange har blitt svært dyktige av å jobbe på denne måten.
Visjoner, mål og retning må komme fra ledelsen. Når disse ligger fast, må de brytes ned i teamjobbing.
– Da kommer det en fastsatt kvalitet ut av dette arbeidet, som vi kaller mål. Ledelsen må altså kommunisere hva vi skal oppnå på en tydelig måte. Hvis ledelsen ikke har involvert seg nok, kommer man ofte på gale veier. Det koker ned til at ledelsen må våge å gi fra seg kontroll, og gi mandat til andre – altså tillit. Man kommer ikke fremover uten å løsne tøylene, og skulle man mot formodning gjøre det vil det ta mye lengre tid. Feiler man her blir arbeidet sittende fast i prosesser og hierarkier, og det er lite effektivt, utdyper Severinsen.
Noen av årsakene til at organisasjoner sliter med å utnytte det å jobbe smidig handler om hvordan de er organisert, eiersituasjon, kultur og politikk.
– Uansett må ledelsen legge til rette for effektivitet, gi tillit, bygge tillit og gjøre seg fortjent til tillit. Dem som lykkes har bygget autonome team som tester, forkaster og tar i bruk løsninger – og som kan treffe beslutninger om eget område. De jobber mer målrettet. Det skaper positive effekter og mestringsfølelse, som igjen fører til økte verdier over tid.
Alle har budsjetter å forholde seg til, også teamene. Da er det viktig at ledelsen har utviklet verktøy, detaljer, metodikk, finansiering, arkitektur, dokumentasjon og koder.
– Dette er et stort felt, som ligger i skjæringspunktet mellom teknologi og menneske, men uansett er det å legge til rette for dette et overordnet lederansvar, avslutter Gunn Severinsen i Squeed Norge.
-
Etabler en tydelig og forankret visjon og et målbilde, og følg opp resultatene. Unngå «moving targets»
-
Etabler og jobb kontinuerlig med en kultur som er basert på tillit
-
Etabler produktfokus og sluttbrukerfokus. Man skal levere verdi over lang tid til sine brukere – ikke bare prosjekter som avsluttes
-
Teamene må få mandat, frihet og tillit for å nå målene – og de bør være selvstyrte. Unngå micromanagement
-
Gi retningslinjer og rammer, men la teamene selv velge sin metodikk, sine verktøy og prosesser
-
Både i teamene – og mellom team som er avhengige av hverandre – bør man ha korte beslutningsprosesser uavhengig av hierarki, slik at fart og kvalitet beholdes
-
Visualiser både mål, fremdrift og resultater
Kilde: Gunn Severinsen