Er du smidig?

Smidig – eller det engelske agile – er begrep som stadig brukes i presentasjoner og i jobbannonser, spesielt innenfor IT-bransjen. Smidig beskriver at vi følger et sett av ideer om at utviklingen blir bedre om man forlater den tradisjonelle fossefalls-tilnærmingen og mange har derfor trykket det til sitt bryst. Fossefall - en tilnærming som  beskriver et prosjekt som en lineær og sekvensiell utvikling - anses som litt gammeldags og utdatert - og ingen ønsker jo å identifiseres med noe som er utdatert.

Men, er det bare ord? Blir man “smidig” av at man innfører terminologien - eller krever det noe mer å virkelig bli smidig?  Vi må, som Fleksnes var inne på, ikke bare si halleluja, men også gjøre det.

I mange virksomheter er smidig et begrep som kun beskriver hvordan – at utviklingsteamene følger en metodikk. “Vi har team som bruker Scrum. De har standup hver morgen klokken 9. Teamet har en backlog, de har store whiteboardtavler og de gjennomfører retrospektiv etter hver sprint.”

Er dette smidig?

For meg er “smidig” en beskrivelse av hvordan du kan bygge innovative produkter kunder liker. For meg betyr dette at målet med en smidig utvikling er å skape verdi - gjennom mer fornøyde kunder og brukere, høyere salg, mer effektive prosesser og riktigere investeringer. For meg handler ikke smidig om at du bruker Kanban, Scrum, Extreme programming eller en annen metode.

Jeg har vært med på å investere 20 milioner i prosjekter – før noen egentlig hadde undersøkt om det vi var i ferd med å lage var noe kundene ønsket, eller var interessert i å betale for. Og jeg har også vært med på det motsatte - gjennom å ha en god dialog med de som skulle bruke en løsning, ende opp med nyttig funksjonalitet som løste behovet med en minimal investering - som gjorde lønnsomheten til et produkt vesentlig bedre.

Dette er også hvorfor det er så viktig å innse at overgangen fra tradisjonelle prosjekt og funksjonsteam til autonome produktteam går langt utover produkt og teknologi. Forskjellen mellom et produkt- og funksjonsteam handler i hovedsak om myndiggjøring. Forskjellen mellom å gi et team et problem å løse, versus å gi dem funksjoner å bygge.

Forskjellen mellom prosjekt og produkt

Forskjellen mellom et produktteam og en prosjektgruppe handler i stor grad om eierskap. Forskjellen mellom et team som tar ansvar for et utfall, kontra et team som er der kun for å levere et prosjekt, og deretter gå videre til noe annet.

Manglene ved prosjektorganisering er velkjent. Hvorfor bruker mange fortsatt prosjektet som måten man organiserer arbeidet på, da? Hovedårsaken er at prosjektgrupper er en del av IT-kulturen. Husk da at det viktigste for IT tradisjonelt er å behandle teknologi som et kostnadssenter. Prosjektorganisering rokker ikke ved maktstrukturene i selskapet, og organisasjoner har som kjent en egen iboende motstand mot å endre maktstrukturer.

Er alt vi har gjort til nå bortkastet?

Den gode nyheten er at det er det ikke. Det at din virksomhet har bestemt seg for å jobbe smidig, er et godt utgangspunkt for veien videre.

I en serie bloggposter vil vi fremover skrive om ulike deler av det å bli smidig. Innen brukermedvirkning, teamutvikling, smidig sikkerhet, DevOps og flere spennende tema.