Når smidig blir komplisert

I 2001 forfattet flere fremtredende utviklere dokumentet "Agile Manifesto". Syv år etter snakker "alle" om smidig programmering. Scrum, som er en av de mest kjente smidige metodene, har blitt et kjent begrep i it-verdenen. Men det er en risiko for at de smidige teknikkene bare blir med navnet, når metoden skal implementeres rundt i virksomhetene. Det mener to av de opprinnelige forfatterne av manifestet som amerikanske søstertidsskrift CIO har snakket med.

Alistair Cockburn, som er en av de sytten bak manifestet, mener at en del utviklere og team bruker smidige modeller som en unnskyldning for ikke å gi kundene detaljerte planer.

- Utviklerne starter med å gå rundt i sirkler, og kundene eller brukerne prøver å fortelle dem hva de vil ha, og da sier utviklerne: "Nei, nei nei! Dette er for mye informasjon. Bare gi meg den første setningen du sa, og så går jeg og bygger det." Og brukeren sier: "Men det er mer komplisert enn som så, la meg fortelle mer." Så svarer utvikleren igjen: "Det er alt jeg trenger for å få noe til å virke, la meg bare bygge det." Resultatet er selvfølgelig at de alle blir gående rundt i sirkler og til slutt går de seg helt bort – og på dette tidspunktet selvfølgelig over budsjett, sier Cockburn.

Trinn for trinn

Et typisk utviklerproblem er også når smidig teknikker blir behandlet dogmatisk, unyansert i forhold til oppgavene som faktisk skal løses. Ifølge Alistair Cockburn har dette å gjøre med hvordan folk tilegner seg ny kunnskap.

Cockburn mener man kan dele opp tilnærmingen i tre steg, hvor det første er når man har behov for å følge en oppskrift. Det andre steget er hvor man erkjenner at oppskriften var grei, men at man trenger mer. På dette stadiet ser man seg rundt etter andre oppskrifter og teknikker. Og det tredje steget, om du noen ganger kommer dit, er ifølge Cockburn steget for intuitive beslutninger hvor du ikke klarer å forklare hva du egentlig gjør, men du låner kanskje fra flere oppskrifter på metoder og blander det til et ok resultat.

En konsekvens av dette er at han eller hun i fase én tenker: "Jeg har sjekklisten min, jeg har sertifiseringen min". Og da er man kvalifisert til å drive smidig utvikling. Dette fokuset mener Cockburn er uheldig fordi det formelle settes foran det du faktisk skal gjøre. Og det smidig utvikling handler om er å få ting gjort.

Smidighet handler om steg to og tre. Den erfarne utvikler og team skal tenke mer på hvordan prosjektet egentlig går. Alle som kommer inn i forbindelse med prosjektet vil imidlertid helt sikkert spørre etter en sjekkliste og de andres faglige bakgrunn.

- Dermed har du spørsmål om Scrum-master sertifisering, Scrum-sjekklisten, sjekklisten for XP (extreme programming red. anm.) – alle vil ha sjekklister! Vi må få folk til å komme ut av boksen og ut på arenaen hvor de tenker på gode prinsipper og følelser, og ikke på alle sjekklistene, konkluderer Cockburn.

Selvdisiplin

Kent Beck signerte også manifestet om smidig programmering i 2001. Hans smidige prinsipper kommer til å bli en betydelig utfordring for mange.

- Når det snakkes om smidighet bruker man ofte termer som "selvdisiplin" og "selvbevissthet". Når karakteristikken, denne navnløse gruppen av selvbevisste utviklere som har hatt suksess med lettvekterprosesser, skal brukes av organisasjonene oppstår problemene - det er langt fra noen selvfølge at egne folk plutselig skal få disse attributtene, sier Beck.

Han advarer derfor virksomheter mot å bevege seg mot smidige metoder uten først å gå igjennom en selvransakelse. Beck mener en mekanisk tilnærming til smidige metoder kan være farlig. Han påpeker at det opprinnelige miljøet som banet vei for smidig programmering var meget selvmotiverte folk som ikke trengte særlig veiledning. Det kan dermed bli feil å lære opp andre i samme prinsipper, uten en grundig vurdering hva som passer og ikke passer for den enkelte organisasjon.

Denne saken er et utdrag fra artikkelen som har stått i Computerworlds seksjon for it-strategi, CIO, med tema Scrum.