Om forskning på IT-prosjekter

Dette handler om kunsten å lære av erfaring og er en kommentar til Magne Jørgensens foredrag på Software 2015 kalt “Hva skal til for å lykkes i IT-prosjekter?
 Hvor mye og hvordan kan man lære av andres suksesser og fiaskoer?”
 

Akkurat disse spørsmålene har opptatt meg nærmest på heltid siden tidlig 90-tall når jeg jobbet i Siemens Telecom på Linderud i Oslo. Jeg var da så heldig å få være med på ulike forskningsprosjekter, alle med variasjoner over disse spørsmålene som hovedtema. Jeg kan nevne SISU, SPIQ, SPIKE, PROFIT og Evisoft som ble kjørt på rekke og rad i en 20-års periode fra tidlig 90-tall, med finansiering av Norsk Forskningsråd og med forskere fra Sintef, NTNU, UiO og etter hvert Simula. Magne var selv med i noen av disse, husker jeg. Vi (i Siemens) var også med i PERFECT-prosjektet, et EU-finansiert ESPRIT-prosjekt over 3 år, der vi som industripartner hadde støtte fra konsulenter (Q-Labs i Sverige) og forskere fra Sintef, NTNU, Fraunhofer, Universitetet i Kaiserslautern og Universitetet i Grenoble. Våre utviktingsprosesser og vår evne til å lære av erfaring fikk da virkelig kjørt seg. Resultatet fra prosjektet ble kalt PERFECT Improvement Approach (PIA) og var basert på Quality Improvement Paradigm (QIP) og Goal Question Metrics (GQM). Alt lå til rette for at dette skulle bli virkelig bra. God finansiering, flere industripartnere og ikke minst anerkjente forskere som professor Dieter Rombach fra Fraunhofer på laget. Vi støtte oss også tungt på Professor Vic Basili ved Universitetet i Maryland som utviklet GQM og QIP. Og forskning gjort ved NASA av Frank MacGarry. Til tross for alt dette ble resultatet en stor flopp! Hvorfor virker ikke denne solide, vitenskapelig baserte prosessforbedringsmodellen? Hvorfor klarer vi ikke å lære av erfaring på denne måten? Jeg stilte meg dette spørsmålet om og om igjen på slutten av 90-tallet og utover i dette årtusenet og kunne bare konkludere med en ting: Prosjektene var for langvarige og store! Jeg tror det er tre helt fundamentale problemer med dette:

1. Det blir kjørt få prosjekter innenfor en kontekst, så vi får svært få datapunkter å sammenligne.

2. Store prosjekter er svært krevende å analysere, siden det fort vil være alt for mange variable faktorer – som ikke er uavhengige

3. Store prosjekter vil bruke mye kalendertid hvilket lett fører til at det neste prosjektet må forholde seg til en annerledes virkelighet og ha andre rammebetingelser – prosjektene blir ikke sammenlignbare.

Om 3: en metode som fungerte godt i ett prosjekt vil ikke nødvendigvis fungere godt i det neste for her vil sannsynligvis en rekke faktorer (som for eksempel personell) være forskjellige. Jeg husker godt dette fenomenet ble belyst i den smått kjetterske artikkelen The Importance of NOT Learning from Experience som Magne skrev sammen med Dag Sjøberg i år 2000. Bare overskriften fikk brikker til å falle på plass hos meg (jeg kan legge til at jeg ikke er enig i alt som står i artikkelen, men det spiller ingen rolle her). Jeg husker fra PERFECT-prosjektet at vi i Siemens ble trukket fram som et empirisk eksempel på at PIA fungerte. Vi kjørte da tre ganske like prosjekter rett etter hverandre. Alle tre var ganske korte med varighet på 6-7 måneder og prosjekt nummer 3 var særdeles vellykket. Vi som jobbet med prosessforbedring innkasserte gjerne denne seieren da, men med en litt flau smak i munnen. Realitetene var jo at disse tre prosjektene hadde vært nesten like! Og de hadde omtrent samme bemanning. Vi hadde systematisk samlet data og forbedret prosessene våre, men vi må ikke glemme at den erfaringen som satt i hodene på de som hadde vært med på alle tre prosjektene kanskje talte like mye. Eller kanskje mer? Etter dette forandret Siemens strategi (nye tider, ny teknologi osv) og vi oppdaget da at all erfaringslæring, innsamlede data og definerte prosessmodeller var fullstendig ubrukelige. Det ville rett og slett vært skadelig å benytte seg av dette i de neste prosjektene…

I foredraget problematiserer Magne Jørgensen rundt vår evne til å analysere og trekke slutninger. Hvor stor kausalitet har egentlig problemet vi analyserer? Hvor uhildet er våre konklusjoner? Er vi i stand til å være objektive, eller vil vi søke etter å få det svaret vi trodde på forhånd – eller det vi ønsker oss? Kan vi forvente å lære noe særlig når det opprettes “havarikommisjon” i forb med et stort, feilslått prosjekt? Dette er fornøyelig lesning og det er alltid godt å få bekreftet det vi allerede vet av en professor og av forskning. Men dette foredraget rommer egentlig ikke noe nytt. Dessverre.

Løsningen på læringsproblemet

Magne Jørgensen presenterer HVA KAN VI GJØRE FOR Å BLI BEDRE TIL Å LÆRE AV ERFARING? og kommer med en del gode, men ganske selvfølgelige tips. Men han nevner ikke noe om muligheten til å stykke opp problemet i små, sammenlignbare enheter som i for eksempel Scrum. Jeg “arvet” Masterkurset “Produkt- og Prosessforbedring” på IFI av Magne Jørgensen på tidlig 2000-tall, og jeg hadde kurset i 5 år. Jeg bakte tidlig inn det å kjøre mange små, fremfor få store prosjekter i kurset, men rundt år 2004 fikk jeg en slags oppvåkning da jeg forstod rekkevidden av Scrum og andre smidige metoder. Scrum er jo en prosessforbedringsprosess! Scrum er skreddersydd for å lære av erfaring! Men for at det skal fungere godt, må noen brikker være på plass: Teamet må ha på plass kontinuerlig integrasjon, og faktisk fullføre et produktinkrement i hver iterasjon. Og teamet må ansvarliggjøres slik at de selv kan iverksette tiltak når de lærer av erfaring. Erfaringer kan kun trekkes på bakgrunn av sluttresultatet.

Læringsmulighet

Jeg blir altså stadig forundret over at forskere og konsulenter overser denne fantastiske muligheten til å optimalisere læringen. I figuren kan vi tenke oss at det samme 2-års prosjektet med de samme målsetningene kjøres på tre ulike måter. Først et “big-bang-prosjekt” som altså får én læringsmulighet, der vi kjører en prosjektevaluering (som alle gode prosjektledere gjør). Deretter det samme prosjektet med 3 delleveranser og 3 evalueringer. Her vil vi høyst sannsynlig ha ganske like rammebetingelser og kanskje vi er så heldige å ha de samme menneskene i prosjektet (mye tyder på at menneskeaspektet er det aller mest avgjørende). Det er lett å se at vi her får langt bedre betingelser for å forbedre oss underveis og å kunne trekke noen konklusjoner. I smidig vil betingelsene for læring være dramatisk forbedret. Her ser vi at hver iterasjon (I) (tar typisk 2-3 uker) resulterer i et produktinkrement som analyseres og vi får en direkte læringseffekt. Ett aspekt her er at de involverte får rask feedback gjør at læringen kan bli langt mer effektiv. Vi har det vi gjorde friskt i minne og kommer lett i en svært effektiv læringsmodus. Inkrementene er også svært like hverandre, hvilket gjør at vi nå kan eksperimentere med metoder og verktøy. Og vi får øvd oss. Skal vi virkelig bli gode i noe, må vi øve! En viktig betingelse for at smidig skal fungere godt er også at teamet som gjør jobben ikke arbeider mot en stor avslutningsmilepæl. I slike tilfeller vil investeringer i bedre metoder og verktøy kunne virke litt fånyttes, siden prosjektet blir oppløst ved avslutningen. En bedre løsning er å satse på mer permanente team som jobber mot klare målsetninger, men som da får lov til å forbli intakte og kan selv høste fruktene av egen prosessforbedring.

Scrum er laget for å øke kausaliteten dramatisk. Gjennom å dele opp arbeidet i inkrementer, tiden i løpende tids-bokser (iterasjoner) og organisasjonen i små, tverrfaglige team får vi en helt annen gjennomsiktighet. Årsak-virkning-sammenhengene kommer til syne på en helt annen måte.

Jeg trodde det var opplest og vedtatt at store prosjekter er for komplekse til å kunne trekke bastante konklusjoner om hva som gikk galt. Til det er det alt for mange avhengige faktorer som spiller inn; Verden er ikke lineær, den er tvert om dynamisk og kompleks. Jeg støtter meg til Cynefin-modellen til Dave Snowden når jeg diskuterer kausalitet i lys av kompleksitet. Jeg har skrevet en liten innføring her. Han deler inn problemer i 4 domener: Opplagte, Kompliserte, Komplekse og Kaotiske. Det Snowden interessant nok sier om Scrum er at inne i terasjonen er vi sannsynligvis i det kompliserte domenet, hvilket innebærer at vi kan finne årsak-virkning-sammenhenger. I et mer langsiktig perspektiv er vi i det Komplekse området, hvor vi kun i ettertid kan analysere resultatet og finne ut om vi er på rett vei.

Det var mange foredrag direkte og indirekte om smidig på Software2015. Synes nå det er på høy tid at også forskerne ser med større interesse på dette fenomenet, særlig når det er snakk om å lære av erfaring. Det er mulig jeg er for utålmodig, men forskerkverna kverner svært langsomt…

PS: Som deltager på Software2015 fikk jeg en dropbox-link til alle foredragene. Jeg er usikker på om jeg uten videre kan dele foredraget til Magne Jørgensen på denne bloggen.

Du kan se presentasjonen til Magne Jørgensen her

 

Posted on February 20, 2015 at 4:54 pm by gamsjo · Permalink
In: Forskning, kompleksitet, Scrum · Tagged with: , , , ,

4 Responses

Subscribe to comments via RSS

  1. Written by Magne Jørgensen
    on 23/02/2015 at 7:50 am
    Reply · WordPress › Error