olav m.j. christiansen bloghoved olav christiansen

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?

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Olav M.j. Christiansen Blogger

Vandfaldsartiklen fra 1970

Faktisk var Winston Royce i sin artikel fra 1970 inde på noget der er ret "agilt".

http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

Den er bestemt en læsning værd hvis man har bere den fjerneste interesse for området.

Meget interessant artikel. Den tror jeg ikke jeg har set før (men noget, der ligner eller er inspireret af den). Den vil jeg nærlæse ved førstgivne lejlighed.

Royce nævner bl.a. problemer med den sene test, og det er faktisk forsøgt løst ved at ændre vandfaldet til det, der oftest kaldes en v-model.

  • 0
  • 0
Søren Pedersen

Agile, som i det agile manifesto, har ikke sine rødder i 17 folk der satte sig i en hytte og definerede reglerne.

De står på den platform der blev lavet tilbage i 80'erne hvor Toyota udviklede en model der udkonkurerede de amerikanske bilfabrikker.

Hvis man tjekker op på det, vil man kunne genkende de principper som Agile Manifesto bygger på.

  • 0
  • 0
Olav M.j. Christiansen Blogger

Det knækked link

Agile, som i det agile manifesto, har ikke sine rødder i 17 folk der satte sig i en hytte og definerede reglerne.

De står på den platform der blev lavet tilbage i 80'erne hvor Toyota udviklede en model der udkonkurerede de amerikanske bilfabrikker.

Hvis man tjekker op på det, vil man kunne genkende de principper som Agile Manifesto bygger på.

Det er en smule mere kompliceret end det, men du har ret: Meget af det, vi i dag kalder 'Agile', har sine rødder hos Toyota (især Lean). Men det var i en helt anden branche, så der er sket en del ændringer i de forskellige metoder, inden det agile manifest blev skrevet. Jeg tror også flere af de metoder, der endte med at blive kaldt 'Agile', ikke har ret meget med Toyota at gøre.

Man kan læse lidt om den oprindelige Toyota-metode her:
https://en.wikipedia.org/wiki/Toyota_Production_System
(læs også om The Toyota Way og Lean Manufacturing)

Jeg overvejer om man ikke burde dykke lidt længere ned og prøve at dokumentere mere præcist hvilke metoder, der har indflydelse fra hvilke andre metoder, og jeg vil ikke udelukke at jeg vil tage det emne op på et senere tidspunkt.

  • 0
  • 0
Søren Pedersen

Efter min opfattelse er deres kobling er på principniveau og ikke metoder.

De fem principper som jeg kender dem
1) Identificer kundens behov
2) Kortlæg værdistrømme
3) Skab flow
4) Introducér flow
5) Stræb efter perfektion

Forskellen på de agile og "vandfalds" metoderne er, at i de først nævnte har man fokus på disse fem principper. Hvor den mere klassike model ikke har alle principperne indbygget, eller først har dem senere i processen eller slet ikke.

Jeg overvejer om man ikke burde dykke lidt længere ned og prøve at dokumentere mere præcist hvilke metoder, der har indflydelse fra hvilke andre metoder, og jeg vil ikke udelukke at jeg vil tage det emne op på et senere tidspunkt.

Kunne være super fedt at se et take på dette :)

  • 0
  • 0
Olav M.j. Christiansen Blogger

Kunne være super fedt at se et take på dette :)

Jeg skal gerne gøre et forsøg. Tænker at der måske allerede er noget på nettet et sted. Her er f.eks. et kort over de forskellige ting, der hører hjemme i div. agile metoder:
https://www.agilealliance.org/agile101/subway-map-to-agile-practices/

Og her er (fra samme sted) en tidslinje:
https://www.agilealliance.org/agile101/practices-timeline/

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