Smidige team: - Man kommer ikke fremover uten å løsne tøylene

Organisasjoner blir ikke smidige før ledelsen lærer å gi fra seg kontroll og gir teamene reell tillit.

Gunn Severinsen satt på bussen fra Gøteborg til Oslo da Norge stengte ned 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 akkurat 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 på 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 styring av detaljer. Dersom ledelsen ikke våger å gi teamene tillit til å treffe egne beslutninger, og dermed overlate noe av kontrollen til dem, blir det vanskelig å lykkes. 
Det er et skille mellom de som er gode, og de som virkelig 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 - og der medlemmene er avhengige av hverandres kompetanse. 

Etter flere tiår med prøving og feiling innen it-utvikling, oppsto det agile (jf. smidig eller tilpasningsdyktig ) 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 erfaringsmessig innsikt som viser at smidig utviklingsmetodikk fungerer og gir effekt. 

Før DevOps hadde man planleggingsintensive prosjektmodeller, der det 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 tankesett og med DevOps. Det betyr at man ser på problemstilingen utenfra og inn, og starter med brukerbehovet. Enten det handler om folk, produkter eller prosesser, er tanken at man legger til rette for forbedringer slik at verdien for kundene økes. Teamet må dekke de ulike rollene, og må ha riktig kompetanse. Men dette er ikke nok. Organisasjoner som velger denne veien må også ta noen prinsippvalg: brukerfokus, realisering av produkt fremfor prosjekt, investering i kulturen og det å skape varige verdier

For å lykkes må ikke teamene vokse seg for store. Teamene er helt avhengige av samarbeid med andre. De må ha definerte oppgaver innen et mål, og ikke minst må de få tillit til å utføre dem. Man må levere hyppig: utvikle, teste, forkaste eller godkjenne. Og arbeidet med forbedring må skje på kontinuerlig basis. 

Dersom teamene er avhengige av en funksjon, korrigering eller avklaring i et annet team, er det viktig at de kan gå direkte til det andre teamet for avklaring. Veien om ledelsen bør unngås. 

Det er dette som ikke er så enkelt. Ofte har man eldre løsninger og systemer å forholde seg til - teknologiske og kulturelle faktorer. Det er viktig at man har god prosesser for godkjenning, og målene må være forankret høyt nok opp i organisasjonen. Utfordringen er at det er lett å gå inn i gamle mønstre. 

Må forankres i ledelsen
Teamene må få lov å samarbeide direkte med andre team ved behov, og de må få mandat til treffe beslutninger på egen hånd. Det handler om å lære av beste praksis, og også om å bygge egne erfaringer. 

Visjoner, mål og retning må komme fra ledelsen. Når disse ligger fast, må de brytes ned i teamjobbing. Ledelsen må altså kommunisere hva man skal oppnå på en tydelig måte. Hvis ledelsen ikke involverer seg nok her, kan man havne på gale veier. Ledelsen må våge å gi fra seg kontroll og gi mandat til andre - altså ha tillit. Man kommer ikke fremover uten å løsne tøylene. Feiler man her kan arbeidet bli sittende fast i prosesser og hierarkier, og det er lite effektivt.

Ledelsen må legge til rette for effektivitet: gi tillit, bygge tillit og gjøre seg fortjent til tillit. De som virkelig lykkes har bygget autonome team som utvikler, tester og tar i bruk løsninger - og som kan treffe beslutninger om eget område. De jobber mer målrettet. Det skaper også positive effekter og mestringsfølelse, som igjen fører til økte verdier over tid. 

Dette er et stort felt som ligger i skjæringspunktet mellom teknologi og menneske. Uansett er det å legge til rette for dette et overordnet lederansvar, avslutter Gunn Severinsen i Squeed Norge.
SLIK BYGGER DU SMIDIGE TEAM:

• 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 til å treffe beslutninger for å nå målene - og teamene 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 beslutningsprosser uavhengige av hierarki.
• Visualiser både mål, fremdrift og resultater.

Vi gjør oppmerksom på at teksten er hentet fra artikkel som stod på trykk i Dagens Perspektiv 20. november. Den var basert på et intervju med Gunn Severinsen og ført i pennen av journalist Bård Andersson.