As my previous Norwegian language article turned out to be one of the all time top hit articles in my blog, I will continue to write a few articles in Norwegian. This one is on an idea on how to do reseach on the success of agile projects. Next week, I will return to another popular topic: Testing.
Under paneldebatten på Geilo-seminaret til Dataforeningen, satt Magne Jørgensen meg, Lars Arne Skår og Niklas Bjørnerstedt litt til veggs med et ganske enkelt spørsmål: Hvordan kan vi vite om smidige metoder virker? Perspektivet til Magne som forsker på utviklingsprosjekter fikk meg til å tenke på spørsmålet, men før jeg fikk kommet med et forslag til svar. Derfor skriver jeg det her i stedet.
Ã… forske pÃ¥ et spørsmÃ¥l som “fungerer smidige metoder” er veldig vanskelig. Mitt hÃ¥p er at noen i stedet vil ta et skritt tilbake og se om man kan fÃ¥ svart pÃ¥ det mer interessant spørsmÃ¥let: Er det en sammenheng mellom hyppig feedback og lønnsomme prosjekter?
Hvordan forske på smidige metoder?
Problemet nÃ¥r en forsker spør “fungerer smidige metoder” er at det tvinger oss til Ã¥ definere “smidige metoder” og “fungerer” pÃ¥ en mÃ¥te som kan mÃ¥les. Og det er ogsÃ¥ fordelen med spørsmÃ¥let.
Mitt forslag er at vi omdefinerer spørsmÃ¥let til “er smidige prosjekter vellykkede?” Hva betyr dette, da? Hva er “et smidig prosjekt” og hva er “et vellykket prosjekt”?
Er et prosjekt som bruker test-driven development, men ikke leverer noe oftere enn hvert år et smidig prosjekt? Hva med et prosjekt som følger en tradisjonell Krav -> Analyse -> Design -> Utvikling -> Test innfallsvinkel, men som gjør dette hver måned?
For meg er den definerende karakteristikken på et smidig prosjekt hyppigheten på iterasjoner. Iterasjoner kan defineres på fire måter: (1) Et planleggingsvindu, (2) tiden mellom hver gang man setter noe i drift i et produksjonsnært miljø, (3) tiden mellom hver gang man viser fram fremdrift til produkteier eller (4) tiden mellom hver gang man setter i drift noe som sluttkundene vil benytte. Jeg vet ikke hvilken av disse syklusene som er viktigst, men jeg mistenker at de blir mer verdifulle fra 1 til 4. Et studie som bryter ned prosjekter i hvor mange ganger per år de hadde en iterasjon for hver av de fire betydningene vil være veldig interessant for IT-bransjen.
Og hva er et vellykket prosjekt? Er et prosjekt som holder budsjett, men som ikke er verdifullt vellykket (tenk et prosjekt startet etter Ã¥r 2000 for Ã¥ effektivisere produksjon av videokassetter)? Hva med et prosjekt som gÃ¥r over budsjett, men som kundene river av hyllene i begeistring (tenk facebook)? Det er Ã¥penbart at Ã¥ møte “tid, kost og kvalitet” (aaaargh!) ikke er mÃ¥lestokken pÃ¥ suksess. MÃ¥lestokken mÃ¥ være om prosjektet er lønnsomt! Eller som vi gjerne sier: Return-on-Investment (ROI).
Å måle lønnsomhet kan være en vrien affære. Det er som regel overkommelig å finne ut av utgiftene, men det er vanskeligere å danne et realistisk bilde av fordelene. De fleste IT-prosjekter er begrunnet i en eller annen form for effektivisering, og ofte ikke målbar sådan. For å gjøre vondt verre, er det ofte politisk nødvendig å overdrive gevinsten av prosjekter.
Jeg har ingen perfekt løsning på dette spørsmålet, men én mulig innfallsvinkel ville være å måle utviklingen av selskapets markedsverdi relativt til andre selskaper. Noen andre har helt sikkert en bedre idé. Å måle markedsverdi er enkelt, men det er mange forstyrrende elementer, så man må involvere upraktisk mange selskaper for å få et optimalt resultat. Det utelukker også den store andelen IT-prosjekter som kjøres av det offentlige.
En utfordring og invitasjon til forskere
SpørsmÃ¥let “fungerer smidige metoder” er et som har mye interesse, og som forskningen burde ta tak i. En mulig metodikk for Ã¥ svare pÃ¥ dette er Ã¥ forske pÃ¥ spørsmÃ¥let “finnes det en sammenheng mellom hyppige iterasjoner (i en av fire forskjellige betydninger) og økonomisk vellykkethet?” Dette er et spørsmÃ¥l jeg selv er veldig interessert i svar pÃ¥, men jeg har ikke ressursene til en forsker. Men jeg bidrar gjerne til Ã¥ komme nærmere et svar, dersom noen kan lede veien.
Forkortet og repostet av Johannes etter tillatelse fra Magne Jørgensen
Du er inne pÃ¥ mye jeg ogsÃ¥ synes er helt vesentlige i dine tanker rundt hvordan vet vi at … Og hyggelig Ã¥ fÃ¥ respons pÃ¥ kritikk. Synes generelt sett vi kritiserer hverandre for lite – tar gjerne imot kritikk pÃ¥ mine synspunkter/studier/resultater etc ;-)
Ved Ã¥ redusere til “iterasjoner” og “suksess” i ROI-termer er du/vi kanskje noe nærmere Ã¥ kunne evaluere “agile” – men bare noe. Jeg har selv (etter en del studier pÃ¥ lignende tema – som om verktøy xxx er bedre enn verktøy yyy i firma zzz) mistet troen pÃ¥ at slike studier er særlig nyttige. Selv ikke med den helt avgjørende overgangen fra “er x bedre enn y” til “nÃ¥r er x bedre enn y” synes slike studier Ã¥ være særlig verdifulle. Noe av problemene skyldes definisjonsproblemer – a la de du er inne pÃ¥, men det viktigste er at man sjelden har sammenligninger av interesse der noe er ALLTID bedre enn noe annet, og det hjelper en organisasjon lite at det f eks i GJENNOMSNITT har vært best i den studerte konteksten.
[…] Ditt fokus pÃ¥ hyppige iterasjoner bør – etter min mening – ogsÃ¥ sees i et problemløsningsperspektiv, dvs hva er den optimale feedback-sekvens for en viss type feedback gitt et eget kompetansenivÃ¥ og type problem. At man lenge har hatt for lite feedback innen systemutvikling innen mange metoder, vil kanskje si at hyppigere SOM OFTEST vil forbedre nytten/effektiviteten/… er selvsagt langt mindre
verdifull kunnskap enn å vite mer om hvilken type feedback, når og hvor ofte et visst nivå med feedback er gunstig.
Hei, Magne
Jeg har merket selv at det er veldig lett Ã¥ falle i felle med Ã¥ forsøke Ã¥ avvise kritikk (“deflect”) i stedet for Ã¥ svare pÃ¥ den. Jeg forsøker selv Ã¥ ta meg i nakkeskinnet mer her.
ForstÃ¥r jeg deg riktig nÃ¥r du sier at et studie for Ã¥ finne ut av effekten av smidige metoder (eller feedback) burde hatt en dimensjon til? Slik at spørsmÃ¥let blir “innen hvilke problemtype er hvilken iterasjonslengde korrelert med vellykkede prosjekter?”
Jeg skjønner poenget ditt med begge spørsmålene som du spurte på Geilo til å være at noen problemer går det ikke an å ha meningsfull fremdrift innenfor en tidsperiode som er for kort. Er det riktig? For å bruke en utslitt metafor: Det er ikke meningsfullt å ha iterasjonslengde på under 9 måneder på leveranse av spedbarn.
Min erfaring er at de fleste oppgavene innen utvikling kan og bør stykkes opp i oppgaver pÃ¥ under et dagsverk. NÃ¥r jeg ikke gjør det selv, produserer jeg dÃ¥rligere resultater (og jeg finner alltid i etterkant at det var en mÃ¥te jeg kunne stykket det opp bedre). Og det er en ganske stor gruppe med selv-erklærte “dyktige” utviklere som ikke klarer Ã¥ stabilisere koden sin i løpet av en dag.
Kanskje et annet område som kunne være verdt å få bedre empiri på.
Som du påpeker er det motsetning mellom feedbackfrekvens og størrelse på chunks. Jeg tror den viktigste faktoren her ikke er problemtype, men prosjektstørrelse. Men smidige prosjekter oppfordrer typisk til mindre prosjekter. Jeg tror dette både er for å underbygge hyppig feedback, men også fordi det er en vanlig oppfatning at store prosjekter er mindre vellykket. Som igjen går tilbake til det du sier om planer som er vanskelige å sammenstille.
Et spørsmÃ¥l til sist: Jeg forstÃ¥r deg til Ã¥ si at det er bedre Ã¥ forske pÃ¥ “NÃ…R fungerer X bedre enn Y”, heller enn “FUNGERER X bedre enn Y”. Det kan jeg si meg enig i. Men dette endrer ikke problemet du pÃ¥peker med at vi ikke klarer Ã¥ definere “BEDRE”, ikke sant?
De to kanskje viktigste argumentene for å bygge valg av metode på bedre evidens er:
1) At man i mindre grad tar utgangspunkt over-genereliserer fra sin egen erfaring og problemkontekst.
2) At man i mindre grad utsettes for teoriladet observasjon (at alt passer inn i ens egen modell av hvordan verden er skrudd sammen)
De fleste er enige i det, men vi gÃ¥r vel alle uunngÃ¥elig den fellen likevel. Noe jeg tror ogsÃ¥ “de smidige” gjør.
SÃ¥ er det problemet om Ã¥ finne ut nÃ¥r en metode er bedre – som i stor grad er uløst. Noe er iboende (f eks av vi ikke klarere Ã¥ studiere vitenskapelig noe vi ikke klarere Ã¥ definere tilstrekkelig presist), men noe tror jeg skyldes at mye av forskningen gÃ¥r fram pÃ¥ feil mÃ¥te og at vi mÃ¥ innse at noe kunnskap er svært lokal – dvs at vi kan finne ut noe innen en avgjrenset kontekst (et firma), men i mye større grad bør avstÃ¥ fra Ã¥ generalisere. SÃ¥ hÃ¥pløst er det ikke – men vanskelig. Jeg tror f eks at det kan finnes lokale, meningsfulle, nyttige mÃ¥linger av kvalitets og produktivitets-relaterte egenskaper ved programvare.
mvh Magne (litt stresset pÃ¥ tid, men dersom du ønsker Ã¥ legge noe av diskusjonen vÃ¥r/mine kommentarer inn pÃ¥ bloggen – gjerne en forkortet versjon, mÃ¥ du bare gjøre det)
Hei, Magne
Ettersom “vi smidige” ofte er veldig dypt nede i enkeltprosjekter er det definitivt en kjempefare for Ã¥ overgeneralisere.
Det praktiske motstykket til det du sier er at vi observerer “dette ser ut til Ã¥ fungere for oss, jeg vet ikke om det vil fungere for dere”. Jeg bestreber meg veldig pÃ¥ Ã¥ presisere pÃ¥ at jeg har veldig fÃ¥ datapunkter, men det er lett Ã¥ la seg rive med.
Takk for en spennende diskusjon.
Forkortet og repostet av Johannes etter tillatelse fra Magne Jørgensen
Du er inne pÃ¥ mye jeg ogsÃ¥ synes er helt vesentlige i dine tanker rundt hvordan vet vi at … Og hyggelig Ã¥ fÃ¥ respons pÃ¥ kritikk. Synes generelt sett vi kritiserer hverandre for lite – tar gjerne imot kritikk pÃ¥ mine synspunkter/studier/resultater etc ;-)
Ved Ã¥ redusere til “iterasjoner” og “suksess” i ROI-termer er du/vi kanskje noe nærmere Ã¥ kunne evaluere “agile” – men bare noe. Jeg har selv (etter en del studier pÃ¥ lignende tema – som om verktøy xxx er bedre enn verktøy yyy i firma zzz) mistet troen pÃ¥ at slike studier er særlig nyttige. Selv ikke med den helt avgjørende overgangen fra “er x bedre enn y” til “nÃ¥r er x bedre enn y” synes slike studier Ã¥ være særlig verdifulle. Noe av problemene skyldes definisjonsproblemer – a la de du er inne pÃ¥, men det viktigste er at man sjelden har sammenligninger av interesse der noe er ALLTID bedre enn noe annet, og det hjelper en organisasjon lite at det f eks i GJENNOMSNITT har vært best i den studerte konteksten.
[…] Ditt fokus pÃ¥ hyppige iterasjoner bør – etter min mening – ogsÃ¥ sees i et problemløsningsperspektiv, dvs hva er den optimale feedback-sekvens for en viss type feedback gitt et eget kompetansenivÃ¥ og type problem. At man lenge har hatt for lite feedback innen systemutvikling innen mange metoder, vil kanskje si at hyppigere SOM OFTEST vil forbedre nytten/effektiviteten/… er selvsagt langt mindre
verdifull kunnskap enn å vite mer om hvilken type feedback, når og hvor ofte et visst nivå med feedback er gunstig.
Hei, Magne
Jeg har merket selv at det er veldig lett Ã¥ falle i felle med Ã¥ forsøke Ã¥ avvise kritikk (“deflect”) i stedet for Ã¥ svare pÃ¥ den. Jeg forsøker selv Ã¥ ta meg i nakkeskinnet mer her.
ForstÃ¥r jeg deg riktig nÃ¥r du sier at et studie for Ã¥ finne ut av effekten av smidige metoder (eller feedback) burde hatt en dimensjon til? Slik at spørsmÃ¥let blir “innen hvilke problemtype er hvilken iterasjonslengde korrelert med vellykkede prosjekter?”
Jeg skjønner poenget ditt med begge spørsmålene som du spurte på Geilo til å være at noen problemer går det ikke an å ha meningsfull fremdrift innenfor en tidsperiode som er for kort. Er det riktig? For å bruke en utslitt metafor: Det er ikke meningsfullt å ha iterasjonslengde på under 9 måneder på leveranse av spedbarn.
Min erfaring er at de fleste oppgavene innen utvikling kan og bør stykkes opp i oppgaver pÃ¥ under et dagsverk. NÃ¥r jeg ikke gjør det selv, produserer jeg dÃ¥rligere resultater (og jeg finner alltid i etterkant at det var en mÃ¥te jeg kunne stykket det opp bedre). Og det er en ganske stor gruppe med selv-erklærte “dyktige” utviklere som ikke klarer Ã¥ stabilisere koden sin i løpet av en dag.
Kanskje et annet område som kunne være verdt å få bedre empiri på.
Som du påpeker er det motsetning mellom feedbackfrekvens og størrelse på chunks. Jeg tror den viktigste faktoren her ikke er problemtype, men prosjektstørrelse. Men smidige prosjekter oppfordrer typisk til mindre prosjekter. Jeg tror dette både er for å underbygge hyppig feedback, men også fordi det er en vanlig oppfatning at store prosjekter er mindre vellykket. Som igjen går tilbake til det du sier om planer som er vanskelige å sammenstille.
Et spørsmÃ¥l til sist: Jeg forstÃ¥r deg til Ã¥ si at det er bedre Ã¥ forske pÃ¥ “NÃ…R fungerer X bedre enn Y”, heller enn “FUNGERER X bedre enn Y”. Det kan jeg si meg enig i. Men dette endrer ikke problemet du pÃ¥peker med at vi ikke klarer Ã¥ definere “BEDRE”, ikke sant?
De to kanskje viktigste argumentene for å bygge valg av metode på bedre evidens er:
1) At man i mindre grad tar utgangspunkt over-genereliserer fra sin egen erfaring og problemkontekst.
2) At man i mindre grad utsettes for teoriladet observasjon (at alt passer inn i ens egen modell av hvordan verden er skrudd sammen)
De fleste er enige i det, men vi gÃ¥r vel alle uunngÃ¥elig den fellen likevel. Noe jeg tror ogsÃ¥ “de smidige” gjør.
SÃ¥ er det problemet om Ã¥ finne ut nÃ¥r en metode er bedre – som i stor grad er uløst. Noe er iboende (f eks av vi ikke klarere Ã¥ studiere vitenskapelig noe vi ikke klarere Ã¥ definere tilstrekkelig presist), men noe tror jeg skyldes at mye av forskningen gÃ¥r fram pÃ¥ feil mÃ¥te og at vi mÃ¥ innse at noe kunnskap er svært lokal – dvs at vi kan finne ut noe innen en avgjrenset kontekst (et firma), men i mye større grad bør avstÃ¥ fra Ã¥ generalisere. SÃ¥ hÃ¥pløst er det ikke – men vanskelig. Jeg tror f eks at det kan finnes lokale, meningsfulle, nyttige mÃ¥linger av kvalitets og produktivitets-relaterte egenskaper ved programvare.
mvh Magne (litt stresset pÃ¥ tid, men dersom du ønsker Ã¥ legge noe av diskusjonen vÃ¥r/mine kommentarer inn pÃ¥ bloggen – gjerne en forkortet versjon, mÃ¥ du bare gjøre det)
Hei, Magne
Ettersom “vi smidige” ofte er veldig dypt nede i enkeltprosjekter er det definitivt en kjempefare for Ã¥ overgeneralisere.
Det praktiske motstykket til det du sier er at vi observerer “dette ser ut til Ã¥ fungere for oss, jeg vet ikke om det vil fungere for dere”. Jeg bestreber meg veldig pÃ¥ Ã¥ presisere pÃ¥ at jeg har veldig fÃ¥ datapunkter, men det er lett Ã¥ la seg rive med.
Takk for en spennende diskusjon.
good for you
thanks for sharing me this ideas