2003-11-25 — Magnus Ljadas
Många har försökt, och många har stupat. Magnus Ljadas ger sig in i jakten efter en utvecklingsmetod som ser bra ut både på pappret och i verkligheten.
Jag tycker om god mat, så för mig är det alltid ett nöje att åka till Italien. Men det är inte god mat, utan nyfikenhet, som får mig att åka till Milano den här gången. Nyfikenhet inför det som gör att vissa mjukvaruprojekt lyckas medan andra misslyckas. Jag har med tiden pendlat mellan en naiv och en rätt krass inställning till valet av utvecklingsmetod. Resultatet brukar bli ungefär detsamma oavsett - projekt kostar mer, tar längre tid och förbrukar mer mänskliga resurser än nödvändigt. Men så plötsligt en dag fann jag mig själv i ett projekt där mer än vanligt kändes rätt. Jag märkte hur människor trädde fram och tog ansvar på ett helt annat sätt än vanligt. Hur en märklig känsla av att vara på rätt spår infann sig. Märkligt nog verkade det som om hela företaget snappat upp det nya arbetssättet redan efter några månader. Utvecklingsmetoden hette Scrum.
Det är 36 grader varmt i Milano och kroppen blir lite matt av solen. Precis som i andra sydeuropeiska städer är luften i Milano tung av trafikavgaser. De italienska männen tycks inte påverkas av detta utan går omkring, till synes opåverkade av värmen, i sina oklanderliga kostymer. Själv svettas jag oavbrutet i min fladdriga skjorta och shorts. Jag är dömd till ständig turistmundering i dessa trakter. Förväntansfull traskar jag runt i Palazzo delle Stelline på morgonen för att hitta lokalen vi ska hålla till i. Kommer vi att vara fem eller hundra personer? Ingen sådan information har läckt ut i förväg.
I ett rum på andra våningen finner jag till slut tretton personer samlade runt en hästskoformad bänkrad. Tankarna går osökt till Leonardo da Vincis "Den sista måltiden" som hänger i kyrkan på andra sidan gatan. Den skallige mannen i mitten med den härligt breda Chicago-dialekten måste vara Scrum-Jesus, eh, Ken Schwaber, tänker jag. Jag hälsar på de andra och bänkar mig mellan Andrew från ett brittiskt TV-bolag och italienaren Luca. Ken samlar in kursavgiften från var och en i kontanter och börjar sedan att berätta om Scrum.
Scrum är enkelt och samtidigt mycket svårt, säger Ken. Scrum består av ett enkelt skelett som kan förklaras och läras ut på en dag. Men att förstå Scrum kräver en radikalt förändrad syn på människan. Ken går igenom grundpriciperna i Scrum. De tre rollerna: projektägaren som ansvarar för verksamhetens krav och produktens return- on-investment, utvecklargruppen som ansvarar för att på ett självorganiserande sätt leverera lösningar på projektägarens krav och Scrummästaren som ansvarar för processen och ser till att alla eventuella hinder för utvecklargruppen undanröjs.
Utvecklargruppen är tvärfunktionell - alla kan göra arkitektur, alla kan göra design, alla kan programmera och alla kan testa. Några må vara bättre än andra, men alla kan och förväntas hjälpa till om en flaskhals skulle uppstå. Självorganisation är en av hörnstenarna. Det är upp till gruppen att komma överrens om vem som gör vad och när. Anpassning efter förändringar värderas högre än att följa en plan. Empirisk fakta väger tyngre än teoretiska antaganden. Erkännandet att världen och även mjukvaruprojekt är i ständig förändring medför att även metoderna för systemutveckling måste förändras. Mjukvara är en ny produkt varje gång, för varför skulle någon vilja bygga mjukvara som redan finns?
Under den andra kursdagen blir diskussionerna allt livligare. Andrew och Dharmesh berättar om problemen de lider av på grund av att deras projekt delas upp i grafisk design- och utvecklingsprojekt. Mel som är systemarkitekt berättar om svårigheterna med att införa Scrum på sitt företag, som i genomsnitt spenderar 14 månader per projekt åt ren processformalia. Många av oss är vana att jämföra estimat med rapporterad nedlagd tid för att sedan kunna göra bättre uppskattningar i framtiden. I Scrum bryts krav inte ned i uppgifter förrän strax innan de ska implementeras. Nedbrytningen sker alltså just-in-time, och utförs av samma personer som ska implementera kraven. Istället för att rapportera nedlagd tid rapporteras fortlöpande återstående tid för varje uppgift.
Marco som har ordnat det praktiska kring kursen bokar bord till middagen. Kvällen avslutas med en trerätters middag, vin, grappa och cigarr på en fin restaurang i källaren på Palazzo delle Stelline.
Dagen efter går Ken igenom uppskalning av Scrum i stora projekt och offshoreutveckling. Principerna är desamma men man kan räkna med att få göra avsevärda justeringar av sina tidsuppskattningar i projekt som skiljer sig från "sju personer i en optimerad miljö". Någon i gruppen flikar in, apropå offshore-utveckling, att olika tidszoner faktiskt kan vara en fördel. Kursen avslutas efter lunch den sista dagen, vilket är räddningen för den del av sällskapet, inklusive undertecknad, som suttit uppe ganska sent kvällen innan. Speciellt den annars så talföre Dharmesh lider av sviterna efter den toxiska kombinationen av cigarr och grappa. När vi skiljs åt har Ken utnämnt oss till certifierade ScrumMasters. Han berättar att avsikten med att certif iera människor i Scrum är att rädda metoden från den fälla som bland annat Capability Maturity Model och eXtreme Programming fastnat i. Mark Paulk, skaparen av just CMM lär ha uttryckt stor frustration över att CMM har kommit att användas på sätt som inte alls var hans avsikt. Joseph från Schweiz, som sysslar med att införa XP i organisationer, flikar in att han sällan ser några framgångsrika exempel på organisationer som framgångsrikt lyckas införa XP på egen hand.
Nyss hemkommen och trots en något omtumlande natt med trassliga taxibilar och parkeringsbiljettautomater, känner jag mig otroligt inspirerad. Scrum vänder upp och ner på många av de "sanningar" vi har lärt oss om hur man organiserar mjukvaruprojekt.
