Det finns mycket intressant och delningsbart från Tomas Gustavssons dagsfärska avhandling ”Inter-team Coordination in Large-Scale Agile Software Development Projects”.

Avhandlingen, som titeln avslöjar, går bland annat på djupet kring mekanismer kring koordinering av beroenden mellan agila team i storskalig agil utveckling i relation till teamens upplevda autonomi. Intressant i det sammanhanget är att teorierna kring koordinering i organisationer sträcker sig tillbaka till 50- och 60-talet. Precis som med lean (och agilt) där teorierna funnits med oss över lång tid. Gustavssons undersöker utifrån ett antal frågeställningar kopplat till koordinering tre case (finans, myndighet, bilindustri). De tre casen delar det gemensamma att de använder ramverket SAFe.

Gustavssons refererar bland annat till Thompsons (1967) definition av beroenden där pooled och sequential är närvarade i alla tre case.  

Pooled interdependenc betyder att är organisationen är beroende av kompetens från en delad pool där det blir utmaningar om kompetensen är begränsad till ett fåtal experter men efterfrågad av många.

Sequential interdependence betyder att output för ett team är input för ett annat team. Team nedströms i processen blir därför beroenden till team uppströms för att kunna göra sitt jobb.

Det finns som sagt mycket intressant att dela, jag väljer här en talande del som har bäring utanför det aktuella caset. I summeringen i slutet i kapitel 11.2 ”Dependencies in large-scale ASD” blir det tydligt vad som händer när man bortser från viktiga bärande delar i lean och agilt som visualisering, gemensam termer och standarder och behovet av koordinering i komplex kontext med flera olika sorters beroenden. Exemplet visar vad som händer när man bortser från dem.

Myndigheten (ett av tre case) valde att visualisera och hantera beroenden baserade på definitionen av Sequential dependency men inte baserade på Pooled interdependenc. Detta trots att observationer sa att de flesta beroenden var av typen Pooled interdependenc. Det här gjorde förstås myndigheten blind för en majoritet av beroendena mellan teamen. Det ledde i sin tur till att man inte hade optimala rutiner för att hantera alla sina beroenden. Vilket i sin tur gjorde att de koordinerade insatserna inte sågs som värdefulla bland medarbetarna, vilket bland annat slutade med att den centrala ”program board” där alla teams beroenden till varandra inom ett agilt tåg visualiseras inte användes.

Om vi inte definierar beroendet, finns det då inte längre …?

Sammanfattning

Mjukvaruutveckling i komplex kontext med många autonoma agila team inblandade ställer höga krav på koordinering och visualisering av beroenden. Roller, ceremonier och visuella tavlor är ingredienser som hjälper till med både koordinering och kommunikation. Ett ramverk kan hjälpa till ytterligare med en ännu mer standardiserad approach.

Traditionellt har det alltid funnits utmaningar i att koordinera stora initiativ kopplat till IT-utveckling. Plandrivna processer och temporära projekt har inte de mekanismer och incitament för att koordinera globala beroenden. En följd av det är de skulder i form av IT-skuld och arkitekturella skuld vi ser idag hos inte minst stora organisationer. Frågan hur ska vi organisera oss för att hantera och koordinera beroenden ställs inte med samma nyfikenhet av management som “blir vi mer produktiva nu”. Innan vi ens kan bli produktiva måste vi på allvar ta itu med beroende genom koordinering och kommunikation för att skapa förutsättningar för kontinuerligt flöde av värde (produktivitet). En anledning till att den viktiga frågan om koordinering inte ställs tillräckligt ofta kan vara att man inte har erfarenhet av hur komplext det faktiskt är med mjukvaruutveckling och hur dåligt koordinering har skett tidigare där projekt ofta har optimerat för delar av systemet och inte helheten. Hur ska vi organisera oss i en komplex och dynamisk kontext? Vill vi ha ut värdet ur processen snabbare och billigare blir vi också skyldiga att resonera kring den frågan och inte bara “time to market”.

Alldeles för många gånger i tidigare roller jag har haft har jag hört organisationer uttryckt ”agilt är inget för oss” eller ”vi testade agilt för x antal år sedan men det funkade inte”. Jag tro inte att det är metoden och tankesättet som har svikit utan snarar inställningen till hur vi ska förena autonoma team med behovet av koordinering av helheten. Att blunda för verkligheten (och tex beroendena) och sen skylla på ett ramverk eller rutiner, oavsett vilket, är nog aldrig speciellt framgångsrikt i längden. Gustavssons avhandling indikerar det om inte annat.