Hva har spillerne i nettspillet Farmville til felles med medlemmene i en prosjektgruppe? Ved første øyekast ikke mye – den ene bygger en virtuell gård, den andre utvikler et produkt. Men ser man nærmere etter, har de det til felles at de begge investerer tid og krefter i å nå sine mål.
Ugjenkallelige kostnader – Ugjenkallelige kostnader
Hva skjer når en Farmville-spiller på et tidspunkt ikke lenger har lyst til å spille? Den hardt opptjente fremgangen i spillet forsvinner igjen. Og det er her problemet begynner: Beslutningen om å fortsette å spille tas ikke rasjonelt. I stedet for å tenke på fremtidige kostnader og fordeler, tenker man på hvor mye tid man allerede har investert i spillet. Denne investerte tiden kan ikke gjenvinnes. Men for at det ikke skal bli "tapt tid", bestemmer spilleren seg for å bruke mer ressurser.
Så selv om det rasjonelt sett hadde vært riktig å avslutte spillet, siden det ville vært mer fordelaktig å bruke tiden på en annen måte, fortsetter du å spille. Et godt konsept som Farmville-utviklerne har kommet opp med.
Eksempel på "ugjenkallelige kostnader
Følgende eksempel viser hva dette har med et prosjektteam å gjøre: Etter en lang produktutviklingsfase er det ferdige produktet endelig klart. Teamet er fornøyd, for det har tross alt lagt ned mye ressurser (både tidsmessig, kognitivt og økonomisk) i utviklingen. Neste trinn er presentasjonen for kunden.
Teamet går optimistisk inn, men kommer rystet ut: Kunden har forestilt seg det ferdige produktet på en annen måte, kravene har endret seg. Nå står teamet overfor en avgjørelse: Enten starter de fra bunnen av og utvikler et nytt produkt, eller så beholder de produktet som allerede er utviklet (men som ikke oppfyller kundens behov) og gjør noen små endringer.
Rasjonelt sett bør teamet bestemme seg for å utvikle et nytt produkt som oppfyller kundens krav og ønsker. Hadde det bare ikke vært for alle de ressursene som allerede er investert i utvikling –, disse dumme ugjenkallelige kostnadene.
Hvorfor kan vi ikke gi slipp?
Den Feilslåtte kostnader beskriver nettopp dette tilfellet, der det investeres ytterligere ressurser i noe som har vist seg å være ikke-målrettet eller til og med feil (Arkes & Blumer, 1985). Personer eller team som er utsatt for denne beslutningsfeilen, har vanligvis tre ting til felles (Brockner, 1992):
- De har allerede investert mye tid, penger og arbeid.
- De investerte ressursene førte ikke til suksess.
- De kan bestemme seg for hva de skal gjøre nå: investere mer ressurser i prosjektet eller avbryte det.
Spørsmålet er hvorfor vi prøver å redde et skip som allerede har sunket. Psykologen og nobelprisvinneren i økonomi, Daniel Kahneman, mener med sin Prospektteori en forklaring klar: Folk er redde for tap (Kahneman & Tversky, 1979). Denne frykten går så langt at de heller investerer i den usannsynlige muligheten for å lykkes med et dødsdømt prosjekt enn å akseptere en sikker fiasko.
Sunk Costs vs. kundeorientering – Scrum som løsning?
Det er åpenbart at team som tviholder på mislykkede prosjekter, går på bekostning av kundefordelene. Men hva kan teamene gjøre for å unngå å bli Feilkalkulasjon med nedsunket kostnad til å bukke under? Ett av svarene ligger i smidig arbeid. Der er kundeorientering et av de viktigste prinsippene. Med denne prioriteringen av kundeverdi kan man unngå å investere enda mer ressurser.
Når Scrum-team jobber, er kunden involvert i hele utviklingsprosessen, slik at man raskt kan reagere på endrede kundebehov. Den kontinuerlige utvekslingen sikrer at det ikke oppstår et sjokk på slutten av utviklingsfasen når det blir klart at kunden hadde forventet et annet produkt.
Vi er villige til å forkaste arbeid som er gjort, hvis ny innsikt i kundenes behov krever det. (Echometer-artikkel)
Konkret betyr dette at teamene må jobbe i korte tidsintervaller. Sprints arbeid. I begynnelsen bestemmes det hva det skal jobbes med de neste ukene. På slutten av sprinten sjekkes det om de fastsatte målene er oppnådd. Brukerhistorier er et viktig verktøy som Scrum-team bør bruke. Disse oversetter kundens krav til en brukersentrert uttalelse om produktet i henhold til formatet:
Som Rulle
Når brukerhistoriene er opprettet, overføres de til produktbackloggen og danner det innholdsmessige grunnlaget for utviklingsteamets arbeid. I likhet med mange andre konsepter i Scrum er ikke brukerhistorier statiske: Hvis kundens krav endres, endres også brukerhistorien.
Dette muliggjør en ekstremt høy grad av kundeorientering. Siden Scrum-team jobber selvorganisert, er det viktig å analysere brukerhistoriene fra forrige sprint i sprintretro. For eksempel kan man samle inn årsaker til hvorfor en bestemt historie gikk bra eller dårlig, for å sikre kontinuerlig forbedring.
Ønsker dere å utvikle dere som team? Og ta hensyn til de nyeste psykologiske funnene? Da anbefaler vi teamworkshopen vår Retro Tool. Her er Holgers erfaringer med det:
I et nøtteskall...
Scrum-teamenes iterative tilnærming og den konstante gjennomgangen av kundenes behov bidrar til å unngå irreversible kostnader. Produktinkrementene som utvikles i sprintene, bør helst ikke være for ressurskrevende. Dette fører til at teamet forplikter seg til de nye målene når kravene endres. Har du allerede opplevd problemet med ugjenkallelige kostnader i teamet ditt? Prøv å ta opp problemet i et retrospektiv og utvikle løsninger sammen!
Og hvis du er interessert i enda flere metoder for å øke prestasjonene dine i teamet, kan du for eksempel lese om dem i våre Artikkel om den forbløffende sannheten bak den smidige tankegangen se.
Kilder
Arkes, H. R. & Blumer, C. (1985). The psychology of sunk cost. Organisasjonsatferd og menneskelige beslutningsprosesser, 35, 124–140.
Brockner, J. (1992). Opptrapping av forpliktelse til et mislykket handlingsforløp: Mot en teoretisk fremgang. Academy of management Review, 17(1), 39-61.
Kahneman, D. & Tversky, A. (1979). Prospektteori: En analyse av beslutninger under risiko. Econometrica, 47, 262–291.
