Hashtagen #NoEstimates har hatt en imponerende aktivitet på twitter i drøye to år nå, med samme tema: Kan vi ta gode beslutninger uten å estimere? Det ville jo vært besnærende om det var mulig! For alle som har vært ute en IT-vinterdag før vet at estimering har en del problematiske sider ved seg. Temaet er fremtredende på de fleste konferanser med fokus på smidig systemutvikling. Spørsmålet er når prosjektstyringsmiljøet fatter interesse for temaet.
Problematiske estimater
For det første er det svært vanskelig. Behovene og kravene vi skal tilfredsstille, er ulne. Dessuten har vi ikke gjort det før. Hvis det var gjort før, kunne vi bare levert det, ikke sant? Så for de aller fleste estimater må vi påregne en betydelig usikkerhet. Det hjelper heller ikke så mye å knytte estimert usikkerhet til estimatet, da også dette estimatet blir usikkert ...
Det tar tid. Det går med andre ord an å spare verdifull tid – og dermed penger – ved å la være. Når vi skal vurdere en IT-satsning og estimere kostnadene og leveransetidspunktet, vil vi måtte forsøke å «tenke på alt», slik at vi ikke går på en smell og glemmer å ta med noe som for kunden er opplagt. Så vi blir nærmest tvunget til å gjøre en god del arbeid og bryte funksjonaliteten ned til et ganske detaljert nivå. Mye av dette arbeidet vil være unødvendig siden vi her vil fokusere på både viktig og uviktig funksjonalitet.
Den blir misbrukt til å følge opp framdrift. Et estimat blir lett oppfattet som en forpliktelse, nærmest et løfte. Når en utvikler eller en leverandør støter på uventede ting (dette bør ikke være uventet innen IT-utvikling!) så havner vi på etterskudd i forhold til plan. Om prosjektledelesen eller andre følges opp mot en plan basert på estimater vi det være fristende å forsøke å jobbe fortere. Software kan lages fortere ved å kutte hjørner og altså ofre det gode håndtverket. Dette vil i sin tur kunne gi stor teknisk gjeld og dermed dårlig vedlikeholdsvennlighet.
Les også: IKT i NAV – hva gikk galt?
Hva er alternativet?
Jeg vet ikke om det er fornuftig å ikke estimere i det hele tatt, men jeg vet at ved å dele opp problemet i små biter som blir levert etter hverandre får vi noen besnærende muligheter. Dette går i korte trekk ut på å bruke noen få iterasjoner på å skaffe empiri omkring hastigheten et team kan levere funksjoner i.
Hvis vi har et fast, tverrfaglig team som gjør jobben, kan vi ta beslutningen om å sette i gang utvikling uten å forplikte en stor leveranse langt inn i framtiden. Vi har en hypotese om at dette teamet vil kunne klare å levere verdifulle funksjoner som vil kunne tilfredsstille våre behov, og så investerer vi i et lite antall iterasjoner. Da vil vi kunne telle opp hvor mye funksjonalitet de leverer i en typisk iterasjon, hvilket vi så bruker til å ekstrapolere framover i tid.
Eksempel på ekstrapolering basert på erfaring av Sven Schnee
Her gjelder det altså å velge rammeverk som støtter raske iterasjoner og hyppige leveranser. Bruker vi Scrum, vil vi typisk avse fem prosent av kapasiteten til å grovestimere funksjonene som ligger foran oss. Man bruker gjerne relativ estimering og måler hastigheten i Story Points.
Med Kanban-metoden vil mange si at vi klarer oss med bare å telle opp ferdige elementer (gjerne User Stories) levert per tidsenhet. Uansett Scrum eller Kanban kan vi sannsynliggjøre omtrent når dette teamet har levert noe som vil ha betydelig verdi for oss. Faste team har også den besnærende effekten at kostnadene vil være ekstremt lett å kalkulere og ekstrapolere.
Hvordan ta beslutninger uten estimater?
Kunder vil naturlivis spørre «hva vil det koste» og «når kan vi få det» og de blir forståelig nok skuffet over at svaret er «vet ikke». Men selv om vi ikke vet så mye om det endelige produktet, kan vi allikevel gi kunde et godt beslutningsgrunnlag. Kunden vil kunne få bedre styring og kontroll på satsningen enn det som er vanlig i IT-prosjekter – etter at noen iterasjoner er gjennomført. Vi må altså ha erfaringer om fortiden for å kunne spå om framtiden. Vi skaffer oss empiri og baserer styringen på dette.
Etter at vi har fått empiri om hastigheten til teamet, vil vi kunne besvare spørsmål av typen:
Når vil vi sannsynligvis nå en nytteverdi som er høyere enn kostnadene?
Kjører dette teamet fort nok, eller bør vi bemanne opp? Kanskje sette på et helt team til?
Skal vi skrinlegge hele satsningen, siden teamet ikke oppnådde den hastigheten vi hadde håpet?
Har vi for svakt team / feil team til å gjøre denne jobben?
Bør vi revurdere hele ideen, siden noen antagelser viste seg å ikke være til stede?
Beslutningstakere har gjerne en klar mental modell hva det vil si å utvikle IT-systemer: Analyse, forprosjekt, estimering, planlegging, ny estimering, oppbemanning, gjennomføring, leveranse, nedbemanning. Man gjør dette nærmest av gammel vane, men det er ikke nødvendigvis den beste og mest effektive modellen. Og den medfører større økonomisk risiko enn nødvendig. Så snart man lærer seg å splitte problemet opp i små, prioriterte inkrementer får man også muligheten til å effektivt se fremover uten å basere seg på svært usikre estimater.
Leste du denne?– Du kommer ingen vei uten IT-fiaskoer
