Slutterminer

Vi må leve med “harde” tidsfrister for når ting må være ferdig. Så det gjelder å ha en god strategi på hvordan vi håndterer dette, enten vi kjører tradisjonelt eller smidig. Som vanlig har smidig tilnæring noen fortrinn. Det finnes gode og dårlige begrunnelser for å sette tidsfrister. 

Dårlig motiverte tidsfrister

Mange mener det er motiverende og gir et sundt fokus å sette milepæler å jobbe mot. Man setter derfor frister som strengt tatt er unødvendige. Psykologen  Dr. Leslie Becker-Phelps skriver om dette i artikkelen How deadlines can be murder on motivation; hvordan kunstige slutterminer er begrenset til å gi ytre (ekstrinsisk) motivasjon, og at dette vil gå på bekostning av indre (intrinsisk) motivasjon. Den helhjertede, indre motivasjonen er det vi egentlig er ute etter mens – som Becker-Phelbs skriver – sluttermin-motivasjonen lett utvikler seg i helt feil retning og faktisk blir en de-motivator. Lystbetont arbeid som man i utgangspunktet setter stor pris på, kan gradvis utvikle seg i negativ retning, da det ikke lenger er lyst som er drivkraften, men snarere plikt eller i verste fall frykt for å mislykkes.

Programvareprosjekter styres ofte mot slutterminer som ikke alltid er velbegrunnede. Fristen er ofte satt av prosjektlederen i samråd med kunden og er ment som en slags forsikring om at leveransen ikke skal “trekke ut i tid”. Ofte avtaler de stilletiende en “hemmelig buffer” på slutten, slik at den reelle tidsfristen egentlig er senere (“vi har jo dårlig erfaring med slike programmeringsprosjekter”). Tanken er at slutterminen blir et styringsredskap basert på tidlige estimater.

Tidsfrister med fast omfang

Vi er vant med å se på omfanget av en leveranse som absolutt. Dette er naturlig, for det er jo slik det er i dagliglivet og i veldig mange prosjekter vi kan observere. Entrepenøren leverer hele broen, ikke bare deler av den. Vi klipper snorer og spretter (eller knuser) champagneflasker for å markere overlevering.

Vi har gjentatt dette til det kjedsommelige: Programvare er ikke det samme som å lage en bygning eller en “ting” som utgjør en opplagt leveranse. Programvare er nesten alltid gjenstand for en mer eller mindre kontinuerlig utvikling – en evolusjon. Tidsfrist mot en hovedleveranse er derfor unødvendig. Ikke bare er det unødvendig, men det er direkte skadelg! Alle som har vært med på slikt vet at stressnivået stiger voldsomt mot leveransetidspunktet. Og det er selvsagt i denne tilstanden, når tiden begynner å bli den altoverskyggende parameteren vi styrer etter, at vi ofrer det gode håndtverket. Vi tester det vi får tid til å teste, dokumenterer lite, får ikke tid til refactoring, selv om alle ser at det burde vært gjort. Vi lapper alt sammen etter beste evne og håper det beste. En uslåelig måte å maksimalisere dette stressnivået er å knytte dagbøter til slutterminen. Da kan du som kunde være helt trygg på at du må slite med anseelige mengder teknisk gjeld i systemet i årevis etter denne datoen.

Smidige slutterminer

Det er rikelig med gode eksempler på at harde terminer har sin berettigelse. Regnskapssystemer må gjerne leveres i ny versjon i forbindelse med årsavslutning. Andre systemer lages for å støtte et arrangement (OL på Lillehammer var en rimelig hard milepæl), og det er forhold som at markedsvinduet snart lukker seg, som gjør at vi trenger en absolutt frist. Så dette må vi takle.

Produktkø

Produktkø

Spørsmålet blir da: “hvordan kan vi styre mot en absolutt tidsfrist, uten å ende i dette uføret der stressnivået øker så mye at vi kaster det gode håndtverket over bord?”

I Scrum styrer vi med variabelt omfang (scope). Så lenge omfanget er variabelt, kan vi holde tid, kost og kvalitet fast. Hvilke implikasjoner har dette? Jo, det har flere, men først og fremst innebærer det at vi kan beholde roen og fokusere på det viktigste, nemlig å gi brukerne og interessentene mest mulig verdi uten å ofre langsiktig kvalitet.

Omfanget ligger altså i en kø med arbeid kalt produktkø, som til enhver tid er prioritert. De ulike elementene er også grovestimert. På denne måten kan vi vurdere de ulike elementene opp mot hverandre og etter hvert som vi nærmer oss slutterminen blir det tydeligere og tydeligere hva som vil komme med.

For at produktkøen skal bli et godt styringsredskap er det selvsagt viktig at vi har en formening om framdriften. Dette får vi gjennom å jobbe i korte iterasjoner og ved at vi grovestimerer produktkøelementene. Bruk gjerne relative størrelsestall på elementene, slik at vi kan skaffe oss empiri knyttet til hvor mange av disse tallene dette teamet i gjennomsnitt leverer i en iterasjon. Planning Poker er en fin teknikk for dette som sikrer at et helt team gjennom en strukturert prosess kommer fram til en felles forståelse av et element og et tall som representerer estimatet. Dette kalles ofte et Story Point.

Fordelen med denne styringsformen er at fokus hele tiden er på “hva er det aller viktigste i dette omfanget”. Det blir helt klart for kunden at han må engasjere seg i denne løpende prioriteringen og bidra til at prosjektet gjør gode valg.

På denne måten vil vi ofte ende opp med et ganske minimalistisk system som har visse mangler. (Vi vil fremdeles estimere feil og vi er fremdeles notoriske optimister, så jeg tror ikke vi skal ha illusjoner om at estimatene vil være veldig nøyaktige.) Så vi kan sette i drift et system som har verdi og som gjør jobben, men som alle vet må videreutvikles senere.

Hovedgevinstene ved variabelt omfang:

  1. Vi unngår det høye stressnivået som forleder oss til å ofre kvalitet og tolerere teknisk gjeld.
  2. Systemet blir enkelt og ukomplisert der manglene i systemet er et resultat av bevisste valg.

 

 

 

Posted on April 14, 2013 at 2:49 pm by gamsjo · Permalink
In: kontrakt, ledelse, prosjektledelse, Scrum · Tagged with: , , ,

3 Responses

Subscribe to comments via RSS

  1. Written by Det smidige hjørne » Den aller viktigste faktoren…
    on 12/05/2013 at 5:34 pm
    Reply · WordPress › Error