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 · Permalink

    Dette er nok en av de tingene jeg liker mest med Scrum. Hvis man kan få ledere til å se nyttverdien i å utvikle mer permanente arbeidsgrupper slik at noen andre slipper å lære “alt på nytt” hver gang et nytt prosjekt skal gjennføres er mye gjort. En slutt på urealistiske tidsfrister som bare fører til elendige produkter vil gavne både kunde og leverandør. Men det er mye som gjenstår og det er mange prosjektledere og kunder som må overtales. Spesielt kundesiden kan være vanskelig å forholde seg til. Mange kunder er interessert i klare frister å forholde seg til uavhengig av selve prosjektets metodikk. Det vil bli en utfordring for sjefer som i verste fall må kombinere to ulike metodikker.

    Jeg liker også tankegangen ved at man ikke egentlig kan velge kvalitetsnivå totalt sett hvis man ser på hele sluttpakka. Kostnaden kommer uansett på et eller annet tidspunkt, og dette med “Tradable quality” dreier seg egentlig om å flytte kostnade frem eller tilbake i tid og hvilket budsjett kosntaden skal belastes.

    En annen viktig ting er å få kundene til å innse verdien av en scrummaster. Det gjelder å skape forståelse for at det ikke skal etableres vilkårlige kontaktflater mot prosjektorganiasjonen og at en slik arbeidsform faktisk også gavner kunden selv ved at organisasjonen blir i bedre stand til å levere produkter av god nok kvalitet og til riktig tid. I min erfaring er dette faktisk et større problem for mindre organisasjoner der både kundesiden og leverandørsiden er forholdsvis små. Når forholdene ikke er så store er det også vanskeligere å skape aksept for det som kan oppfattes som overdrevne rutiner fra kundens side.

  2. Written by gamsjo
    on 16/11/2011 at 11:13 pm
    Reply · Permalink

    Hei Blå!
    Takk for god kommentar. Jeg mener bestemt at verden er i bevegelse og at svakheten med slike slutterminer og midlertidige organisasjoner begynner å gå opp for stadig flere kunder. Og det er nok kundene som sitter med nøkkelen her.

  3. Written by Torbjørn Marø
    on 19/11/2011 at 11:39 am
    Reply · Permalink

    For en flott artikkel. Jeg skulle ønske den ikke hadde vært nødvendig, men desverre er det mange som ikke har tatt disse tingene inn over seg.

    Personlig jobber jeg med produkter hvor utviklerne selv også må drifte løsningene. Dette gjør at vi får et enda mer intimt forhold til kvalitet – det går til syvende og sist ut over egen fritid om vi ikke gjør en god nok jobb i forkant for å si det sånn.

    Vi har derimot forkastet Scrum. Jeg synes argumentasjonen din mot prosjekter også til en viss grad kan brukes mot scrum. Vi bruker i stedet Kanban, hvor vi plukker oppgaver etterhvert som vi har ledig kapasitet, og kan re-prioritere hele tiden. Dessuten bruker vi veldig lite estimering – hvilken verdi en feature gir er mye viktigere for kvaliteten på produktet enn hvor lang tid det tar å utvikle den. Ting er ferdig når det er ferdig – dermed skyver vi ikke på kvaliteten. Skal du bruke Scrum må du estimere og committe deg til å levere på en deadline.

    Vår form å jobbe på krever selvsagt erfaring og svært dedikerte og ansvarsbevisste utviklere. Men det får du også nesten automatisk når du er organisert på denne måten.

  4. Written by gamsjo
    on 01/12/2011 at 6:33 pm
    Reply · Permalink

    Takk for godt svar Torbjørn! Og beklager sen respons.

    Jeg ser at Scrum også kan misbrukes til å kjøre rått mot en kjede av milepæler, men da har man også latt være å ta innover seg at Scrum faktisk bygger på agile, og at man må ha et langsiktig perspektiv på tingene. Dessuten vil syklusene gjøre at man vil få øye på problemene med å kjøre for fort – før man rekker å bygge opp for mye teknisk gjeld. Men dette forutsetter at man releaser ganske ofte da..

    Er for øvrig enig i at kanban gir den ultimate muligheten for å frigjøre seg fra deadliner, men man mister også timeboksene som er veldig nyttige for forbedringsarbeidet.

Subscribe to comments via RSS

Leave a Reply