Smidig utvikling er ikke i mål

Smidig metodikk har inntatt Norge. Derfor må vi slutte å bare reklamere for de positive sidene, og åpne opp for å diskutere og løse reelle utfordringer knyttet til smidige prosjekter.

De aller fleste artikler, temanummer osv. om smidige metodikker har så langt framstilt smidige metodikker på en svært rosenrød måte. Smidig systemutvikling er uten tvil et stort skritt framover i forhold til tradisjonell systemutviklingsmetodikk. Imidlertid er smidig utvikling i sin nåværende form ikke endestasjonen. Vi kan – og må – bli enda bedre.

Det finnes reelle utfordringer ved bruk av smidige metodikker, og det må vi også tørre å diskutere. Dét er viktig for at smidig utvikling skal bli en suksess, leve opp til sitt potensiale og ikke bare bli nok en hype på historiens gravplass. Her vil jeg nevne tre av de utfordringene jeg er opptatt av om dagen.

Levere verdi

Den første utfordringen gjelder å levere verdi. Smidige metodikk har som prinsipp å levere verdi tidlig og hyppig, og det mest verdifulle først. Dette gir bedre cashflow og ROI, og er et flott prinsipp.

I praksis leverer imidlertid smidige prosjekter funksjonalitet, ikke verdi. Stort sett aner vi ikke hvor mye verdi funksjonaliteten har for organisasjonen, eller om det kanskje ville vært mer lønnsomt å ikke utvikle en gitt funksjonalitet. Vi bare overlater til Produkteieren (kunden) å prioritere funksjonaliteten, og så håper vi at det fører til at vi leverer høyest verdi først og at ROI blir så høy som mulig. Kanskje det stemmer, kanskje ikke – det vet vi ikke, vi bare tror.

Vi trenger altså bedre måter å måle verdi på.

Styre mot mål

Den andre utfordringen er at smidige prosjekter fortsatt i for stor grad styrer mot kundens krav, ikke mot kundens mål. Den etter hvert velkjente Produktkøen (Product Backlog) fra Scrum er et eksempel på dette. Vi beskriver krav som brukerhistorier, legger dem inn i Produktkøen, og deretter følger vi framdrift i forhold til ferdigstillelse av kravene. Vi er åpne for å endre på kravene og omprioritere, mye mer enn på tradisjonelle prosjekter, og det bidrar absolutt til bedre resultater for prosjektet.

Imidlertid er det måloppnåelse som er viktig, ikke kravoppnåelse. Kravene er bare et sett med hypoteser for hvordan man kan nå målene. Vi trenger altså mer fokus på å definere mål og styre mot måloppnåelse. Det bør nevnes at EVO, utviklet av Norges egen Tom Gilb, er et velprøvd alternativ med fokus på måloppnåelse.

Mer støtte til Produkteieren

Den tredje utfordringen er at mye av det som er mest krevende, særlig i Scrum-prosjekter blir dyttet over på Produkteieren, dvs kunden. Og dette er samtidig ting som i stor grad avgjør om et prosjekt blir en suksess eller ikke, så som god forankring i organisasjonen, god balanse mellom ulike interessehavere, riktig prioritering av hva som blir med og hva som ikke blir med, osv. Allikevel sier vi ikke så mye om hvordan Produkteieren skal klare disse tingene. Produkteieren er ofte meget kompetent på sitt fagområde – men det fagområdet er vanligvis ikke prosjektstyring.

Så mens utviklingsteamet jobber lykkelig i vei, beskyttet fra forstyrrelser fra omverdenen, må Produkteieren prioritere ønsker, forankre beslutninger, forhandle enighet, drive internpolitikk – samtidig som hun skal bistå utviklingsteamet med alle ønskelige avklaringer.

Vi har gjort store framskritt på arbeidsmåten til utviklingsteamet, der jobber vi på en mye mer solid måte enn før. Nå må vi løfte blikket fra design-, utviklings- og testjobben. Vi må fokusere mer på Produkteieren og organisasjonen rundt, og gi reell støtte til Produkteierens viktige rolle.

Ta erfaring på alvor

Vi trenger altså bedre måter å måle verdi på, mer fokus på mål og måloppnåelse, og bedre støtte til Produkteieren og organisasjonen rundt. Men dette er kun tre utfordringer som jeg synes er viktige, andre vil være mer opptatt av andre utfordringer – ut fra deres situasjon og erfaring. Hovedpoenget er at vi nå begynner å diskutere disse reelle utfordringene som folk møter i praksis.

Så langt har dyktige folks konkrete utfordringer ofte blitt besvart med varianter over temaet «Men dere gjør det ikke riktig». Slike svar hjelper ikke. Og skal smidig systemutvikling bli en suksess, må det være hjelp å få også når man sliter. Og like viktig: Hvis vi avfeier de utfordringene folk opplever, hindrer vi oss selv i å utvikle og forbedre den smidige metodikken, fordi vi ikke tar tilbakemeldingene fra praktisk bruk på alvor.

Som en av entusiastene som har jobbet for å spre smidig utvikling i en årrekke, gleder jeg meg over at smidig systemutvikling etter hvert har blitt godkjent og omfavnet i Norge. Markedsføringen har virket, nå må vi slutte å evangelisere og heller ta fatt på utfordringene.

Smidig systemutvikling i sin nåværende form er et stort steg videre, men ikke endestasjonen. Vi må fortsette å forbedre oss, basert på tilbakemeldinger.

Dét er den smidige kjernen i all sin enkelhet.

Dette innlegget er hovedsaklig basert på en artikkel jeg hadde i Computerworld i april 2009.

2 kommentarer om “Smidig utvikling er ikke i mål”

  1. Gode poenger. Det er også viktig å tenke på at smidig systemutvikling i seg selv ikke er et mål. Det viktigste er at kunden når sine mål (som oftest knyttet opp mot verdi). Til dette formålet er smidig systemutvikling et veldig viktig middel.

  2. Absolutt, Kjetil! Vi diskuterer ofte som om smidig systemutvikling er målet i seg selv («mest mulig smidig»), mens det kun er et middel til å oppnå gode prosjekter – som igjen er midler til å oppfylle viktige mål for organisasjonen.

Legg igjen en kommentar