Som produktleder er problemløsning en stor del av hverdagen, og det finnes mange ulike måter å tilnærme seg problemløsning på. Det å ha et bevisst forhold til hvordan du løser problemer sammen med produktteamet kan ha mange gode ringvirkninger, i form av bedre effektivitet og bedre beslutningsprosesser. I denne bloggartikkelen vil jeg dele et rammeverk, som du som produktleder kan ta med deg i verktøykassen og anvende fra og med i morgen om du vil.
En produktutviklingsprosess og det daglige arbeidet i et produktteam kan føles kaotisk i ulike faser av utviklingen, avhengig av hvilke utfordringer man står ovenfor. Bevissthet rundt hvordan du som produktleder tar tak i ulike problemer kan resultere i at du evner å rydde vei for teamet til å fokusere på det arbeidet de har å gjøre, og igjen bidra til å skape tydelighet og retning.
Cynefin, uttales ky-ne-vin, er et rammeverk for problemløsning som anerkjenner at ulike utfordringer krever ulike tilnærminger til problemløsning, handling og beslutningstaking. Rammeverket ble utviklet for å hjelpe ledere med å forstå utfordringene de står ovenfor, og til å ta beslutninger i en passende kontekst. Ved å skille mellom ulike områder for problemløsning knyttet til selve problemet, anerkjenner Cynefin at handlingene våre må samsvare med virkeligheten vi befinner oss i. Dette hjelper ledere med å utvikle en bevissthet om hva som virkelig er komplekst og hva som ikke er det, og til å respondere deretter, slik at mindre energi kastes bort på feil beslutninger.
Cynefin-rammeverket er og har blitt brukt i flere ulike sektorer: enten det er teknologi, strategi, politiarbeid, internasjonal utvikling, offentlig politikk, militær, antiterrorisme, sikkerhet, energi, helsevesen, salg eller utdanning, så har rammeverket hatt noe å tilby.
Cynefin definerer seks handlingsmåter vi tilnærmer oss håndtering av problemer på. Sanse, kategorisere, respondere, analysere, sondere og handle. I modellen vises de ulike handlingsmåtene med forklaringer.
Egenprodusert modell 1
Nedenfor illustreres rammeverket gjennom modell 2, med fire områder som omslutter en midtre gråsone og med en utstikkende splittet strek nederst i modellen. Videre vil jeg ta deg gjennom betydningen av de ulike områdene og elementene i modellen og hva som kjennetegner dem.
Egenprodusert modell 2
Ofte er vi her og handler fra et ubevisst sted, basert på personlige preferanser. En kan oppleve å være forvirret og usikker på hvilken del av rammeverket problemet tilhører, og dette resulterer ofte i at man tar feil beslutninger.
Når vi søker til dette området i modellen er det fordi forholdet mellom årsak og virkning er ukjent, og bare kan avdekkes i etterkant. Det finnes ingen beste praksis for problemet du søker å løse, og vi kan da si at problemet er komplekst. All praksis i dette området blir regnet som fremvoksende praksis, ettersom løsningen på problemene ikke er kjent og blir utviklet.
Når vi arbeider innenfor kompleks problemløsning sonderer vi problemet med gjentatte eksperimenter, ved å utforske og designe nye løsninger, evaluere resultat og respondere. Årsaker og virkninger er derfor kun kjent i ettertid.
Det er rett å søke til dette området av rammeverket når vi står ovenfor et problem med en kjent løsning. Her kreves det analyse for å avdekke sammenhenger mellom årsaker og virkninger. Vi må for eksempel grave i forskning, konsultere eksperter eller gjennomføre egne analyser for å finne en god løsning. Vi identifiserer problemet, analyserer det og responderer. Årsaker og virkninger er påviselige av eksperter, eller gjennom undersøkelser. Kjennetegnet er at vi fortsatt er innenfor kjent terreng, og kan prøve og feile med eksisterende løsninger.
Dette området av rammeverket søkes til når vi kjenner til beste praksiser og problemene har kjente og velprøvde løsninger. Både årsaken og virkningen til problemet er kjent. Her identifiserer vi problemet, kategoriserer det og responderer.
Når problemet er kaotiske og lite oversiktlig, befinner det seg i denne delen av rammeverket. Typiske eksempler på situasjoner der vi har kaotiske problemer er kriser eller katastrofer, og beslutninger må tas innenfor et trangt tidsrom basert på ufullstendig informasjon. Fokuset må være på å komme seg gjennom helskinnet. Både årsak og virkning er ukjent. Vurderinger og handlinger dominerer beslutninger. Når problemet er «ute av fare» kan det flyttes inn i Kompleks.
Den splittede streken nederst i modellen er ikke tilfeldig, og betydningen av denne er balanse mellom klar og kaotisk. Det vil si dersom vi behandler alle problemer som klare, kan vi ende opp med å anta at ingenting vil endre seg og at det som alltid har fungert også alltid vil fungere fremover. Men når noe plutselig endres, beveger vi oss raskt inn i kaotisk og da blir utfordringene ofte vanskeligere å løse.
Når vi som produktledere står ovenfor en utfordring og vi skal benytte oss av Cynefin for problemløsning, er første prioritet å forstå hvilken av rammeverkets fire områder problemet befinner seg i. Dersom du står i en klar situasjon handler det i praksis om å bla opp i relevant litteratur, finne løsningen og iverksette denne. I en komplisert situasjon vil det kanskje måtte gjøres ekstra forskning, ekspertkonsultasjon eller risikoanalyse for å finne en løsning. I en kompleks situasjon må vi utarbeide nye løsninger og måle effekten av disse i etterkant. Og i en kaotisk situasjon handler det mest om å komme seg gjennom og opparbeide kunnskap om problemet i etterkant.
Sett i perspektiv av Cynefin, kan vi si at det smidige rammverket SCRUM er designet for å balansere mellom kompleks og komplisert problemløsning. Digital produktutvikling er et eksempel på et komplekst problem, siden vi ikke med sikkerhet kan forutse hvilken funksjonalitet brukerne av løsningen ønsker seg. Vi kan heller ikke vite hvordan de kommer til å anvende løsningene i ulike arbeidsflyter eller hvilken teknologi som er best egnet for å levere løsningen.
Mange organisasjoner har behandlet produktutvikling som om det er et komplisert problem, og derfor brukt mer og mer tid på å få eksperter til å analysere problemet på forhånd. Ved å benytte feil tilnærming til å løse problemet, altså ved å behandle det som et komplisert problem fremfor som et komplekst problem, blir ikke resultatene som ønsket og man kaster potensielt bort mye tid og ressurser på uhensiktsmessige aktiviteter.
SCRUM derimot behandler produktutviklingsprosessen som om den er kompleks, ved å sette sammen et kryssfunksjonelt produktteam som arbeider sammen for å løse problemet. Innen SCRUM legges det så begrensninger på teamet, ved å prioritere og dekomponere problemene som skal løses, slik at prioriteten blir lagt på det viktigste arbeidet først.
Det prioriterte arbeidet utvikles så i sprinter, det vil si en tidsbegrenset periode på 1 til 4 uker. Selve sprintene utføres som om at vi står ovenfor et komplisert problem, der vi sanser, analyserer og responderer. Dette gjøres i praksis gjennom en backlog refinement og sprintplanlegging, med mål om å lage en plan for den kommende sprinten. Vi kan se dette som en ekspertanalyse.
Underveis i sprinten beveger vi oss mellom kompleks- og komplisert-problemløsning, planlegger underveis og sanser om det planlagte arbeidet fortsatt gir mening under daglige møter(standup), og endrer planen etter behov. Sprint review og retrospektiv tillater oss å sanse om vi fikk ønsket utfall fra sprinten, som også kan sees på som et eksperiment. Her arbeider vi innenfor det komplekse området der vi sonderer, sanser og responderer. Dette gjøres gjennom forsterkende eller dempende endringer i backlogen, justeringer av utfall i sprint review og systemendringer etter utfall av retro.
Fra tid til annen vil en organisasjon velge å gå inn i kaos for en kortere periode. Dette kan eksempelvis være i et hackaton. Disse kaos-periodene gjøres trygge ved å begrense tiden som brukes i kaotisk problemløsning, for så i ettertid studere utfallet av perioden, for å finne ut hvordan man kan nyttiggjøre seg av dem.
Som produktleder kan du benytte deg av dette rammeverket, for økt bevissthet rundt hvordan du tilnærmer deg problemløsning i produktteamet. Som Cynefin-rammeverket illustrerer, er det å ha en uordnet/uviten tilnærming til problemløsningen ofte der vi gjør feil og handler ut ifra personlige preferanser, som igjen resulterer i unødvendig sløsing av ressurser. Om du ikke allerede har arbeidet med dette rammeverket så er det absolutt anbefalt å gi det et forsøk.
Synes du dette var interessant? Ta gjerne kontakt med meg for en prat. Du finner meg på LinkedIn og du er hjertelig velkommen til å sende meg en epost.
- Lill
Relaterte artikler og videre lesning