Sandhedens øjeblik

Nogle projekter bliver bare færdige til tiden uden de store problemer. Det er desværre de færreste.

Mange projekter er 90% færdige i størstedelen af projektets varighed. På et tidspunkt, ofte alt for sent, bliver det dog klart, at deadlines ikke kan overholdes og nogen må gå den tunge vej til kunden/ledelsen/styregruppen og bede om mere tid/penge eller (og det er en rigtig dårlig idé) - flere ressourcer.

I agile projekter leverer man hver anden uge, og efter nogle måneder har et udviklingsteam ofte en klar forståelse af egen kapacitet.

Omtrent på samme tidspunkt, får man et overblik hele projektet. Backloggen er næsten komplet og man har gennemført releaseplanlægning og estimeret alle kendte opgaver. De bedste teams estimerer opgavernes størrelse relativt til hinanden i f.eks i storypoints, da erfaringen viser at estimering i timer og dage ikke fungerer.

Så kommer det store øjeblik, hvor man summer storypoints i backloggen sammen og lægger 10% til 20% til, da der vil komme nye krav henad vejen.

Måske er der en kendt relasedato, så man kan regne baglæns fra og se hvor meget man skal nå i hver Sprint. Ellers kan projektet nu for første gang beregne en dato baseret på mængden af arbejde divideret med teamets kapacitet,. En dato som er noget ganske andet end den ønsketænkning og de gætterier, man ser i meget projektplanlægning.

Det er sjældent et smukt syn. Med mindre det er et super forkælet projekt, eller et projekt, der ikke er vigtigt nok, til at nogen har gidet sætte en deadline, er der næsten aldrig tid nok.

Istedet for at blive slået af fortvivlelse eller give op i resignation, kan man vælge at se det som en gave til projektet. Nu er det muligt for alle involverede, at tale om projektets sande status, i så god tid at man kan forholde sig til realiteterne det og gøre noget ved det.

Nu kommer tidspunktet, hvor man enten styrker samarbejdet mellem projektets forskellige dele, eller at alle graver sig ned i skyttegravene og beskylder 'de andre' for at være skyld i miseren.

Skal samarbejdet styrkes er det er vigtigt at alle bringer noget til bordet.

Produktejeren kan starte med at se på datoerne. Er der mulighed for at flytte dem, eller er det muligt at justere indholdet af projektet så noget bliver afleveret senere' Er der en simplere måde at implementere noget indhold på, end den oprindeligt planlagt'

Ligeledes må udviklingsteamet kaste et kritisk blik på sig selv. Er alt det vi gør hensigtsmæssigt' Er vores processer effektive' f.eks har mange teams har forstået budskabet om automatiske test, men jeg ser ikke så mange, der faktisk overvejer hvordan de med den mindste indsats laver de bedste test.

Hvis situationen bruges rigtigt, og alle bidrager til at gøre projektet til noget, man kan tro på, vil krisen lede til fornyet energi og motivation og i den sidste ende måske være det vendepunkt, der gjorde at projektet ikke blev endnu et projekt fra helvede.

Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Bent Jensen

Hej Kim,

Ja og nej. Det er rigtigt at jeg bruger ord som oprindelig stammer fra Scrum: Sprint, Backlog etc. De er efterhånden blevet almend begreber, som bruges i flæng af dse fleste der udvikler agilt, hvadenten det er Scrum efter bogen, eller en anden agil variant.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize