Er man i stand til at kalde sig agil blot fordi man anvender Kanban eller Scrum? Er man per definition rigid bare fordi ens projekt følger en vandfaldsmodel? Er CMMI overhovedet forligeligt med konceptet agile?
Jeg har ikke alle svarene, men jeg har givet det en del tanker: De mest agile teams jeg kender arbejder hverken efter Scrum, Vandfald eller Kanban. Nogle af de mindst agile teams jeg kender følger Scrum metoden slavisk. Sådanne observationer har givet anledning til mange timers fundering over koncepterne. I tillæg kan jeg konstatere at andre også har haft tilsvarende tanker – Se blot Aino og Troels’ indlæg fra GOTO 2014 og den bagvedliggende blog-post af Pragmatic Dave Thomas.
For at finde ud af om man tænker og agerer agilt, så er man nødt til at vende tilbage til kilden – nemlig det Agile Manifest. Therese har skrevet en glimrende artikelserie her på QED om emnet, som jeg varmt kan anbefale. Manifestet beskriver en prioritering af elementer, som alle er vigtige; dog nogen mere end andre.
I min logiske verden har jeg været nødt til at dele skidt for sig og kanel for sig. Det betyder basalt set at min syn på de forskellige koncepter er blevet reduceret til følgende:
- Værdier (Agile, Lean, CMMI, m.v.)
- Styringsmodeller (Scrum, Kanban, plandrevet, m.v.)
- Leverancemodeller (iterativt, inkrementielt og vandfald)
Værdierne
Lad mig starte med de mindst kontroversielle tanker: Værdierne.
De fleste kan acceptere at det at være agil eller arbejde lean er et tankesæt. Vi vægter kundesamarbejde højere end kontraktforhandling, vi bestræber os på at minimere spild, vi arbejder efter forud aftalte arbejdsgange, osv.
Et team kan, på demokratisk vis, debattere og nedfælde disse værdier i en Work Agreement som det kendes fra Scrum. Her kan der evt. nedtones på fleksibiliteten overfor kundesamarbejdet. I visse tilfælde står et team med en udfordring om at skulle løse et stykke kontraktuelt arbejde hvor der ikke kan fraviges meget fra ordren – ligesom det også kan forstærkes hvis man er i den modsatte situation.
En aktiv stillingtagen til koncepter som agilitet, leanificering og CMMI kan således danne fundament og skabe rammer for hvordan et team skal agere.
Fun fact: At være CMMI-compliant er ikke nødvendigvis det samme som at vægte værktøjer og processer højere end personer og samarbejde.
Styringsmodeller
I indledningen nævnte jeg at Scrum ikke nødvendigvis medfører agilitet ligesom at vandfald ikke nødvendigvis medfører rigiditet. Hvordan ser jeg det? Mange vil kalde det et anti-pattern for henholdsvis Scrum eller Kanban når teamet ikke samtidig arbejder agilt, men lige meget hvad, så er det en generel observation at visse teams er i stand til at udføre mekanisk Scrum eller Kanban (dvs. afholde møderne, indføre rollerne og efterleve koncepterne) uden at det ændrer på det fakta at hverken de eller omgivelserne er tilnærmelsesvis agile.
Det betyder ikke at teamet ikke opnår værdi af Scrum og Kanban. Det betyder blot at der ikke kan sættes lighedstegn til agilitet.
Efter at være kommet til den erkendelse, må jeg sande at Scrum, Kanban, plandrevet, m.v., blot er forskellige måder at styre et team og dets opgaver på. Basalt set er Kanban blot en visualisering af arbejde og flow, Scrum er en måde at indføre transparens og ejerskab mens plandrevet bestræber at få et komplet overblik over opgaverne og giver mulighed for langsigtet planlægning.
Fun fact: I den rette cocktail kan det hele faktisk mixes – brug plandrevet styring til at få langsigtet planlægning, Scrum til kortsigtet planlægning og Kanban til daglig opfølgning.
Leverancemodeller
Når koncepterne for værdier og styringsmodeller er konkretiseret er det pludselig meget let at indse at det eneste der mangler er at beslutte hvor tit og hvordan der skal leveres:
- En eller få leverancer (vandfald)
- En eller flere leverancer, men hver leverance bearbejdes flere gange ind til det ønskede resultat er på plads (iterativt)
- Flere leverancer fordelt med jævn kadence (inkrementielt)
Det er meget sjældent at det er de enkelte teams der beslutter hvordan der skal leveres til slutbrugeren, hvorfor det også giver rigtig god mening at opdele som ovenfor. I de tilfælde hvor kunden ønsker at modtage i en eller få leverancer er det pludselig meget fordelagtigt at vælge en vandfaldsmodel der netop adresserer dette.
Fun fact: Når en familie vælger at bygge et nyt hus, så er det netop vandfaldsmodellen der anvendes til styring af leverancer – og alligevel oplever mange nybyggere at processen har været utrolig involverende og konstruktiv (læs: agil)
Nash equilibrium
Hvordan finder man så den helt rette kombination af ovenstående så alle er glade og tilfredse? Til at løse dette har jeg gravet i mine gamle bøger fra universitetet og fremfundet den basale læresætning kaldet Nash equilibrium hvor teamet og kunden spiller overfor hinanden:
Et valg af strategier er et Nash equilibrium hvis ingen af spillerne kan øge deres chancer ved at ændre sin egen strategi.
Med andre ord, for at sammensætte det perfekte mix for netop DIT team og DIN kunde er du nødt til at tage stilling til de tre punkter:
- Værdier
- Styringsmodel
- Leverancemodel
Det er vigtig at alle involverede parter deltager – og tager aktiv stilling til de tre punkter, da det har indvirkning på det fremadrettede arbejde i teamet. Hvis blot ét af punkterne tilgodeser teamet mere end kunden eller vice versa er der ikke længere tale om en tilstand med Nash equilibrium og den ene spiller vinder på bekostning af den anden.
Fun fact: Filmen ”A beautiful mind” er baseret på John Nash og historien om Nash equilibrium
He agilerasmus. Interessant indlæg. Tillad mig at komme med et par kommentarer.
Jeg har som du observeret scrum teams der var super rigide – ligesom jeg har set folk kode C som om det var COBOL og erlang som om det var C. Så jeg er helt enig i din grundlæggende observation og synes diskussionen er både relevant og spændende.
Når det så er sagt så må jeg også sige at jeg ikke køber at værdier, styringmodeller og leverancemodeller kan ses som tre ortogonale dimensioner. Indbyrdes logisk uafhængige. Hvis værdierne er agile giver det faktisk ikke meget mening at køre en streng plandrevet styringsmodel med en vandfalds leverance model.
Jeg har selv fået meget udbytte ud af at gå dybere i en af de oprindelige teoretiske baggrunde for agil tænkning, nemlig kompleksitetsteori (eller som Sutherland angiver inspirationskilden til Scrum: empiriske processer). Med verdensforståelse baseret på kompleksitetstænkning (eller kaosteori) må vi erkende at det ikke er muligt at planlægge eller forudsige særlig langt frem i tiden. Det vil sige den traditionelle måde (vandfald, plandrevet) kan siges at forudsætte en omverden der er tilnærmelsesvis lineær eller kompliceret, men forudsigelig. Når projektet skal fungere i en verden der er kompleks så er det vigtigt at anvende en empirisk proces – en proces der er baseret på inspektion og tilpasning (Inspection, Adaption). Det centrale i valg af styringsmodel og leverancemodel er altså ikke (kun) værdisættet, men i høj grad en forståelse af projektets omgivelser. Et projekt hvor der ikke er nogen læring fra hverken de udførende (leverandøren), de modtagende (kunden) og ingen ændringer i omverden kan med fordel styres linæert/plandrevet/vandfald. Projekter der ikke kan fastholde disse forudsætninger vil nok med fordel kunne anvende de agile tanker i større eller mindre grad.
Yderligere er den agile tankegang funderet i en forståelse fra knowledge management, nemlig at vi som mennesker ikke har direkte adgang til vores viden (Test: Spørg dig selv “Hvad ved jeg?”). Vi har kun adgang til vores viden i en kontekst hvor den kan finde anvendelse. Det betyder at et menneske der prøver at lave en kravspec ud fra en tænkt situation reelt ikke vil kunne bygge et system der har nogen høj sandsynlighed for at være godt og brugbart. Men hvis jeg viser kunden noget undervejs, så er de meget klare på hvad der virker, hvad der ikke virker og hvilke nye ideer der kunne virke endnu bedre. Det betyder en proces der involverer læring vil resultere i et markant bedre resultat. Og dermed bliver den plandrevne vandfaldsmodel både mindre brugbar og dyrere.
Du nævner Nash ligevægt som en optimeringsmodel, men det interessante ved en agil måde at arbejde på er netop erkendelsen af at der ikke er nogen statisk ligevægt. Der er hele tiden læring, hele tiden ny information, hele tiden ændrede betingelser. Man kan sige der måske nok er en ligevægt, men den ændrer sig løbende. Så jeg er også nødt til løbende at vurdere projektet, finde den optimale ligevægt og tilpasse mit projekt efter det.
Hej Michael. Først og fremmest tak for et seriøst indspark til debatten. Det er rart at se at radikale tanker giver anledning til reflektioner hos andre.
Jeg vil forsøge at besvare dine pointer med min personlige holdning og syn på sagen:
Hvis man arbejder i et plandrevet miljø med en vandfaldsbaseret leverancemodel; hvad stopper så teamet fra at arbejde med et agilt værdisæt? Jeg er enig i at det giver udfordring i forhold til at arbejde iterativt og inkrementielt og nyde godt af de fordele det giver. Omvendt kan jeg ikke se hvordan man ikke kan indarbejde en sund og tæt samarbejdsform i teamet og med kunden. At arbejde plandrevet giver også mulighed for at besvare ændringer i scope. Det er måske en tung process, men det er muligt.
I min optik er nøglen i empirisk ledelse eller evidensbaseret ledelse at ændringer skal være faktabaseret. Det harmonerer fint uafhængigt af leverance- og styringsmodel. Hvad stopper et team der arbejder vandfaldsbaseret i at indarbejde elementer fra Scrum? F.eks. kan et Scrum board med tilhørende målinger og et retrospektivmøde med fordel anvendes her. Inspect and adapt er nøgleord fra Lean tankesættet som jeg bestemt også mener hører hjemme andre steder end i iterative og inkrementielle omgivelser.
Den plandrevne vandfaldsmodel har sin berettigelse, som du selv skriver, så er der visse situationer hvor organisationen omkring det udførende team ikke er i stand til at modsvare de behov som et iterativt og inkrementielt forløb kræver. Det kan f.eks. være hvis et team arbejder under stramme kontraktuelle forhold eller arbejder med implementering af lovmæssige tilpasninger i et system.
Grunden til at jeg hiver Nash frem i denne kontekst er at ligemeget hvilken kontekst man arbejder i, så er man nødt til at finde en balance der modsvarer de krav som omgivelserne tilbyder og de elementer som teamet er i stand til at byde ind med. Hvis vi kigger på et agilt team der arbejder med en iterativ og inkrementiel leverancemodel og anvender Scrum som styringsmodel; så vil balancen ofte blive diskuteret initielt og opdateret under forløbet. Det er vigtigt at omgivelserne er indforstået med hvilke krav Scrum stiller f.eks. til en kunde i rollen som Product Owner. Denne balance bliver typisk nedfældet som “definition of done”, “working agreements”, “done” kriterier, m.m.
Hej Rasmus,
Med fare for at støde må jeg nok sige at mit problem med dit oprindelige indlæg ikke er at det er radikalt, men at det er alt for traditionelt. For mig ser det ud som om du stadig er fanget i en gammeldags verden af simple optimeringer når det agile jo virkeligheden peger på noget langt mere radikalt.
Men – jeg kan jo selvfølgelig have misforstået det du egentlig mente, så lad os prøve at se om vi ikke i fællesskab kan gøre det lidt mere præcist 🙂
Min pointe er at du i dit oprindelige indlæg beskriver Værdier, Styringsmodeller og Leverancemodeller som 3 uafhængige størrelser du kan vælge frit. Min påstand er at det ikke giver mening. Har du valgt et punkt på den ene, har du også samtidig implicit påvirket hvad der giver mening at vælge på de to andre. Og dermed bliver Nash ligevægt ikke en brugbar optimeringsmetode.
Til dine konkrete eksempler:
* I et plandrevet vandfaldsmiljø miljø kan teamet ikke arbejde agilt, idet der ifølge planen først skal laves kravspec, så design, osv.
* En empirisk proces er præcis ikke uafhængig af styrings- og leverancemodel. Empirisk betyder jeg observer resultatet og tilpasse retningen, men det kan jeg jo ikke hvis jeg skal køre efter en vandfaldsmodel.
* Den balance du taler om som “Defintion of Done” osv. antager allerede vi arbejde i en agil verden og dermed er det ikke den balance du påstår findes som en balance mellem 3 uafhængige variable.
Jeg synes derimod din påstand om at tage hensyn til om teamet arbejder under strenge kontraktuelle forpligtelser giver god mening. Hvis den del af verden der kan påvirkes allerede antager en linæer/ikke-kompleks verdensforståelse – eller projektet har en karakter hvor transaktionsomkostninger ved at prøve noget og så ændre det er for store (f.eks. brobygning), ja, så er der en del af projektet der må køre efter plandrevne betingelser.
Det radikale, i min optik, er at agilitet skal frigøres fra et rammeværk. Se evt blog og videoindslag der er links til i teksten.
Jeg ser det ikke som værende fastlåst eller gammeldags at anerkende at visse situationer kræver andre styringsværktøjer end de der er klassisk agile (eg Scrum).
At være agil er, i min optik, et spørgsmål om hvorvidt man under de givne omstændigheder bestræber sig på at efterleve prioriteterne som beskrevet i det agile manifest.
I den ideelle verden indfører man ‘full blown agile’ i form af iterativ/inkrementiel leverancemodel, Scrum som styringsmodel og agile/Lean som værdisæt. Kristian Haugaard fra Ugilic har en case story fra Forca hvor dette har været muligt. Kudos for det. Flere virksomheder kunne lære af sådanne historier.
Nej, det er ikke gammeldags at anderkende der kan være brug for mange forskellige styringsværktøjer. Det er vi såmænd ganske enige om. Og nej, det er ikke gammeldags at kigge efter andre muligheder end Scrum (eller Kanban for den sags skyld). Og jeg er helt enig i der er brug for det.