Skip to content

3 faldgruber, der tærer på dit agile setup

’Agile’ er et af de buzzwords, som mange projektledere er hurtige til at slynge ud, når de skal forklare, hvordan deres udviklingsteam opererer. Vores erfaring er imidlertid, at mange er langt bedre til at sige, at de arbejder agilt, end de er til faktisk at gøre det. For at hjælpe med at gøre ord til handling har vi derfor forfattet en todelt artikel, der forhåbentlig kan hjælpe dig med at lede dit team mod reel agil praksis. I første del dykkede vi ned i agilitetens historie og konceptets grundlæggende principper og problematikker. I dette andet indlæg bliver vi lidt mere konkrete og giver dig vores bud på 3 af de typiske faldgruber for agile setups, som vi har erfaret, at mange teams kæmper med – hvad end de er klar over det eller ej. 

 

Som vi forklarede i den første del af denne yin-yang-artikel, er det at være 100% Agile et ideal, som de færreste teams (måske ingen) reelt kan opnå. Det er der ganske enkelt for meget bureaukrati og for mange budgetter til i den virkelige verdens organisationer. Derfor opstår faldgruberne der, hvor agilitet møder rigiditet og skaber kløfter mellem teori og praksis.

Så lad os tage en dyb indånding, og lad os hoppe ned i kløfterne for at se, hvad der gemmer sig. Måske det kan lære os, hvordan vi bygger stabile broer hen over kløfterne i fremtiden. 

handcuffs

Faldgrube 1: Det agile fængsel

Det agile fængsel er en situation, der opstår, når du følger et frameworks ritualer og arbejdsmetoder så stringent, at du glemmer, hvorfor du faktisk følger dem. Det resulterer i, at arbejdsmetoderne bliver formålsløse og kommer til at føles fængslende for team-medlemmerne. Man tvinger rigide processer ned over teamet i forsøget på at være Agile.

Forestil dig en Scrum Master for et team, der følger Scrum-frameworket til punkt og prikke. En der følger håndbogen og hver eneste nedslag i den helt fra produkt-backlog til launch (fold faldskærmen ud, jeg ser en faldgrube!). Det er en situation, der uundgåeligt vil skabe et agilt fængsel over tid, fordi Scrum Masteren vil fokusere mere på at følge ”reglerne” for agilitet i stedet for faktisk at være agil og gentænke de dele af processerne, der ikke fungerer i praksis for det pågældende team. Lad os tage et eksempel fra sprint-planlægningen. Baseret på virkelige hændelser.

"Man tvinger rigide processer ned over teamet i forsøget på at være Agile"


Planning Poker gone wrong

Som Scrum foreskriver det, er en del af sprint-planlægningen at spille Planning Poker, som er en proces der bruges til at estimere tiden, der skal bruges på at udvikle de enkelte opgaver i backloggen. Det sidste led i den proces er, at udviklerne hver især skal lægge et kort med det timeantal, de estimerer opgaven til. Det er en iterativ proces, der fortsætter, indtil alles tal er forholdsvist tæt på hinanden, hvorefter opgaven estimeres og prioriteres.

Men hvad så, hvis tallene aldrig kommer tæt nok på hinanden til, at man kan blive enige om et estimat? Det sker faktisk ofte, da udviklerne jo kommer med forskellige baggrunde og vekslende erfaringsniveau på de enkelte opgaver. Typisk vil de erfarne udviklere foreslå et markant lavere timeantal end de uefne, og selv efter argumentation og utallige iterationer kan der stadig være stor forskel. Så kan det hurtigt tage mere end en time at estimere én enkelt opgave, og det er noget, der dræner teamet for energi til et punkt, hvor sprint-planlægningen bliver mere frygtet end en tømmermandsramt mandag.

Hvis man ender der, bliver sprint-planlægningen således et eksempel på et ritual, som teamet kun følger, fordi frameworket dikterer det. Et agilt fængsel, hvor proces trumfer fremgang og man ender i en situation, der er alt andet end agil (selvom man måske fortæller sig selv noget andet).


Hvad gør vi så ved det?

Vejen ud af det agile fængsel handler slet og ret om at lytte til sin sunde fornuft. Hvis der er et helt team, der tydeligvis foragter en bestemt del af en agil proces, så bør man nok lede efter alternativer.

Man skal huske sig selv på at være agil. Og som der står i The Agile Manifesto, som vi gennemgik i denne artikels prequel, så handler det om at prioritere individerne over processerne, og omstillingsparathed over det at følge en plan.

Det betyder ikke, at I skal droppe frameworkets guidelines lige så snart, I oplever problemer – men der skal være plads til at lade fornuften sejre og komme med pragmatiske løsninger, hvis processen begynder at føles som et fængsel.

waterfall2

Faldgrube 2: Water-gile

Agile bliver ofte beskrevet som det modsatte af Waterfall-modellen, hvor hver fase i en proces er afhængig af leverancer fra den foregående fase, hvorfor det er en temmelig rigid model, hvor mange krav er defineret up-front - og fleksibiliteten til at gentænke de krav undervejs i processen er begrænset. I en agil tankegang kan Waterfall derfor lyde ret negativt, men i realiteten er det en metodologi som er dybt indlejret i langt de fleste større organisationer, hvor der over årene har været behov for hierarki og et stort fokus på ikke at afvige fra planen.

Før digitalisering blev hverdag for virksomhederne, var Waterfall således en ganske effektiv tilgang, men med det tempo teknologien udvikler sig i nu, er det agile fokus på omstillingsparathed vigtigere end nogensinde. Men eftersom Waterfall har bidt sig fast hos virksomhederne over tid, har vi ofte set, at mange ender med at påstå, at de arbejder agilt, men i virkeligheden minder processerne mere om Waterfall. I så fald er man det, som vi kalder Water-gile.


"Mange krav er defineret up-front - og fleksibiliteten til at gentænke de krav undervejs i processen er begrænset"

Indikationer på Water-gile

En indikation af Water-gile kan f.eks. være projekter, hvor deadlines, scope og kvalitetskriterier er fast defineret på forhånd, og derfor er man i realiteten ikke åben for at foretage ændringer undervejs. Man ender altså med at begrænse sin agilitet til en urokkelig trekant af rigide rammer.

En anden indikation er såkaldte Roadmap Warriors. Selvom det lyder ganske awesome, er det alt andet end agilt. Roadmap Warriors er de projektledere og Product Owners, der følger organisationens interne roadmaps, som var de sat i sten. De opfatter eventuelle ændringer og forsinkelser som et pinligt nederlag for dem selv og teamet, hvilket skaber en arbejdsproces, der er langt mere Waterfall end Agile. Roadmap Warriors dukker oftest op i større virksomheder, da det typisk er disse, der har behov for at udvikle større roadmaps for enkelte projekter og afdelinger.

En sidste indikator på Water-gile kan være, at man prioriterer hurtig levering af produktet over indsigt og kvalitet. Det kommer til at handle for meget om at levere produkterne hurtigt – også selvom man egentlig er blevet klogere undervejs og kunne forbedre slutproduktet med mere tid. Det er desuden noget, som de færreste udviklere kan lide, da det typisk fratager dem indflydelse, hvilket går imod den faglige stolthed og kan føre til demotivation.

 

Hvad gør vi så ved det?

For at undgå Water-gile, er det essentielt at kommunikere tidligt i processen, hvad en agil tilgang egentlig indebærer. Kun sådan kan man gøre det klart for både Product Owner, team og kunde, at agile processer nogle gange indebærer, at man må afvige fra planen, hvis man får indsigter undervejs, der kan bruges til at lægge en bedre plan.

Derfor bør man aktivt insistere på at teste produktet tidligt i udviklingen, ligesom man skal inddrage feedback og brugerindsigter løbende, så man kan foretage de nødvendige kursskifter, inden skibet er i havn.

Derudover skal du huske at udfordre og sætte spørgsmålstegn ved planer og roadmaps, der forekommer fasttømrede og ufravigelige. Kun sådan vinder du kampen mod eventuelle Roadmap Warriors.

 

Faldgrube 3: One size fits all

Den sidste faldgrube, ’One size fits all’, handler om, at man nogle gange i sprint-baseret arbejde kan komme til at kæmpe med manglende formål og ikke-definerede krav, fordi de agile setups organiseres på en måde, hvor feature-leverance er det primære fokus, og hvor løbende tests og feedback nedprioriteres. Til trods for at kontinuerlige tests og forbedringer netop er blandt hovedpointerne ved de agile metoder.

En del af forklaringen på det er, at mange agile frameworks overvejende er fokuseret på konsekvent levering – og måske ikke i lige så høj grad på at finde ud af, hvad der egentlig skal bygges og hvorfor.

Discover & Deliver

I Knowit Experience arbejder vi ofte i en vekslen mellem Discovery-tracks, hvor man bruger indsigter til at lave prototyper og kontinuerligt teste produktidéen, og Delivery-tracks, hvor man fokuserer på løbende og konsekvent levering. Mange agile frameworks kan have tendens til at hælde mod Deliver-tracket, da det ofte er forretningens primære fokus. I værste fald kan det betyde, at designere og UX’ere ender med at udforme idéer og koncepter, der ikke er blevet testet og valideret, fordi Discover-tracket ikke er afbalanceret med Deliver-tracket.

"Man risikerer at blive blind for målet, hvis man ikke får snuden ud af håndbøgerne på de rigtige tidspunkter"

Tricket er således at finde den rette balancegang mellem Discover og Deliver, da man ellers risikerer at få tunnelsyn og arbejde for længe i en forkert retning. Når agile teams bliver overfokuserede på leveringer og forbedringer, kan de miste overblikket over, hvorfor de egentlig gør, som de gør. Kundeoplevelsen nedprioriteres, og det betyder ofte, at man ender med at skulle lave ændringer efter lancering, hvilket er langt dyrere, end hvis man havde fanget problematikkerne i opløbet gennem prototyper og løbende tests.

Slutmålet med digitale projekter er som regel at skabe så meget værdi som muligt for kunden og for brugerne. Det formål risikerer man at blive blind for, hvis man ikke får snuden ud af håndbøgerne og framework-reglerne på de rigtige tidspunkter.


Hvad gør vi så ved det?

’One size fits all’-faldgruben undgås ved at inkorporere en tilgang på projektet, hvor både Discover- og Deliver-delen prioriteres tilstrækkeligt, så man får idégenereret, testet og draget nytte af indsigter sideløbende med iterationerne og de kontinuerlige leveringer i udviklingen.

Det handler altså om hele tiden at overveje sine muligheder og få dem testet af både inden, under og efter selve udviklingen. På den måde får man udnyttet de forskellige faggruppers spidskompetencer og skabt den synergi mellem grupperne, der gør det muligt at lære af hinanden og faktisk arbejde agilt.

I praksis kan det som nævnt være svært at undgå at blive overfokuseret på leveringen, og derfor er det vigtigt, at man i sprint-processen sørger for at indlejre specifikke Discover-aktiviteter. Det kan for eksempel være løbende design sprints, tests, ideation workshops, prototyping, co-creation, teknisk proof-of-concept, dataanalyse etc.

Man skal således huske sig selv og sit team på, at det ikke kun handler om, hvordan man løser projektet, men også om hvorfor man gør det. Den distinktion beskriver IBM meget godt i det følgende:deliver-discover2

Gør de rigtige ting, og gør tingene rigtigt

Som vi forklarede i første del af denne artikel, kan det være nyttigt at kigge på fortiden, når vi skal prøve at forstå os på nutiden. Derfor er det på sin vis også ganske interessant, at de principper, der er fremhævet i The Agile Manifesto tilbage i 2001, i høj grad skinner igennem i de løsningsforslag, vi har præsenteret for hver faldgrube. Det er en af de der fulde cirkler, folk er så vilde med.

Det agile fængsel skulle undgås ved at prioritere individer og interaktioner over processerne. Det samme gælder for Water-gile, som samtidigt også handler om at være agil nok til at kunne reagere proaktivt på de omkringliggende konturer og ikke blive overfokuseret på planer og roadmaps. Og løsningen på ’One size fits all’ inkorporerer begge pointer, ligesom den i høj grad også handler om at lytte til kunden og brugerne, hvilket også står som en af kernerne i The Agile Manifesto.

"Der er en fejlfortolket distinktion mellem det at indføre agile tiltag og det rent faktisk at være og agere agilt"

Så hvad er der gået galt? Hvis pointerne har stået sort på hvidt siden 2001, hvorfor kæmper virksomheder så stadig med agile faldgruber? Tja, for os at se handler det i høj grad om de organisatoriske traditioners dybde og om den fejlfortolkede distinktion mellem det at indføre agile tiltag og det rent faktisk at være og agere agilt på tværs af team og organisation.

Et fuldkomment agilt landskab og mindset er simpelthen for komplekst og for forskelligt fra de traditionelle arbejdsmetoder til, at det kan indføres succesfuldt via frameworks som Scrum og Kanban. Derfor er den komplette agile organisation til stadighed en idealforestilling, og faldgruberne opstår således oftest der, hvor virksomhederne bilder sig selv ind, at de arbejder agilt, selvom de i realiteten står lige under et vandfald.

Når målet er et ideal, bliver selvindsigten dit vigtigste våben. Når først du er klar over, at 100% agilitet er umuligt i din organisation, bliver det meget nemmere at spotte og udligne hullerne i osten. Det er netop det, faldgruberne kan bruges til.

Bevæbnet med indsigter om din egen organisation og egne processer, kan du og dit team holde øjnene på bolden og finde en god balance mellem det at gøre de rigtige ting (Discover), og at gøre tingene rigtigt (Deliver).

 model1

model2

På den måde kan du lykkes med at inkorporere en Agile tilgang i dit team, som rent faktisk er agil – i hvert fald i det omfang det nu kan lade sig gøre i organisationens rigide rammer. Det vigtigste er, at du ikke lader planer, frameworks og roadmaps distrahere dig fra det egentlige fokus i den agile metodologi, som i høj grad handler om at være åben for ændringer og holdninger, der kan øge kvaliteten og værdien af det endelige produkt.

Hvis du kan huske på det slutmål gennem hele processen og kan acceptere, at det kan betyde ændringer i planerne undervejs, så er du godt på vej mod en reel, agil arbejdsproces. Og det er både din vej til glade, dedikerede teams og til produkter, der skaber størst mulig værdi for modtageren. Sæt i gang!

 

P.S. Hvis du ikke har set vores mange links undervejs og fået klikket ind på den første del af dette Agile-artikel-medley, kan du gøre det lige her.