Mengden ord og uttrykk som svirrer rundt i IT-eteren er stadig voksende, og hvis du er bittelitt treig i avtrekkeren sånn som meg, så har ordene blitt hverdagstale før du rekker å finne ut hva de egentlig betyr. Og da er det jo for seint å spørre hvis du vil beholde siste rest av tech-cred. Så derfor; for alle som sov i timen eller som foretrekker å få det inn med te-skje; dette er smidig metodikk.
Altså, smidig metodikk. Alle prater om det og alle vil ha det. Ikke så rart, kanskje. Det motsatte — som vel vil være stivbeint metodikk — skjønner jo alle at er noe du bør unngå i det lengste. Ikke like lett å skjønne at du bør unngå det når det motsatte kalles tradisjonell metodikk, kanskje, men, men …
Undertegnede synes dessuten at smidig metodikk er en av de tingene som faktisk låter kulere på norsk enn på engelsk. “Agile” får meg av en eller annen grunn til å tenke på igler, og selv om en igle i og for seg kan være smidig hvis du drar hardt i den, vekker det jo ikke akkurat positive assosiasjoner. Men det er altså meg. Det er et fritt land og andre kan mene noe annet og så videre.
Så hva er smidig metodikk?
Vel, altså … egentlig er det enklere å forklare hva det ikke er. Ikke sant; skal du for eksempel lage en tunnel bør du planlegge godt på forhånd. Du begynner jo ikke akkurat å bore på måfå inn i ett eller annet tilfeldig fjell og håper at det ikke ligger en barnehage eller et fiskemottak eller et rådhus på den andre siden. Du må vite akkurat hvor tunnelen starter og nøyaktig hvor den slutter. På centimeteren! Og så er det en fordel å finne ut av hva du kommer til å møte på av gneis, granitt, kvarts, glimmer og blåleire og kvikksand og hva det nå heter for noe alt dette rare som befinner seg inni et middels norsk fjell. Ting må planlegges. Og det nøye.
Og før — i gamledager — da vi skulle begynne å lage store datasystemer, da brukte vi tunnelmetodikken. Jeg tipper dette skyldtes en eller annen form for metodelekkasje mellom de ulike studieretningene på de tekniske utdanningsinstitusjonene, men det er en høyst personlig teori. Vel, uansett; vi planla. Åh, som vi planla. Nøyaktig hvor vi skulle begynne og på millimeteren hvor vi skulle slutte. Og hvert eneste skritt på veien. Ned til hver minste detalj. Metodisk. Nøyaktig. Først analyserte vi, så skrev vi krav, så tegnet vi bokser, så programmerte vi, så testet vi og til slutt ble hele greia implementert og overlatt til noen som forhåpentligvis kunne drifte det. Metodisk fra start til slutt. Ryddig og greit. En ting av gangen. Ja da.
Problemet var bare at dette ikke fungerte like bra når du skulle lage datasystemer som når du skulle lage tunneler. For det viste seg jo titt og ofte at denne typen prosjekter gikk fullstendig av skaftet. Det kostet gjerne ti ganger så mye som du trodde da du begynte og det tok i alle fall mye lenger tid. Som oftest endte du opp med noe som ikke løste problemene i det hele tatt. Oversatt til tunnelspråket kan du si at du gjerne havnet midt oppi en barnehage, et fiskemottak eller er rådhus når du kom ut på andre siden. Hvis du da kom ut i det hele tatt. Det finnes nok av dataprosjekter her i landet som har endt opp som et høl i et fjell og ingenting annet.
Grunnene til dette kan være mange. Personlig holder jeg en knapp på Babels-tårn-teorien og litt genuint språksurr. Det er nemlig innmari vanskelig for en som har skikkelig peiling på forretningsting, å fortelle en hardbarka datatype hva han vil skal lages sånn at datafyren forstår. De snakker rett og slett forskjellig språk. Det er for mye som blir “lost in translation” for å si det sånn. Og så er det noe med å beskrive hva du egentlig trenger da. Det er jammen ikke lett bestandig. Jeg tror for eksempel at en versjon av meg fra 2009 hadde hatt digre problemer med å beskrive et behov som ble møtt av en Apple Watch. Men jeg har nå klokka på armen og den dekker flere behov enn å fortelle meg når jeg må løpe til trikken. For ting forandrer seg med tiden og det bringer oss fram til den tredje grunnen til at tunnelmetodikk ikke funker så bra på IT-løsninger; for mens fjell har en tendens til ikke å forandre seg noe særlig i en perioden på en 4–5 år, så forandrer teknologien seg og verden vi lever i en hel masse. Så når folk satt der og skulle detaljbeskrive et behov de ikke helt skjønte, med et språk de ikke kunne, måtte de i tillegg ta høyde for at verden ville være helt annerledes når løsningen skulle begynne å virke.
Ikke rart det skar seg. Ikke rart mange IT-prosjektene endte opp i endeløse diskusjoner mellom kunder og leverandører om tolkninger av avtaler, endringsmeldinger, budsjettoverskridelser, scope creeps og alt sånt som gjorde et godt samarbeid umulig.
Så derfor var det noen som begynte å tenke lure tanker om at man kanskje burde lage litt av gangen. Og la de som lager greiene liksom prøve seg fram. Sammen med de som skal bruke greiene, liksom.
Litt som … litt som når du skal finne deg en livsledsager!
Jeg tror at mange er enig med meg når jeg påstår at det er lurt å gå littforsiktig fram når du skal finne deg en partner for livet. Ikke sant; du begynner gjerne med en deit. Og fungerer det så blir det en til, og en til. Og enda en. Og om du for eksempel finner ut at den du deiter er med i Kanarifansen og det er helt utenkelig for deg å leve sammen med noen som holder med Lillestrøm, så kan du hoppe av. Når du vil.
Og hvis ting fungerer bra, flytter dere kanskje sammen. Kanskje blir det giftemål. Og barn. Og sånn kan du bare fortsette å utvide funksjonaliteten; med flere unger og rekkehus, med vinkjeller og stasjonsvogn, med Golden Retriever og hytte på Golsfjellet og alt hva hjertet måtte begjære. Men du hopper jo ikke rett på bikkja og hytta på Gol. Du prøver deg fram. Tar en ting av gangen. Og finner ut hva du egentlig trenger (og har råd til!) underveis.
Og sånn er smidig metodikk. Du gjør deg opp en formening om i hvilken retning du skal, og så begynner du å lage noen enkle greier som du tror bringer deg i riktig retning. Og fungerer det bygger du videre på det, og fungerer det ikke prøver du noe annet. Og så finner du ut akkurat hva du trenger og hva du har råd til mens du lager det.
Og faktisk har det vist seg at dette fungerer like bra på programvareutvikling som på partnervalg. (Ok — jeg vet at det er noe som heter skilsmisser, men IT-systemer varer ikke evig de heller). Smidig utvikling gjør at du får raskere gevinster, at løsningene blir bedre og mer moderne, at feilvalg blir oppdaget og rettet tidligere, og ikke minst at det blir mye bedre samarbeidsklima mellom kunder og leverandører; vi kan bruke kreftene på å lage gode løsninger istedenfor å krangle om kontrakter. Og dette er ikke noe jeg bare påstår. Folk har faktisk forska på dette og dokumentert det.
Nå hadde jo ikke IT-bransjen vært IT-bransjen om det i kjølvannet av smidig tankegang ikke hadde dukket opp en hel haug med standarder og metodeverk med mystiske navn som Scrum og Kanban og XP og Lean Startup og så videre; alle med den hensikt å sette smidigheten i system. For det må jo være en viss orden. Akkurat som når du deiter. Du har spilleregler der også. Og noen foretrekker å kjøre løpet med konfekt, blomster og restaurant, mens andre inviterer på fotballkamp. Det er ulike retninger og ulike meninger og noe for enhver smak. Men jeg tenker at hvilken metode du bruker og om du følger metoden slavisk eller ikke, egentlig ikke er så viktig så lenge du skjønner hva du driver på med og vet omtrent hvor du skal. Så her støttes smidighet i valg av smidigmetodikk, altså.
Dessuten driver smidig på en måte og vokser utover også. Det begynte jo egentlig med de som satt og skrev kode, men i dag setter vi sammen team av folk med ulik bakgrunn som har ansvar for et produkt fra det er en ide til det er i full produksjon og blir videreutviklet. Og her er det haugevis med kule ord og uttrykk det er mulig å bruke og misbruke; DevOps, DevSecOps, BizDevSecOps, ODI, JTBD, Design Sprint, Growth Hacking, OKR og så videre, og så videre. Men det er en helt annen historie.
Og da passer det kanskje å runde av med ni råd til deg som vil ha på plass smidige metoder:
- Sett sammen en gjeng med dyktige folk som trives sammen og kan det som skal til for å lage en god løsning. Sørg for at forretningssiden også er med. De er viktige!
- Fortell gjengen hva du vil de skal løse for deg, ikke hvordan de skal løse det. La gjengen styre seg selv.
- Be om at de lager litt av gangen, og at det de lager skal fungere og løse noe for brukeren.
- Ikke lag milepæler og frister, men følg opp at gjengen lager ting og at tingene fungerer.
- Ikke være så opptatt av å dokumentere saker og ting. Det er bedre med en udokumentert løsning som fungerer enn en veldokumentert som ikke er lagd ennå.
- Prat sammen — ikke skriv!
- Og ikke klag når det oppstår feil — feil er grunnlag for å gjøre ting bedre. IT-prosjekter er komplekse og vanskelige fordi løsningene er sammensatte, og vi må regne med å feile litt.
- Og funker det ikke i det hele tatt, så be dem prøve noe annet.
- Og sist men ikke minst: Bruk hodet!