GOTO-guru: Agile metoder er gift på ledelsesniveau

GOTO: Når hele organisationen skal arbejde agilt, går det galt. For lige så godt, agil udvikling fungerer i et lille team, lige så håbløst er det, når det spreder sig, lyder budskabet fra agil-guruen Dan North.
Illustration: Jesper Kildebogaard

At bruge agile arbejdsmetoder på højere niveau end det enkelte udviklerteam er som at få en bil til at flyde. Jo, det kan den godt, men det kræver bare lige, at man bygger en færge uden om.

Sådan lød det provokerende fra udvikleren Dan North mandag på udviklerkonferencen Goto i Aarhus, og han var godt klar over, at han bevægede sig ind i et minefelt af meninger.

»Jeg er nået frem til, at agile metoder ikke skalerer, og jeg ved, at folk vil kaste ting efter mig for at sige det. Så håber jeg bare, at det er penge, og ikke rådden frugt,« sagde den veloplagte brite, som indledte sporet ’When the agile manifesto isn’t enough.’

Agile arbejdsgange kan være rigtig fine i et lille team – men når metoderne bliver brugt på hele projekter, der består af flere små teams, begynder det hurtigt at gå galt, forklarede han og kom med et eksempel fra egen krop, nemlig et projekt, hvor han var leder af ét team ud af fire.

De andre teams meldte alle tilbage til projektledelsen, at alt gik fint, hele vejen igennem, mens Dan Norths team var det sorte får hos ledelsen. De havde nemlig mange meldinger med gult og sågar rødt lys, hvilket fik cheferne til at ryste i bukserne. Forklaringen på de alarmerende lyssignaler var et løbende behov for at få nogle beslutninger hos ledelsen på plads, fordi de skulle være ens for hele projektet – ellers kunne teamet ikke meningsfyldt komme videre.

Da projektet var overstået, var landsresultatet, at de tre andre teams, ’duksedrengene’ med kun grønne lamper, aldrig nåede i mål med deres bidrag. De havde ikke på samme måde været opmærksomme på, at der var brug for fælles fodslag.

Moralen var, at der på niveauet over selve eksekveringen – altså hvor krav og funktioner bliver omsat til kode – er brug for noget helt andet end agil tankegang. Her skal der være visionær ledelse, der sætter en fælles retning.

»Det er historien om, hvad der sker, hvis du prøver at tage beslutninger ud fra et dårligt grundlag. Først når alle ved, hvad de globale principper er, kan de tage gode, lokale beslutninger. En god leder skaber kontekstuel konsistens. Hvis du vil have folk til at bygge en båd, skal du ikke fortælle dem om forskellige slags træ, men give folk en smag af havet. Så skal de nok bygge et godt skib,« sagde Dan North.

Der var i øvrigt slet ikke noget galt med agile metoder i selve softwareudviklingen, altså på team-niveau, understregede han.

»Agil udvikling er fantastisk til eksekveringen. Jeg har ledt i ti år, men jeg har ikke fundet noget, der er bedre,« sagde han.

Version2 er mediepartner på Goto-konferencen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Allan S. Hansen

Ikke at jeg er specielt større fan af agilt som løsningen på alt og sådan noget....

Men er det ikke mere et produkt af at en metode og processer kun er så gode som de folk der skal udføre dem?

Man kan have nok så meget kontrol eller tiltro til folk, men hvis de blot melder 'grønt' tilbage uden hensyntagen til virkeligheden - så er problemstillingen vel egentlig ikke metoden/metodikken der er benyttet?

  • 2
  • 0
#4 Pelle Söderling

Allan: Som jeg forstår den del så er problemet snarere at de enkelte teams mangler det samlede overblik og dermed også hvilke ting der bør håndteres på et mere globalt plan fremfor lokalt plan. Det vil selvsagt give den slags udfordringer når man tager tingene lidt mere som de kommer, fremfor at tage nogle design- og principbeslutninger på et højere niveau som så lægges ud til de lokale teams.

  • 0
  • 0
#5 Morten Elvang-Gøransson

Alle er vel efterhånden enige om at den 'agile' arbejdsform fungerer rigtig godt på team niveau (når den fungerer :)) ... for at få effekt i større organisatorisk sammenhæng er der brug for noget infrastruktur. Det der skaber effekten i teamet er ikke det samme som skaber effekten i organisationen. Der findes rigtig mange bud på hvordan det kan gribes an og også rigtig mange erfaringer - e.g. SAFe, Flow, ... - er derfor ikke enig i konklusionen om at agil ikke skalerer. Men er enig i, at det der får tingene til at køre i et team ikke er det samme som det der får det til at køre i hele organisationen. Stiller gerne op til yderligere debat :)

  • 0
  • 0
#6 Allan S. Hansen

Allan: Som jeg forstår den del så er problemet snarere at de enkelte teams mangler det samlede overblik og dermed også hvilke ting der bør håndteres på et mere globalt plan fremfor lokalt plan. Det vil selvsagt give den slags udfordringer når man tager tingene lidt mere som de kommer, fremfor at tage nogle design- og principbeslutninger på et højere niveau som så lægges ud til de lokale teams.

Men jeg har svært ved at se det som et resultat af at processen var agil - mere end at det er andre mangler.

Nu ved jeg ikke hvad analyse arbejde der ligger til grund for konklusionen, men det virker lidt på mig som den gamle 'Correlation/causality' aspekt.

Sådan noget i stil med at 'det fejlede - vi brugte agilt - derfor må det være agilt der fejlede', mere end at det var menneskerne der ikke havde fokus/indsigt/information og i stedet for at arbejde for at opnå fokus/indsigt/information arbejde de blot videre. Det kan også ske med andre modeller og teknikker.

Der nævntes jo 'duksedrengene' ikke leverede (hvilket indikerer at det ene team, med han som leder, gjorde). Det tyder stadig for mig på at det handler om personerne mere end teknikken. Fordi hvis det ene ud af fire teams kunne, så ville de andre også have kunnet. Med mindre der definere det som umuligt? Forudsætningerne burde jo være de samme for de fire teams hvis man skal konkluderer ret meget.

  • 1
  • 0
#7 Pelle Söderling

Allan: well, for mig at se handler de her metoder mere om hvordan man får noget produktivt ud af folk der ikke er eksperter i det de laver.

Hvis du har folk som Dan der formår at sætte tingene i et organisations-perspektiv og se ud over sin egen næsetip - altså grundlæggende ret så intelligente mennesker - så er arbejdsmetoden ligegyldig, så skal der nok foreligge et resultat.

  • 0
  • 0
#8 Frank Vilhelmsen

Den rebelsk Dan North udtaler at han ikke mener at "Agile Development" ikke kan kan håndtere politiske forviklinger mellem teams der ikke arbejder mod samme forretningsmæssige mål.

Og i den betragtning er jeg enig.

Jeg er også enig i at "Agile Development" i langt de fleste tilfæde ikke har nogen betydning på om et projekt lykkedes eller ej.

I min tid som konsulent med mere end 25 større projekter har langt hovedparten "udtalt" at vi har brugt adrætte metoder. Det har været bullshit bingo a la carte. Ikke fordi vi har ville snyde men kun fordi det reelt er umuligt at rokke monumentalt ved menneskers arbejdsproces. Og mange af projekterne er blevet færdige alligevel, nu bare med en superimposed agil model. Kun ganske få af de hundredvis af udvikler jeg kender har på noget tidpunkt fungere i et ægte selvstyret tværfagligt projekt med med værdier som kommunikation, åbenhed, feedback og mod. Ib Rene #gotoaar - lige ved siden af Dan..

  • 1
  • 0
#9 Allan S. Hansen

Allan: well, for mig at se handler de her metoder mere om hvordan man får noget produktivt ud af folk der ikke er eksperter i det de laver.

Hvis du har folk som Dan der formår at sætte tingene i et organisations-perspektiv og se ud over sin egen næsetip - altså grundlæggende ret så intelligente mennesker - så er arbejdsmetoden ligegyldig, så skal der nok foreligge et resultat.

Hvilket igen tyder på det ikke er metoden der var problemet, men folkene der ikke magtede opgaven?

Alt handler om at vælge de rigtige værktøjer til opgaverne, og en faktor er de folk der skal arbejdes med. Fordi hvis det havde været metoden, ville jeg have forventet alle teams fejlede.

  • 0
  • 0
#10 Pelle Söderling

Hvilket igen tyder på det ikke er metoden der var problemet, men folkene der ikke magtede opgaven?

Jamen grundlæggende enig :-) Mennesker betyder langt mere end metoder.

Scrum har den store fordel at vi udviklere oftest kan få lov at arbejde uden at det er under alt for bureaukratiske forhold - derfor kan jeg godt lide Scrum. Men kun fordi alternativet somregel er langt værre og Scrum er nem at overtale ledelsen til i disse dage.

Men har man de rette folk er ledelse på det niveau grundlæggende unødvendig, så skal de nok løse opgaven uanset hvilke principper der trækkes ned over hovedet på dem.

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