anders lisdorf bloghoved

Agil arkitektur - hvornår skaber selvorganisering den bedste arkitektur?

Moseloven indenfor den agile verden er jo the agile manifesto. Der er tolv principper, som skal følges. Der er mange gode og produktive tanker i det, som helt klart startede en tiltrængt bølge på det tidspunkt det kom frem. Men jeg har altid undret mig over det 11. princip: "The best architectures, requirements, and designs emerge from self-organizing teams”. Det virker dog mere som et postulat, end et princip.

Nu har jeg tidligere arbejdet som arkitekt både med agile teams og med mere klassisk organiserede udviklingsprocesser og det kan selvfølgelig godt være, at de agile teams ikke har fulgt manifestoet rigtigt, men det er ikke umiddelbart mit indtryk, at der er belæg for denne påstand. De mest forfærdelige arkitekturer jeg nogensinde har set er produceret af agile teams. Der er dog heller ikke i mine observationer belæg for at antage, at det er den agile metode som sådan, der er årsag til dette. Jeg synes ikke jeg har nok observationer og samtidig har jeg heller ikke kendskab til graden af compliance med den agile metode.

Noget kunne dog tyde på at lignende indsigter også er gjort i den agile verden. Gabriele Benefield, en af grundlæggerne af scrum alliance, introducerede for nogle år siden begrebet frankenbuilds til at beskrive den tilstand jeg snakker om. Og det er faktisk en god beskrivelse. Der er derfor et stykke vej fra postulatet i det 11. princip, til den virkelighed, der møder os. Hvordan kan det være? Er det forkert tænkt eller er der noget i udførelsen af agile udvikling som går galt?

Selvorganisering og struktur

Hvorfra kommer ideen om at selvorganisering leder til de bedste arkitekturer, krav og designs? Det er rigtigt at selvorganiserende systemer i naturen har ledt til imponerende strukturer, som virker unikt tilpassede situationen. For eksempel er evolutionen jo en selvorganiserende process, som har ledt til nogle imponerende strukturer, som mange har svært ved at tro ikke kan være designede. Deraf intelligent design bevægelsen. Eksemplerne er legio: bikuben, koral rev, øjet. det er altsammen selvorganiserende systemer. Der findes også en hel disciplin som i udgangspunktet menere at naturen og evolutionenens selvorganiserende processer altid vil have et bedre svar, nemlig biomimetikken.

Man kan godt forstå, at dette kan have inspireret til ideen om at selvorganiserende teams kan være overlegne i forhold til designede løsninger. Naturens selvorganiserende systemer producerer i høj grad overlegne strukturer til at løse specifikke problemer i forhold til menneskelige designere. Men der er også nogle skridt som er taget ud, for selvorganisering skaber i udgangspunktet ikke struktur. Det normale er at systemet bliver kaotisk. Hvis alle dele af et system bare er frit til at organisere sig som det har lyst, så vil der ikke opstå nogen struktur. Hvis vi tager den klassiske med fugle der flyver i flok. Hvis hver fugl eller mindre grupper af fugle blot var karakteriseret ved den egenskab at være selvorganiserende, ville de flyve hulter til bulter og intet mønster opstå. Men det gør fugle flokke ikke. De følger nemlig nogle simple regler.

Første krav til at struktur kan opstå ud fra et selvorganiserende system er derfor, at der er regler. For fugle er det, at man skal lade være med at støde ind i andre, man skal tilpasse sin fart til dem, som er tæt på samt, at man skal prøve at blive så tæt på hinanden som muligt. Disse tre regler er i øvrigt dem, som ligger til grund for al flok opførsel fra fåreflokke til fiskestimer.

Ud fra disse regler kan vi udlede det andet krav til selvorganisering: opmærksomhed på omgivelserne. Hvis man skal finde af at styre udenom andre og finde centrum skal man have information om omgivelserne og kunne bearbejde dem. Der skal altså være en form for sensor.

Det tredie krav kan også udledes: Der skal være et feedback loop. hvis man skal tilpasse sin fart til de omkring liggende skal der være et feedback på farten således at den bremses hvis den er for hurtig i forhold til omgivelserne og speedes op hvis det er for langsomt. Der er tale om et positivt og et negativt feedback loop i forhold til farten.

Men en ting er at skabe en struktur en anden er at skabe den bedste struktur. Her skal vi nok lige kvalificere. Den bedste struktur må betyde den bedst egnede i et givet miljø. Grunden til at fiskens flok opførsel producerer en optimal struktur er at den er tilpasset til miljøet. Den måde som det sker på er ved selektion. Selektion kan i princippet være både naturlig og artificiel og virke, så længe det er de bedste i en generation som bliver udvalgt.

Vi kan altså udlede at for, at der kan opstå en eller anden form for optimal struktur, skal der være fire ting tilstede

1) Regler
2) Sensor
3) Feedback loop
4) Selektion

Agil selvorganisering

Hvis vi applicerer det på agil udvikling kan vi måske bedre forstå, hvordan det fungerer.

1) Regler - Agil udvikling har regler: sprint længde, planning poker, faste roller (product owner, scrum master etc)
2) Sensor - I forhold til omgivelserne, det vil sige brugere og de forretningsmæssige omgivelser, er det product owner som er den eneste sensor, så produktet afhænger i høj grad af denne postitions kvalitet.
3) Feedback loop - focus på brugeraccepttest er en form for feedback loop. På samme måde som at justere hastighed, skal produktet justeres i forhold til forventningerne. Der er også retrospectives som er feedback loop i forhold til processen.
4) Selektion - her arbejder den agile verden ikke rigtigt med noget. Det er meget sjældent man udvælger de stærke og lader de svage strukturer dø, men der er mulighed for det. Refaktoring er et eksempel på dette. Man kunne sige at Lean Start up er den motor som kunne styre det agile selektionspres, hvor man løbende laver prototyper og vælger de bedste ud til egentlig produktion.

Hvor går det galt?

Så alle ingredienserne er altså tilstede i agil udvikling, hvilket passer fint med succesen. Men hvor går det typisk galt og hvor går det godt? Det kan gå galt på alle fire områder og alle teams er forskellige, men hvis man skulle snakke om strukturelle problemer kan man godt pege på punkt 2 og 4, som de mest kritiske. De fleste agile teams plejere at kunne følge reglerne og måske i lidt mindre grad, men dog ikke utilstrækkeligt, at få lavet brugeraccepttest.

Men selve sensoren, product owner, er et oplagt singe point of failure, for hvis denne ikke kan finde ud af, hvad omgivelserne vil have, er resten næsten ligegyldigt. Product owner rollen er også strukturelt udfordret i det den ofte er overbelastet. Her kan man rede det ved at opprioritere rollen eller lave processer til at sikre, at der sker en ordentlig forståelse af hvordan produktet bruges. Gabriele Benefield bruger ofte at tage temaet med til live usability testing, hvor de kan se brugere bruge eller misbruge produktet. Det skulle være en lærerig oplevelse.

Hvis man bruger lean start up er man et godt stykke af vejen, men her er succes afhængig af selektionens effektivitet. Ofte kører man efter AB testning. Her er faldgruben at man ikke har nok data til at resultatet er godt nok til at foretage en ordentlig selektion. Her handler det paradoksalt nok om at lade være med at bruge AB test, hvis man ikke har data nok til det.

En anden grund til selection failure er at man, selv om man ved en variant er mere “levedygtig” ikke får lavet refaktoring af koden. Det betyder at fitness gradvist vil mindskes. Hvis der ikke handles eller hvis selektionsprocessen ikke er god nok vil hele produktet fejle.

Det er altså muligt at finde belæg for det agile manifests antagelse, men i praksis er det langt fra altid at omstændighederne er tilstede. Jeg tror at den næste store barriere for agil udvikling er at finde en passende måde at sikre hvordan de rette signaler fra omgivelserne tages ind og benyttes i de agile teams. Hvad siger brugerne, hvad siger sælgerne, de andre teams, arkitekterne eller endda (gud forbyde det) lederne. Samtidig

Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Kirk

først lige en kommentar på første halvdel af din post: Jeg tror det der menes med selv-organisering er, at folk falder ind i de roller de er bedst til og længere er den ikke.

f.eks. har nogle folk naturlig talent for ledelse, organisering, struktur mens andre er kreative rodehoveder, iderige, legende personer osv...
MBTI åbnede mine øjne for disse forskelle blandt menneker

Og hvis folk ikke tvinges ned i en rolle de ikke kan bestride, fungere teamet bedst og deres samlede produkt vil derfor blive optimalt.


Dernæst så hører jeg om og oplever selv at 'Agile' misbruges på det groveste, oftest fordi ledelsen eller management ikke forstår hvad det går ud på og hvad det indebærer.

Agile betyder f.eks. ikke: "Ledelse / Management kan til enhver tid komme med nye opgaver til udviklere"

Udviklere skal have ro til deres opgaver og fungere bedst hvis de ikke forstyrres hele tiden - og teams fungere bedst i sprint af 1-2 ugers varighed.

Selvfølgelig skal der være plads til at man stopper en udvikling op hvis alle er poå vej ud over klippen, men hvis man gør det hver 3. dag, er det fordi ledelsen ikke aner hvad de har gang i eller hvor de vil hen.

Dernæst så er SCRUM også et begreb som misbruges, igen fordi det ikke implementeres ordentligt og fordi folk ikke ved hvad det går ud på.

Med andre ord, så betyder Agile ikke Anarki - Agile er ligesom alle andre processer en Process - der er regler som skal følges !


btw. Læs denne blog post: http://www.techbroil.com/2014/10/scrum-is-stupid.html

som handler om at management tit har det med at holde så mange møder, at det slår processen ihjel.

  • 2
  • 0
Malik Taaning

Jeg er ikke en scrum fanboy - men jeg synes ikke det er en fair repræsentation af scrum der bliver præsenteret i den linkede artikel.

Eksempel 1-2 hour scrum meeting:
Daily scrum er kort, og det er kun teamet der har tale ret (hint; manager er ikke en del af teamet)

Hr. Jerkface har ikke været i en organisation hvor scrum har været implementeret - han har været et sted hvor de har været buzzword complient.

Jeg mener at scrum er et af de bedste bud på hvordan man kan organisere sig - men lige som alt andet bør man over tid tilpasse processen til personerne.

People > processes - right? :)

  • 0
  • 0
Martin Kirk

Jerkface (Techbroil) er en rant-blog.

Som du korrekt pointere så har han sikkert kun oplevet SCRUM blive implementeret som buzzword compliant, men det skulle ikke undrer mig hvis hans historie er sandfærdig. Hvis teamet består af 20-30 personer kan et 'kort' møde jo nemt vare 1 time.

Jeg oplevede selv et projekt hvor management var skyld i at vi gik over deadline. Løsningen var selvfølgelig at indfører 1-2 ekstra møder hver dag på 20-30 minutter, som så åd en hel masse udviklingstid.

  • 0
  • 0
Log ind eller Opret konto for at kommentere