Denne klumme er et debatindlæg og er alene udtryk for skribenternes synspunkter.
’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 denne første del dykker vi ned i agilitetens grundlæggende principper og konceptets (problematiske) digitale indtog, før vi i del 2 giver vores bud på tre af de typiske faldgruber for agile setups, som vi har erfaret, at mange teams kæmper med – om de så er klar over det eller ej.
Agilitetens historie
Vi lægger ud med en lille historietime.
Lige som så meget andet gælder det nemlig også for agile-begrebet, at man må rode i fortiden for at forstå sig på nutiden.
Historien om 'agile' begynder i 2001, hvor Y2K-panikken så småt havde lagt sig, George W. Bush havde sat sig på den bløde læderstol i det ovale kontor, og Erann DD blev kåret til Årets Nye Navn ved Danish Music Awards.
I dette år, på et ski-resort i Utah samledes 17 innovative (og lettere rebelske) hjerner med et fælles mål om at gøre softwareudvikling lettere.
Det skulle ske ved at udarbejde et sæt af værdier og principper, der kunne gøre op med de rigide arbejdsprocesser i datidens edb-industri. Og således blev The Agile Manifesto født.
Nogle af principperne i The Agile Manifesto var egentlig allerede forholdsvist udbredte i koncepter som Scrum og Lean Thinking - sidstnævnte med rødder i amerikanske og japanske ledelsesprincipper helt tilbage fra 2. verdenskrig.
Men dette var første gang, at man samlede og konkretiserede principperne i en software-fokuseret kontekst.
Derfor blev manifestet på mange måder startskuddet for den agile metodologi, og det blev hurtigt anerkendt som den hellige gral for enhver med interesse i hurtigere og bedre softwareudviklingsprocesser – noget som der var meget bred interesse for her i slutningen af dot com-boblen.
Og så var der da også noget overraskende sexet over selve fremførslen og det mentale billede af 17 løsgængere, der slog sig sammen i kampen mod de ortodokse jakkesæt i corporate America.
Digitaliseringens agile indtog
Siden The Agile Manifesto tog software-verdenen med storm i 00’erne, har det ikke ligefrem skortet på agile frameworks som Scrum, Crystal, Kanban og Extreme Programming (XP).
Den agile metodologi er i den grad blevet testet af og har spredt sig som en PM-steppebrand i takt med den ekstreme digitalisering de seneste 20 år.
Digitale processer er allestedsværende i dag, og det har betydet at de agile ledelsesprincipper har spredt sig fra udviklingsteams til topledelse. Agile er gået viralt, og bliver nu brugt på tværs af industrier og sektorer til alt fra marketing og HR til fabriksproduktion og logistik.
Af selvsamme årsag bliver begrebet brugt flittigt i både øst og vest (både bogstaveligt og billedligt talt), hvilket i nogle tilfælde har gjort det fragmenteret, diffust og i værste fald meningsløst.
Ligesom så mange andre digitale koncepter før det, er udviklingen gået hurtigere, end de fleste virksomheder har kunnet følge med.
Derfor er agile endt som en metodologi og et ledelsesprincip, der er nemt nok at råbe højt om til et team-møde, men som i realiteten kan være svært at efterleve.
Mange projektledere hopper lige lukt i forvirringens fælde og indfører agile processer og frameworks på stribe uden egentlig at være klar over, om deres team overhovedet tænker og agerer ud fra agile principper. Derfor er der en ganske afgørende differentiering mellem det at gøre agile ting og det at være agil.
Hvis du lige nu tænker: ”Jamen, vi er da agile, vi bruger jo Scrum!”, så er du måske netop røget i framework-fedtefadet, hvor du fokuserer for meget på at indføre agile-metoder end på faktisk at praktisere en agil arbejdstilgang. Scrum kan sagtens være en del af et velfungerende agilt setup, men det agile landskab er langt større end scrum alene.
Agilitetens faldgruber
De faldgruber, vi præsenterer i det næste indlæg, sker netop på hængebroen mellem det enkelte framework og den kollektive, holistiske tilgang, som fuld agilitet kræver. Mellem det at gøre kontra at være agile.
Det sidstnævnte vil for mange være et urealistisk scenarie, eftersom processerne i langt de fleste organisationer er præget af en stor mængde tradition, rutine, bureaukrati og hierarki.
Alle nødvendigheder for en funktionel arbejdsgang før den globale digitalisering, og for mange nok også stadig nødvendigheder i dag, om end det netop også er her, at problematikkerne med at indføre et agilt mindset opstår.
Så hvis du er en af dem, der oplever, at dit teams agile processer ikke er helt så fleksible, som de burde være, så er det bare med at hoppe videre til del 2, som du kan læse senere på ugen.
Nogle gange er bevidstheden om, at man befinder sig i et hul, lige netop den oplysning, der skal til for at komme ud af selvsamme hul.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
