Det var med spænding at jeg sad og så en video med David Douglas, som er kariere konsulent og co founder af Innovel og ledene træner i Scrum, Agile og Lean. Overskriften er ” We suck less” is not enough.
Endelig var der måske en der ville tage fat i problemerne med Scrum, Agile og hvorfor det fejler så tit. Faktisk kom de med eksempler på firmaer som var gået væk fra Scrum, efter at de faktisk havde haft noget succes med de starten, de var gået tilbage til en mere kontrolleret måde at gøre tingene på…det sagde han faktisk..
Det er David Douglas’s svar på problemerne man må undre sig over. Svaret er at ændre sin organisation – for det er derfor Scrum fejler. Organisationen følger ikke med udviklingen.
Problemet var ifølge de to herre, at de gamle stive folk sad tilbage i deres linie organisationer og ikke er villige til at give slip. Det er jo spændene taget i betragtning at vi i mange år har arbejdet i matrix organisationer.
Agile sander altså til hen af vejen fordi organisationen ikke følger med, eller som de siger ” Agile adoption without organisation change is unstable and is likely to regress and get unstable”. Af gode forslag er der eksempler på nogle der har organiseret sig efter team metaforen.
Men vi er lige nød til at overvejer hvorfor vi har organiseret os som vi har inden vi gik i gang med Agile og Scrum.
Min påstand er stadig at hvis du ikke organisere dig efter din software arkitektur så går det galt. Når du står med din komponent arkitektur, kigger ud over den, så har du din organisation. Mindst et team til hver komponent, og måske flere komponenter til et team. Men der kan ikke være en komponent uden team, for så bliver den bare ikke lavet.
En software komponent er typisk det man i dag vil kalde en service. Altså en samling af funktionalitet som tilbyder sig i et samspil med andre komponenter for at kunne udføre en given usecase til gavn for brugeren.
I Scrum er man organiseret i cross functional teams, for at kunne dække en given usecase i et sprint. Man laver altså et team, med en fra hver komponent som indgår i den usecase man ønsker at give liv. Problemet er jo bare at komponenterne ikke findes endnu, de skal først udvikles, og det er her det går galt. Hvis man skal noget med Agile skal man ikke gøre som de to herre foreslår. Man skal ikke have cross functional teams, hvor en mand sidder med en komponent. I stedet foreslår jeg at man organisere sig efter sin komponent arkitektur, samler teams til hver komponent. Det kræver naturligvis koordination mellem komponenterne, fælles mål at arbejde hen imod, men med respekt for de afhængigheder der er indbygget både inden i de enkelte komponenter, og komponenterne imellem – og det er jo derfor man laver en projekt plan, med afhængigheder.
Den arkitektoniske udviklings model har flere fordele, som vi i Agile har smidt væk, eller kommer til at gøre hvis vi følger det råd de to konsulenter foreslår. Hvor blev vores specialister af – og hvor kommer de fra?. Jo de bliver netop skabt i samspil med andre af samme race, altså af at side sammen med andre der laver det samme. I en Agile organisation som vist på tegningen, er specialisten væk, og alle er det samme, kan det samme og har lyst til det samme. Udvikleren bliver generalist, og det står enhver frit for at vælge en task på Scrum tavlen for der er ingen specialister mere.
Ingen kommentarer:
Send en kommentar