AgileFall - når vandfald sniger sig ind i Agile

Jeg har tidligere her på bloggen skrevet en del om agile projekter, og der har været en god og sund debat blandt læserne om hvad det der agile egentlig er for noget. Og hvis man har kigget lidt på min backlog, vil man kunne se at det er et emne jeg vil komme tilbage til.

Nu er jeg igen faldet over et interessant indlæg et andet sted, der er udmærket som udgangspunkt til at debattere det agile igen igen.

Her er et link til artiklen: https://steveblank.com/2019/09/17/agilefall-when-waterfall-sneaks-back-i...
(læs den først, inden du læser videre her)

Forfatteren skriver lidt om en situation, hvor man tilsyneladende forsøger at arbejde på en agil måde, men så ender med alligevel at gøre nogle ting, der lugter meget af vandfald. Der er her tale om en virksomhed, som rent faktisk forsøger at være mere agil, og som er i gang med at flytte sig fra vandfald til Lean. Der bliver omtalt 15 projektledere, der styrer 60 forskellige projekter (her kan man da tale om skaleret Agile).

Problemet her var at den øverste chef for disse projekter stadig styrer projekterne via en masse forskellige dokumenter og i øvrigt har en meget langvarig proces for release management (tre måneder med en bureaukratisk review proces). Det var så ikke nødvendigvis hans skyld altsammen, men skyldes langt hen ad vejen at resten af organisationen stadig er ret domineret af vandfald og derfor arbejder ud fra nogle andre principper.

Og hvad er så lige problemet her?

For det første, så lad os lige se på hvad det der agile egentlig er for noget. Jeg skrev faktisk noget om det sidste år, da jeg startede denne blog. Det handler om et manifest, der bl.a. fortæller noget om nogle meget overordnede principper. Det er altså ikke en bestemt metode, og der er nok ikke rigtig nogen, der kan tage patent på det og sige at den og den metode er agil. Faktisk er det sådan i dag at stort set alle organisationer gerne vil fortælle at de arbejder agilt - også selv om metoderne måske i virkeligheden ligger ret langt fra de tanker der lå bag begrebet, da det blev skabt på et møde tilbage i 2001. Men måske er problemet også at selve begrebet Agile opstod på en agil måde :-) De personer, der mødtes i en forlænget weekend for efterhånden en del år siden og fandt på begrebet Agile, havde jo hver deres metoder, som de syntes var gode. Og ud fra det forsøgte de så at finde nogle fællesnævnere og også gerne et fælles ord, der dækkede det hele. Det blev så til ordet Agile, som siden da er blevet misbrugt til ukendelighed.

Hvad er så det der vandfald for noget? Ja, faktisk er det heller ikke en egentlig metode, men nærmere et skældsord som er brugt om visse strukturerede metoder, hvor man arbejder i veldefinerede faser, f.eks. analyse, design, konstruktion, test og implementering. Der er faktisk slet ikke noget galt med at anvende vandfaldsbaserede metoder, hvis det er det, der giver mening i forhold til det enkelte projekt. Og i virkeligheden består mange agile metoder faktisk af en masse små vandfald.

Så når folk bruger udtryk som AgileFall, ScrumFall, Water Scrum Fall og lignende så handler det (efter min mening altså) mest om at folk slet ikke forstår metoderne, men bliver religiøse i forhold til begreberne.

Sagen er at der ikke er én bestemt metode, der er vandfald, og der er heller ikke én bestemt metode, der er Agile. Sandheden ligger (som nok altid) et sted midt imellem ekstremerne. Hvilke metoder, man anvender i den enkelte organisation, skal jo altid tilpasses til lige den organisation (med den bestemte type forretning) og det enkelte projekt. Efter min mening opstår problemerne (som her i den aktuelle artikel) når beslutningstagerne tror at man bare kan køre en procesmodel ind over det hele og kalde det Agile. Man arbejder ofte med hovedet under armen uden at tænke over hvad den dybere mening med modellen egentlig er.

Jeg har arbejdet i organisationer, hvor man har forsøgt at arbejde med Scrum/Agile på et tidspunkt men så har opgivet det, fordi modellen ikke rigtigt duede. Jeg synes jo det er smartere at anvende de relevante dele af en model i hvert tilfælde fremfor bare at sige at nu kører vi alle sammen Scrum/XP/Lean/Kanban/Agile og så presse en eller anden procesmodel ned over hovedet på folk.

At være Agile (eller agil på danglish) handler jo bl.a. om at kunne træffe hurtige beslutninger, og det betyder blandt meget andet at man har uddelegeret et vist niveau af kompetence og mandat fra et overliggende chefniveau til dem, der er udførende i projektet (f.eks. et Scrum-team), men hvis cheferne så stadig forlanger den samme type dokumentation som før, så er vi jo lige vidt. Agilitet fordrer at hele organisationen forstår hvad det indebærer og er indforstået med en vis uddelegering, og i virkeligheden handler det ret langt hen ad vejen om forventningsafstemning.

Som konsulent har jeg kontakt til mange virksomheder, og på et tidspunkt talte jeg med en virksomhed, som havde mange projekter i gang. Et af dem kørte agilt, fik jeg at vide. "Ja, for vi afleverer vores krav til dem, og så kører de det agilt!"

(den opmærksomme læser må selv se hvad der er galt i den sætning)

Hvad mener du, kære læser? Findes der agile metoder, som duer, eller er det hele bare gammel vin på nye flasker? Er Agile endnu et fortærsket buzzword, som hører hjemme i Bullshit-bingo, eller kan det bruges til noget ude i den virkelige verden? Er det hele noget Agile Bullshit eller duer det til noget, hvis man forstår hvordan det implementeres?