Den Smidige myte?
Studier som utgir seg for å være vitenskapelig utført viser seg stadig å ikke tåle nærmere granskning. Kommersielle tenkesmier tar mange snarveier i kampen om å få frem oppsiktsvekkende resultater. Forskeren Magne Jørgensen har gjennom årene bidratt til å “avsløre” flere tvilsomme studier og dermed bidratt til å heve den vitenskapelige standarden innenfor systemutvikling. Vi synes dette er en hederverdig innsats som vi har lært mye av. Vi synes dog at Magne har blitt overivrig i det siste. I både artikler og foredrag virker han å fremfekte et syn som stiller spørsmålstegn ved all erfaring som ikke er vitenskapelig bevist. Det siste eksemplet på dette synet sto å lese i CW den 24. mars. Når artikkelen bruker denne skepsisen til å koble smidig utvikling med ord som “mote” og “tro” så føler vi at forskeren er i ferd med å kaste ut barnet med badevannet.
Kan det noen gang bevises at smidig utvikling er effektivere enn “tradisjonell utvikling”? Problemstillingen er sannsynligvis for åpen. Det finnes mange måter man kan definere “effektiv” på, en uendelig antall måter å være smidig på og enda flere måter å utvikle på som ikke er smidige. Vitenskapelige studier må redusere en problemstilling til noe som lar seg måle. For eksempel: Gir parprogrammering færre defekter enn individuell programmering? Faren med å redusere problemstillinger på denne måten er at det som gjenstår kan bli et meningsløst spørsmål uten kontekst. Et studie har for eksempel nylig vist at en naken mann (eller kvinne) ikke mister mer varme gjennom hodet enn resten av kroppen. Men dette er ikke relevant til hvor vidt vi bør ta på oss lue om vinteren: I det virkelige livet er det få som velger å gå ut nakne på vinteren, men mange som går barhodet. I sitt foredrag på Software 2009 hevdet Magne tilsvarende at Fred Brooks berømte påstand “Adding manpower to a late software project makes it later” ikke er verdt mye da det er en overforenkling (Brooks skal selv ha innrømmet at det er en “outrageous oversimplification”). De fleste prosjektledere vil derimot si at dette er et godt eksempel på en erfaringsbasert regel. Selvfølgelig er den ikke sann i alle tilfeller, men man bør ha gode grunner for å bryte den.
Som et komplement til vitenskapelige studier er det jo vanlig å bruke erfaringsbaserte slutninger. Disse erfaringene kan være falske, vi mennesker er mestere på å lure oss selv, men det må likevel være bedre å basere seg på en erfaring enn å bare gjette. Hvis det så kommer vitenskapelige studier som tilsier at erfaringen er falsk så er det et grunnlag for å endre adferd. Det er viktig å samle erfaring på en måte som er tilnærmet vitenskapelig for å unngå noen av de fallgruvene Magne gir eksempler på i sine innlegg.
Systematisk bruk av erfaringer er også fundamentet for smidige metoder. Etter en kort iterasjon revurderer teamet resultatet og sin arbeidsform. Målet er nettopp å basere seg på erfaring og empiri framfor blind tro. Slik vil et smidig team bruke iterasjonene på å hente inn mer informasjon om teknikkene de bruker, måten de jobber på og hvor vidt arbeidet deres tilfredsstiller kundens behov.
Smidige metoder er heller ikke en moteting, slik Magne ser ut til å hevde. Smidig utvikling har en lang tradisjon. Det oppsto ikke med det smidige manifestet i 2001. Tankeretningen vokste ut fra det samme miljøet som ble kalt objektorientert på 90-tallet. Dette er et miljø med sterke bånd til akademia tilbake fra Smalltalk og Simula67 før dette. I tillegg har man lånt fra Toyota Production System sin erfaring innen prosessindustrien. En tradisjon som bygger på det W. Edwards Deming kalte Plan-Do-Check-Act – en tilpasning av den vitenskapelige metode til industrien.
Smidig utvikling er et rammeverk for å lære fra erfaring. På samme måte som man kan bruke vitenskapens verktøy bra eller dårlig, kan man bruke smidig utvikling bra eller dårlig. Det vil aldri finnes metoder som garanterer at vi lykkes. I stedet ønsker vi metoder som hjelper oss å oppdage når vi ikke gjør det.
Niklas Bjørnerstedt, Leanway
Johannes Brodwall, Steria
Publisert i Computerworld 22. mai 2009 (kun i papirutgaven)
Posted on 2009.05.25 at 14:46
Comments are off for this post.