I løvens hule

Det var med skrekkblandet fryd jeg tok plass på første rad på Dataforeningens arrangement Smidige metoder i Prosjektgjennomføring her om dagen. Jeg skulle som tredje og siste taler forklare alle de 80 fremmøte prosjektlederne at Prosjektet som arbeidsform har en del svakheter. Selv om “Smidige” var det første ordet i tittelen på dette medlemsmøtet, merket jeg raskt at forståelsen av Smidig ikke var helt i henhold til Agile Manifesto. Ikke helt uventet. Jeg åpnet mitt foredrag med å be de deltagerne som hadde et forhold til Agile Manifesto om å rekke opp hånda. Mindre enn en tredjedel responderte. Men de fleste var antageligvis kommet for å lære – og det er jo bra.

Foredraget ligger på Slideshare

Har Prosjektet skylda?

Jeg mener faktisk at Prosjektet har en betydelig del av ansvaret for kvalitetsproblemene og den enorme kompleksiteten vi ser i IT-systemene. Dette med programvarekompleksitet er ikke noe nytt, jeg husker vi for 10 år siden også var veldig opptatt av “kompleksitetskrisa” vi står overfor. Hvordan kan Prosjektet få skylda for dette da? Jeg tror hovedproblemet er at i Prosjektet gir vi alt for mye ansvar til en midlertidig organisasjon som jobber mot en sluttermin. Denne overleveringsdatoen blir veldig styrende og de som jobber i prosjektet vil fokusere på å oppfylle avtalen på dette tidspunktet. Dette hensynet har en tendens til å overskygge ønsket om å skape mest mulig verdier for brukerne av systemet. Dette er ikke særskilt IT-problem, et godt eksempel på dette problemet har vi sett i vegbransjen se senere årene:

HVORFOR?

Jeg tror ikke vegentrepenørene er noe spesielt umoralske eller slurvete. De tar en kalkulert risiko og de regner med at de ikke vil bli stilt til ansvar for eventuelle problemer som kan oppstå senere. I IT-bransjen er sjansen for å “slippe unna” med dårlig håndtverk betydelig større. Og forskjellen på godt og dårlig håndtverk er mye mer flytende. Programmering har ikke forskrifter, retningslinjer eller standarder. Det finnes anerkjente mønstre (Patterns) og det begynner å bli en etablert forståelse av “best practice” innen systemutvikling. Men slikt har kundene typisk inget forhold til.

The Iron Square

The Iron Square

Vi ofrer selvsagt kvalitet fordi det koster noe. Det koster typisk både tid og penger. Når penger og/eller slutterminen blir styrende blir vi tvunget til å velge, og spørsmålet blir fort “hvor lite kvalitetsfremmende tiltak kan vi slippe unna med“. Etter min erfaring er ikke dette noe som sies høyt, men enhver håndtverker vet at dette er en realitet.

Programvarekvalitet?

Om et prosjekt virkelig har et brennende ønske om å etterlate seg et velstrukturert, lettfattelig og fremtidsrettet system så finnes det en hel del gode metoder og praksiser man kan velge å benytte. Refaktorering  – gjerne på flere nivåer – synes å være en betingelse. Etter hvert som systemet utvikler seg vil gamle design- og arkitekturbeslutninger stå for fall. Vi bør gjøre en jobb under overflaten som gjenoppretter systemets struktur. (Se presentasjonen til Karianne Berg fra Javazone : Strukturert refaktorering).

Dengang jeg programmerte brukte vi peer-reviews mye. Vi leser hverandres kode før den slippes inn i systemet. Dette er en enkel og kraftfull praksis som både fører til bedre lesbarhet, færre feil og kompetansespredning. Et godt alternativ til dette kan være par-programmering.

I de senere årene har det kommet en hel del nye teknikker og konsepter: Test Driven Development (TDD), Acceptance Test Driven Development (ATDD) Behavior driven development (BDD), Clean Code, etc etc..

Felles for alle disse metodene er jo at de har en prislapp. Verdsetter kunden kvalitet så høyt at han alltid er villig til å bruke tid og penger for dette, selv om slutterminen da ryker? De finnes nok, men jeg har aldri sett en slik kunde. The Iron Square er ubarmhjertig – skal du være sikker på at systemet i det lange løp er vedlikeholdsvennlig nytter det ikke å prioritere ned kvalitetsfremmende teknikker og metoder. Litt av problemet her er nok at vi er vant til at vi kan velge oss et kvalitetsnivå for en vare. Dette er en farlig tanke når det gjelder programvare (som Martin Fowler har beskrevet her i sin “Tradable Quality Hypothesis”). Kunden vil alltid måtte betale for denne manglende kvalitetene senere en gang i form av høyere vedlikeholdskostnader. Vi kaller dette gjerne teknisk gjeld. Som all annen gjeld har den renter (høyere endringskostnader) og den skal betales tilbake på et senere tidspunkt.

Vi må begynne ta virkeligheten på alvor

De fleste IT-kundene utvikler sine systemer mer eller mindre kontinuerlig. Hvorfor ikke da etablere en kontinuerlig organisasjon? På denne måten kan vi slippe unna denne slutterminen som blir så styrende. I Scrum er det ingen prosjektleder og det er ikke tilfeldig. Det er jo ikke noe prosjekt heller – det ble laget for produktutvikling.

Prosjekter kommer og går, Scrum består

Prosjekter kommer og går, Scrum består

De mest vellykkede smidige organisasjonene har ganske permanente Scrum team som utvikler systemene. Produkteier og utviklingsteamene vet at de skal jobbe med dette produktet over lang tid. Ingen sluttermin. Dermed blir det også i deres egen interesse å holde kvalitetsnivået så høyt som mulig – for hvis ikke blir de selv forsinket.

I noen perioder et det stor aktivitet i andre mindre. Det er unødvendig med en egen “vedlikeholdsfase”. En Scrum-organisasjon lar seg lett skalere opp og ned, uten at man dermed behøver å lage revolusjon og etablere en ny organisasjon av den grunn. Om man ønsker det kan man enkelt starte og stoppe prosjekter “på utsiden” av Scrum. Disse prosjektlederne må da legge fram gode kost/nytte analyser og på den måten få Product Owner til å slippe dem til høyt oppe i Product Backlogen. De er med andre ord interessenter på lik linje med de andre.

Jeg tror på ingen måte Prosjektets tid snart er omme i IT-bransjen. Men jeg tror denne arbeidsformen vil få mindre og mindre betydning både i offentlig og privat sektor.

 

 

 

Posted on October 21, 2011 at 11:12 am by gamsjo · Permalink
In: prosjektledelse, Scrum · Tagged with: , ,

4 Responses

Subscribe to comments via RSS

  1. Written by Blå
    on 16/11/2011 at 4:55 pm
    Reply · WordPress › Error