Jeg leste forleden et utsagn jeg kjente meg så godt igjen i.
Keith Braithwaite, en kjent foredragsholder fra QCON og Agile on the Beach, i dag ansatt hos Zuhlke Engineering Ltd. uttalte:
"…estimater gjør ikke det som de som ber om det tror at de gjør.
De som ber om estimater bør lære seg å stille bedre spørsmål. En bra indikator er følgende: Enhver forespørsel om estimater bør besvares med noe tilvarende en minimums, forventet, maksimum svar.
Om et svar på det formatet, uansett størrelse, ikke er akseptabelt — da vet du at du egentlig ikke har blitt bedt om et estimat. Du har blitt bedt om noe annet, og da er tiden inne for en nyttig — men antakeligvis utfordrende — diskusjon rundt avgjørelser og prioriteringer i en uforutsigbar verden".
«Når jeg blir bedt om å levere estimater er jeg ofte nysgjerrig på hva de skal brukes til.»
Når jeg blir bedt om å levere estimater er jeg ofte nysgjerrig på hva de skal brukes til. Grunnen til at jeg undrer meg, er fordi bruken av estimatene ofte gir meg en pekepinn på hva det egentlig er man spør etter. Hva er grunnbehovet som dette estimatet skal dekke?
Det er 3 hovedpunkter jeg opplever som utfordrende:
- Å tro at det gir suksess å levere på tid og kost.
- Å tro at når noen har sagt at det skal ta 5 timer så gjør det det — (og hvis det ikke gjør det er det unnasluntring og latskap).
- Å bruke en gjetning som grunnlag for hva man skal satse på.
La oss se på hver av disse tre punktene.
#1: Å tro at det gir suksess å levere på tid og kost
Jeg er nok ikke alene om å oppleve at jeg har videreformidlet estimater fra teamet som gradvis blir en målestokk på hvor vellykket prosjektet eller en leveranse er?
Altså; leverer man innenfor estimatet, så er leveransen per definisjon vellykket. Gjør man det ikke, så har man på en eller annen måte feilet. Selv om innsikten man har fått underveis kanskje har ført til at man leverer et bedre produkt, rent verdimessig.
14 dårlige vitser om programmering
Lenfle og Loch presiserer i sin artikkel "Lost Roots: How Project Management came to emphasize control over flexibility and novelty" at mye går tapt når man velger den tilnærmingen til prosjektstyring som vektlegger å levere på tid og kost.
Usikkerhet og kompleksitet i prosjekter fører til en undervurdering av arbeidsmengden. En undervurdert arbeidsmengde og et underbemannet team skaper tidspress, som kan føre til turnover i et allerede underbemannet team og resultere i forsinket prosjekt. Dette kan på sikt føre til at ledelsen konkluderer med at prosjektet ikke er levedyktig.
"The strict logic of ‘time and investment stages each leading to demonstrated progress’ must be loosened to allow for iteration and duplication in order to handle unforeseeable events."
For å håndtere uforutsigbarheten må vi skifte fokuset til hva prosjektet skal levere av verdi, slik at det gir rom for å kunne finne de riktige svarene underveis og dermed ha en større sjanse for å tilpasse endringer og uforutsette hendelser.
#2: Å tro at når noen har sagt at det skal ta 5 timer så gjør det det — (og hvis det ikke gjør det er det unnasluntring og latskap)
Har du pusset opp hjemme? Eller lovet noen å bli ferdig med en rapport som tok mye lenger tid enn antatt? Da vet du at sammenhengen mellom hvor mye tid man tror noe vil ta, og hvor lang tid det faktisk tar, kan være ganske lav.
Det som hjelper for å kunne konstatere med stor sikkerhet hvor lang tid noe kommer til å ta er at du har gjort det flere ganger før — og at det ikke kommer noen overraskelser underveis.
De færreste IT-utviklingsprosjekter er slik (se den forrige bloggposten min) og vi må slutte å oppføre oss som om de er det.
Kan det være at “estimat” egentlig betyr "fastpris" i hodet til den som ber om det? At man ved å be om et estimat føler at ansvaret for å oppfylle estimatet nå ligger hos den som ga det?
Sjur Bjørndalsæter (42) blir prosjektleder i Netlife
Det er ikke min erfaring at det hjelper å holde estimatet som en pisk over utviklerne, resultatet blir sjelden bedre av en stresset utvikler som skal prøve å rekke en dato han eller hun gjettet på for noen uker siden.
Vi kjenner det samme fra budsjettering:
"Man kan lett tro at man har styr på det hele når fremtiden er detaljbeskrevet med to desimaler i et styregodkjent budsjett. Dessverre blir dette ofte bare en illusjon av kontroll, selv om mange fortsatt føler at man har noe kontroll når man i alle fall kan avviksforklare i detalj når den virkelige verden nok en gang tok en annen vei enn planlagt."
- Bjarte Bogsnes (Beyond Budgeting)
Det å skulle levere når noen insisterer på at vi må gi dem en illusjon av kontroll er frustrerende, og det fører også til at vi jobber på en mindre effektiv måte enn vi kunne gjort hvis vi tok hensyn til uforutsigbarheten.
Jeg tror også at gjentakende opplevelser av at estimater brukes feil, trolig vil føre til at man prøver å sikre seg med store buffere på estimatene sine. Et lite tankekors for de som synes de får for høye estimater, kanskje?
#3: Å bruke en gjetning som grunnlag for hva man skal satse på
Jeg får alltid en dårlig magefølelse når våre estimater brukes som grunnlag for investeringsbeslutninger og prioriteringer.
Våre usikre gjetninger (se mer om dette i mitt forrige blogginnlegg) kan være med på å avgjøre hvilke prosjekter som skal startes, eller hvilken funksjonalitet som skal prioriteres.
«Er det riktig at våre gjetninger skal avgjøre om prosjekt X eller Y skal startes?»
Er det riktig at våre gjetninger skal avgjøre om prosjekt X eller Y skal startes?
Jeg mener Hans Georg Gemünden, Chair for Technology and Innovation Management, Technische Universität Berlin, treffer blink med følgende utsagn:
"Projects should be considered as investments, which should create value. Thus, I want to make a plea that we should control projects, programs, and portfolios according to the targeted outcome and impact, and not according to the input of financial and human resources, and how much time the project needed."
Nå tenker du kanskje at det er lett for meg å si at prosjektene burde vurderes ut fra den verdi de skal skape, men at det er vanskelig å få til.
Hvordan skal man beregne hva slags verdi som kan skapes, og ikke minst, hvordan kan man vite hvor mye man vil miste i verdi på å ikke lage noe?
Det skal jeg skrive mer om i en ny blogg-artikkel.
- Liker «la meg være i fred så jeg får gjort jobben min»-metoden
Men tall fra 560 norske utviklere viser at man ikke blir lykkeligere av å slippe Kanban og Scrum.