Agile eller Kaos

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.

Vi går på de kritiske stier.

Software projekt planer og parallel processering viser mange fælles træk. Feks skrev Amdahl i 1960’erne Amdahls lov, som på viser at de fleste algoritmer ikke opnår en lineær forbedring i køretid ved en tilsvarende stigning i antallet af processerings elementer. Altså en dobbelt så hurtigt CPU, udfører ikke algoritmen dobbelt så hurtigt – i mange tilfælde i det mindste.

I 1975 fik vi så brooks’s lov, som sagde ”tilføjelse af ressourcer til et forsinket software projekt gør det mere forsinket.

Egentlig udtaler de sig om det samme. Nemlig det faktum at der er afhængigheder i software, og at uanset hvad du finder på, kan du ikke optimere din plan ud over den kritiske sti, nemlig den tid det tager at skrive det stykke software som ikke kan paralleliseres i sin udførsel. Vores byggesten har i mange år været de samme, filer der kompileres – kalder hinanden på kryds og tværs og til sidst udgør et hele med den ønskede funktionalitet. Disse filer er en slags atomer, som på sin vis bliver det mindste det giver mening at arbejde på, for et menneske. Man har prøvet at lade flere mennesker arbejde på den samme fil, men det viser sig for det meste, at tiden med at koordinere arbejdet bliver højere end selve det at skrive softwaren. Størrelsen af atomerne i vores tilfælde filerne er delt op efter funktionalitet, hvad enten vi udvikler objekt orienteret eller i ren c. Funktionaliteten kommer fra beskrivelsen af domænet, altså virkeligheden.

Gustavsons lov fra 1988 redede parallel algoritmerne, og viste at jo der var noget at hente, hvis bare der var data nok at arbejde med. Men det reder desværre ikke vores projekt planer. Men den beviser at man lige så godt kan udvikle mere funktionalitet i den tid der alligevel bliver brugt på at udvikle den sekventielle del. Selvfølgelig forudsat at de ingen afhængigheder har til resultatet af den sekventielle del og dermed bidrage til et bedre og mere rigt produkt.

Netop derfor er vi glade når vi ser en software arkitektur som udgør et framework. Når først vi har et framework kan vi nemlig begynde at parallelisere vores opgaver i det uendelige. Web services er et godt eksempel – på hvordan alle glæder sig til at ”bare” at skulle lave nye services til et eksisterende framework og lave en mashup der trækker på de services der er nødvendige. Der er ikke noget nyt i det, ud over at vi går imod en større standardisering af vores løsninger, nemlig et fælles framework for hele verden. Men der er stadig afhængigheder mellem vores mash up og vores services, præcis som der altid har været, og vi skal stadig definere vores services, men vi bruger det som en IASP.

Nogle vil måske sige, hvad så med kreativiteten? – tja hvad skete der med industrien da man fik standarder på bolte, møtrikker og skruer? Jeg tror ikke man kan sige at den blev mindre kreativ, og materialerne bliver bedre og bedre og opfindelserne ikke mindre.

hjælp jeg er selvorganiserende

Vi har en flad selvorganiserende organisation var der en dag en der sagde til mig. Og jo, de lavede software. Man kan smage lidt på ordet selvorganisation. Hvad betyder det egentlig? – Ja det betyder at et system kan stige i kompleksitet uden at nogen eller noget har fortalt hvad retning det skal tage.
Sådan en organisation havde de altså – en organisation som ændrer sig til mere komplekse former uden grund, eller uden at nogen havde forlangt det. Scrum bruger tit ordet til at beskrive Scrum teams, og det er måske nok lidt overdrevet, at 5 til 6 individer skulle kunne blive til en mere kompleks organisation uden at nogen havde forlangt det. Som tidligere skrevet er organisation et spejl af din arkitektur. Så konsekvensen af en selvorganiserende software organisation må være en selv organiserende arkitektur. Hverken mere eller mindre – og det er spændene. For det betyder jo, at software arkitekter i den forbindelse, hvis de får lov, er en slags gud der giver tingene et design inden de udvikler sig, hvorimod den selvorganiserende software udvikler sig af sig selv. I naturen har det så vist sig at det når taget temmelig lang tid med sådanne selvorganiserende strukturer, også længere tid end kunden vil vente på et stykke software uanset hvor genialt det så måtte ende med at blive. Men faktisk tror jeg at vi i mange år i software udviklingens kunst, har lagt op til at de strukturer vi byggede skulle være selvorganiserende i et vist opfang. De fleste af de mønstre vi anvender, går jo netop på at afkoble de enkelte dele så de kan udvikle sig frit, under så lidt hensyn tagen til resten af projektet. Den service orienterede arkitektur er vel det sidste skud på sammen, hvor alle kan bidrage med services, som kobles på, kan findes, bruges og anvendes af andre. Men det betyder jo ikke at den enkelte service er lavet af en selvorganiserende projekt gruppe.
Selvorganisering virker nemlig ikke så godt når mennesker er blandet ind i det - vi tænker for meget – ligger for mange planer, og vil til enhver tid udnytte de svagheder et system har til vores egen fordel. Derfor tager Scrum og selvorganiserende teams ikke højde for den menneskelige psykologi, og da slet ikke at vi har forskellige evner. Prøv at stil dig selv spørgsmålet, hvilke rolle er der brug for i et Scrum team? – er det ligegyldigt fordi det finder de selv ud af, fordi de netop er selvorganiserende? Jeg tror ikke på det, for hvis et team skal være effektivt er det nødvendigt at der er lidt af hvert på det team, en med de gode ideer, nogle der kan kode, nogle der kan teste, en build manager der kan styre den side af sagen osv. Det er så rigtigt nok, at hvis man bare tager tilfældige folk uden at have en ide om hvad deres stærke og svage sider er, så er selvorganisering nok det bedste bud på den højst opnåelige effektivitet. Men vi ansætter jo ikke tilfældige mennesker (endnu), og vi ved godt at et effektivt team har medlemmer med forskellige roller, for vi vil gerne have at vores team har en performance der er bedre end hvad tilfældigheden kommer med. Jeg er træt af ordet selvorganisation og synes vi skal bruge ordet selvstyrende i stedet. Selvstyrende betyder jo at en lille organisation selv kan tilrettelægge arbejdet på den måde den finder bedst for at nå de mål organisationen står overfor. Det kan man desværre ikke i Scrum, der er regler der skal følges og en product backlog der definere målene med hvert eneste sprint. Så et team får et lille råderum på 3 – 4 uger, med tasks der maximalt er et vist antal timer. Det er ikke selvstyrende – og om det er selvorganiserende er også ligegyldigt, for det hjælper ikke.

Scrum fra dag 1..eller?

Software arkitektur handler om facon og form hørte jeg den anden dag. Hvor er faconen så henne – ja den ligger i de abstrakte base klasser. Og hvad kan man så bruge det til? – jo det er fra arkitekturen at projektplanen fremtræder. Det er her mellem streger og kasser at de parallelle spor findes. Det er her man får overblik over hvad der kan udvikles parallelt og hvor der er afhængigheder som udgør de kritiske stier som skal betrædes for at få det til at lykkedes.
Rækkefølgen hvor i hvordan software skrives er derfor ikke ligegyldig, det gælder om at starte det rigtige sted for at opnå parallelitet i projekt planen og dermed udnytte de hænder man har til rådighed bedst muligt. Svarende ligger i arkitekturen fordi vores traditionelle lagdelte arkitektur har afhængigheder. Enhver form for relation mellem software, hvad enten det er en webservice, et c modul, en java klasse giver en afhængighed. Så kommer spørgsmålet når man så tager sit første sprint, hvad skal vi lave? Det ved product owneren. Han har en plan med sprintet. Og vi tager den plan, laver vores backlog, bryder ned til tasks – men hvad skete der med paralleliteten?. Kan vores product owner gennemskue arkitekturen og se at her er et godt sted at starte fordi det betyder at vi om en eller to uger kan rampe up og starte en masse i parallel og give projektet fart. Næppe. Jeg har aldrig set en product owner der kunne. Kunden i den anden ende kan slet ikke. Og er sikkert også ligeglad, kunden forventer at vi gør hvad vi kan for at levere hans produkt så hurtigt så muligt. Derfor sander scrum til. Det er simpelthen langsommere at lave software på den måde, fordi vi ikke tager højde for at noget kan udvikles parallelt.

UML og scrum:
I UML findes der 6 forskellige måder at beskrive afhængigheder på i software. 4 omhandler kommunikation og 2 struktur.

De 4 der omhandler kommunikation er:
Afhængighed
Associering
Aggregering
Og komposition.

De 2 der omhandler struktur er:
Generalisering og realisation.

Afhængighed, ligner en association, så den tager vi bagefter.

Man laver en association ved at erklærer den man associerer til i sin egen klasse. Hvis det skal kompilere skal man altså mindst have et skelet af den man associere til, ellers er erklæringen ugyldig. Og hvorfor så lave sådan en? – jo typisk skal man jo bruge de metoder som den associerede klasse tilbyder, så hvis det skal kompilerer skal man altså også som minimum have metoderne i den klasse erklæret. Der er altså en rækkefølge ved denne type af afhængighed. Noget man er nød til at implementere før man kan bruge det.

Afhængigheden laves ved at gøre det samme, men nu er erklæringen af den man associerer til ikke i sin egen klasse, men derimod i en metode i sin egen klasse. Den er altså lokal og ikke som sådan en del af klassen selv. De er mere dynamiske og opstår runtime og forsvinder igen når metoden returnerer. Men igen er der en rækkefølge.

Aggregation, er en specialisering af association. Men i praksis har det ingen betydning. Koden er fuldstændig mangen til en association!.

Komposition er igen en specialisering af association. I C++ kan man se forskellen ved at den klasse man har en komposition til er erklæret som en variable og ikke en pointer. I Java er der ikke har pointere, er der igen ingen forskel på koden.

Fælles for disse er altså at noget skal findes før det kan bruges i andre klasser. Og det er man nød til at tage højde for i sin planlægning af sit projekt. Et rigtigt godt udgangs punkt er skelettet. Det gør at koden kan kompilerer, man kan hurtigt få sin struktur implementeret og teste om softwaren har det rigtige flow igennem den ”use-case” man ønsker, inden man fylder algoritmer og funktionalitet på.

Hvis man derimod går efter funktionalitet og begynder at fylde det ind, inden skelettet er på plads sker der tit det at de metoderne ikke bliver generelle nok til at håndtere andre use cases af lignede art. De andre udviklere på teamet går i stå, de kan ikke kompilere deres kode, fordi de mangler metoder. Når metoderne ikke bliver generelle nok skal der ”refaktorering” til. En metoder skal have en argument mere på, og det kan ikke kompilerer, da alle andre kalder den samme funktion med et nu forkert antal parametre. Det griber om sig.

De strukturelle afhængigheder som der findes 2 af i UML er følgende.

Generalisation er arv, det vil sige at man arver en del af de egenskaber en anden klasse har. I C++ er det bare et enkelt : og i Java, extends der gør det for en. Hvad man arver er forskelligt afhængig af hvordan den klasse man arver fra er skruet sammen. Men faktum er at klassen skal være der, før man kan arve. En finurlig ting ved arv er polymorphi, som kommer fra græsk og betyder at have flere former. Det basale er at hvis den klasse man arver fra har erklæret en metode virtual, ja så kan man overskrive den. Man skal dog holde sig til den samme erklæring, parametre etc. Man ser det mange steder i den virkelige verden, feks i banker hvor vi alle har forskellige kontoer med forskellige renter, som beregnes på forskellige måder.
Hvis man bare går efter en enkel funktionalitet, behøver man ikke bruge det. Man kan sagtens i sprint 1 lave en opsparings konto der kan beregne renter og i sprint 2 lave en real kredits konto der kan beregne renter.

Realisering er typisk brugt hvor man ønsker at gøre brug af det framework ens platform tilbyder. Feks på android er det flittigt brugt til interaktion, swipe, scroll etc. Hvor frameworket kalder din klasse og fortæller dig hvad der foregår mellem brugeren og skærmen, hvor man trykker og hvor hurtigt han flyttede fingeren. I Java er det simpelt, især med moderne editorer, man skriver implements også det interface man vil lytte til. I C++ er det heller ikke så svært, man laver en base klasse hvis metoder er pure virtual og nedarver fra den. Effekten er den samme, der er nogle metoder som man er tvunget til at implementere i sin egen klasse. Poly morphisme og realisation hænger nøje sammen. Feks kunne det betyde at man aldrig kan lave en konto klasse, der ikke kan beregne renter. Altså en sikkerhed for at et interface overholdes.

Det er åbenlyst at det er i disse beskrivelser af afhængigheder imellem de software komponenter, klasse eller moduler vi laver at nøglen til genbrugbarhed, fleksibiliteten til at udvide ligger. Men ved vores produkt owner det?, og kommer det til at stå i produkt backloggen? – næppe. Derfor kan man ikke køre Scrum fra dag 1.

Den Parallelle facon i software

Software arkitektur handler om facon og form hørte jeg den anden dag. Hvor er faconen så henne – ja den ligger i de abstrakte base klasser. Og hvad kan man så bruge det til? – jo det er fra arkitekturen at projektplanen fremtræder. Det er her mellem streger og kasser at de parallelle spor findes. Det er her man får overblik over hvad der kan udvikles parallelt og hvor der er afhængigheder som udgør de kritiske stier som skal betrædes for at få det til at lykkedes.
Rækkefølgen hvor i hvordan software skrives er derfor ikke ligegyldig, det gælder om at starte det rigtige sted for at opnå parallelitet i projekt planen og dermed udnytte de hænder man har til rådighed bedst muligt. Svarende ligger i arkitekturen fordi vores traditionelle lagdelte arkitektur har afhængigheder. Enhver form for relation mellem software, hvad enten det er en webservice, et c modul, en java klasse giver en afhængighed. Så kommer spørgsmålet når man så tager sit første sprint, hvad skal vi lave? Det ved product owneren. Han har en plan med sprintet. Og vi tager den plan, laver vores backlog, bryder ned til tasks – men hvad skete der med paralleliteten?. Kan vores product owner gennemskue arkitekturen og se at her er et godt sted at starte fordi det betyder at vi om en eller to uger kan rampe up og starte en masse i parallel og give projektet fart. Næppe. Jeg har aldrig set en product owner der kunne. Kunden i den anden ende kan slet ikke. Og er sikkert også ligeglad, kunden forventer at vi gør hvad vi kan for at levere hans produkt så hurtigt så muligt. Derfor sander scrum til. Det er simpelthen langsommere at lave software på den måde, fordi vi ikke tager højde for at noget kan udvikles parallelt.

Hvor Scrum fejler

Når Scrum fejler, får man tit at vide at det er da fordi man ikke kører rigtigt Scrum. Det er mig en gåde at så mange højt uddannede mennesker kan fejle med noget alle siger er så let. Det skulle være så let, men er så svært i praksis - det siger alle. Men i stedet for at gøre noget ved det, siger man blot, du kører ikke Scrum rigtigt. Jeg ikke det er mig der kører det forkert, jeg tror det er Scrum der er noget galt med, og jeg siger det højt.

Flere software folk er begyndt at forstå at din software komponent arkitektur faktisk afspejler din organisation. En klog man sagde engang til mig at hvis man sætter 5 software udviklere til en opgave, så vil man højst sandsynlig opdage at man ender op med en arkitektur med lige så mange komponenter, filer, moduler, classer etc. Grunden kommer faktisk helt fra vores ide om ansvar, og i en optimering af at det er dumt at 2 laver det samme - især hvis de ikke ved det selv. Software versions styring er et grundlæggende værktøj, og langt de fleste værktøjer kommer da også med en advarsel hvis man checker en fil ud som en anden også har checket ud. Og hvorfor? - fordi der så er to mennesker der er ved at lave det samme, hvis ellers ens software arkitektur har uddelegeret ansvaret ud i klasser, en mini Saas som jo er et moderne begreb, men samtidig altid har været grundstenen i software arkitektur på alle niveauer. Det giver mange fordele, man ved hvor tingene er, hvem der laver det, hvor ny funktionalitet skal være i arkitekturen, hvor fejl kilden er når en usecase ikke virker som tiltænkt. Det er et helt fundamentalt og sundt princip i software og i organisation.

Men virker det mon også sådan med Scrum. Mit svar er nej, for Scrum tvinger os til at fravige dette fundamentale princip. Alle ved det, og det burde være nemt at rette op på, men ingen gør det, for så kører man ikke Scrum rigtigt mere. Scrum er selvorganiserende. Men det er software arkitektur ikke. Men kan sagtens lave software hvor det er, men det svarer til at køre SOA uden governance, og alt erfaringer viser at det som regel ender i kaos. Du får en arkitektur alligevel, men det er bestemt ikke sikkert det er en du kan lide eller at den er egnet til det du havde tænkt den til.