Om vi skal gjennomføre et tiltak agilt eller som fossefall, er et spørsmål om å velge riktig metode til riktig formål, og å anerkejenne at et tiltak, enten det er agilt eller tradisjonelt, kan - og bør - inneholde elementer av begge.
Det handler om å bruke riktig verktøy til jobben. For vi bruker vel ikke Word til å regne ut ting, gjør vi vel?
Jeg sa i et tidligere innlegg om smidige kontra tradisjonelle tilnærminger, at det i den agile diskusjonen ofte blir en drøfting om enten-eller, mens jeg mener det burde handle om både-og. For å fremheve et poeng rundt sunn fornuft, sa Halvard Kilde en gang i et foredrag om eierstyring av investeringer, at «Word brukes til å skrive og Excel brukes til å kalkulere». Dette synes jeg er ganske passende å ta frem nå.
Det tidligere innlegget jeg snakker om endte opp i (etter min mening veldig gode) diskusjoner, blant annet på digi.no, rundt spørsmålet om behovet for styring knyttet til smidig gjennomføring av tiltak.
Utfordringen med slike ordvekslinger er at det av og til kan være vanskelig å ikke bli opphengt i våre egne persepsjoner om hvordan ting er – eller bør være. Jeg pleier å si til mine studenter at vi som mennesker er forutinntatte av natur. Vi er etter min mening ute av stand til å være fullstendig objektive, nettopp fordi vi er mennesker med erfaringer, meninger og følelser – og ja, persepsjoner og preferanser.
Ikke la deg styre av det som føles komfortabelt
Våre persepsjoner og preferanser gjør også at vi ofte velger det vi kjenner godt eller foretrekker når vi står overfor valg av tilnærming. Eksempelvis møtte jeg nå nylig på et prosjekt hvor det var så tydelig hva som skulle leveres, hvorfor, og hvordan, men hvor prosjektledelsen og teamet likevel var overbevist om at prosjektet måtte kjøres agilt. Hvorfor må det det? Er det fordi teamet mener at det fremdeles er rom for kontinuerlig tolkning og avklaring? Eller er det fordi de ganske enkelt foretrekker å jobbe agilt fremfor å «bare levere det som er avklart»?
Kanskje nettopp på grunn av disse persepsjonene og preferansene, er det vi mennesker trenger litt «kart og kompass» når vi skal finne veien i en jungel av muligheter, og når vi skal velge riktig verktøy for jobben vi står overfor. Akkurat som da vi lærte oss å bruke Word og Excel til deres respektive formål, mener jeg vi kan ha nytte av et kart som gir oss en pekepinn. På den måten får vi ikke bare en pekepinn på hva som er mulig å gjøre, men på hva som er fornuftig å gjøre.
Stikk fingeren i jorda: Hvordan gå frem på en fornuftig måte
Jeg deltok nylig på et kurs i design thinking. Her ble jeg påminnet om hvor viktig det er å «jorde» oss når vi står overfor en problemstilling, for å prøve og unngå å falle i persepsjonens og preferansens felle, og heller belyse problemet og spørsmålet med fornuft, logikk og felles forståelse.
Hva er det vi egentlig prøver å finne svar på? Hvordan bør vi mest fornuftig gå frem for å løse problemet? I det samme kurset ble jeg også påminnet om en figur som jeg har tatt meg friheten til å «spisse» enda litt mer, nettopp for å prøve å gjøre den enda tydeligere.
I figuren ser vi at der hvor vi står overfor en kjent løsning på et kjent problem, er det naturlig å benytte en «tradisjonell» tilnærming (eller fossefall om du vil). Likeledes sier den at der vi står overfor et kjent problem med en ukjent løsning er det mest naturlig å innta en mer utforskende tilnærming, altså agil.
Men nå står vi ikke bare overfor spørsmålet om agil eller ikke lenger. Vi står også overfor spørsmål om hvorfor tiltaket eller investeringen bør organiseres som prosjekt (hvis i det hele tatt), og om prosjektet i så fall bør ha en fossefalls- eller smidig tilnærming. Vi står overfor spørsmål om hvorvidt utvikling bør produkt-orienteres, og om vi har tilstrekkelig med fokus på innovasjon i vår tilnærming. I tillegg dukker det opp spørsmål om hvordan vi skal organiseres oss; i teams, squads, tribes osv.
Figuren over gir oss svar på noen – ikke helt ubetydelige – spørsmål. Som at vi bør kjøre fossefall når vi kjenner både problem og løsning og at vi bør kjøre agilt når problemet er kjent, men løsning er ukjent. Den gir oss også en pekepinn på at produktorientert, kapasitetsstyrt utvikling kan være hensiktsmessig i en «forbedringsportefølje» hvor man har en løsning (eksempelvis IT systemene i en bedrift), som kontinuerlig bør videreutvikles for å tilpasses organisasjonens og brukernes endrede behov. Sist, men ikke minst, sier den at hypotesedrevet design (ekte explorative om du vil) passer aller best der hvor vi skal utforske både problemet og løsningen.
Ikke enten-eller, men både-og
At figuren sier «gå for en tradisjonell tilnærming» betyr selvsagt ikke at du alltid skal gjøre det, ei heller at akkurat det valget trenger å være gjeldende for hele prosjektet. Eksempelvis er det ofte i tidligfase av prosjekter mest hensiktsmessig å innta en utforskende tilnærming, selv om prosjektets gjennomføringsfase kanskje naturlig bør gjøres som fossefall.
Likeledes kan du ha prosjekter hvor noen deler av gjennomføringen bør gjøres som fossefall, mens andre bør gjøres mer smidig. Det er, som jeg sa i den nevnte diskusjonen, ikke et spørsmål om fugl eller fisk, men heller som Ole Brumm (faktisk aldri) sa: ja takk, begge deler (faktasjekk: Ole Brumm sa aldri egentlig det, det fremkommer kun i den norske oversettelsen av Torbjørn Egner).
Figuren gir oss ikke alle svarene, men den gir oss en pekepinn på hvor vi bør rette blikket. Den gir oss i så måte også et kompass vi kan navigere etter i vår søken etter løsning og tilnærming, eller svar på spørsmålet om hvilket verktøy vi bruker til hvilket formål.
Vil du lære mer om når det kan være nyttig å ha en smidig tilnærming?
Krav om hurtige endringer og løpende justeringer skaper behov for en arbeidsflyt hvor man jobber iterativt og realiserer verdi gjennom hele eller deler av prosjektet. Derfor går mange over til å bruke smidige metoder i prosjekter. Men når skal man gjøre det, og hvordan går man frem?
På vårt kurs om Smidighet i prosjekter vil du få en grunnleggende innsikt i nettopp dette.
