Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Måske er det tid til at gøre lidt status over det succesombruste vidunderbarn, som den agile bevægelse har været i it-Danmark?
Dansk IT og Rambølls årlige undersøgelse blandt de største virksomheder og offentlige myndigheder peger på den organisatoriske barriere mellem It-funktionen og den øvrige organisation.
IT i Praksis fra 2022 bringer svar fra CIO’er og CEO’er. 40 procent i den private sektor mener, at deres organisationsstruktur afspejler agile principper. 34 procent benytter de agile roller, og 28 procent svarer, at prioriteringsmekanismen omkring arbejdsopgaver reflekterer agile principper.
I den offentlige sektor svarer ledelseslaget, at 30 procent af udviklingsprojekterne gennemføres efter agile principper. Her er det 23 procent, som bruger de agile roller, 20 procent prioriterer opgaver med agile principper og 18 procent indretter organisationen agilt.
Alt sammen ifølge den traditionsrige og solide survey, som bygger på over hundrede CEO- og CIO-besvarelser i hver sektor.
Ikke vildt imponerende
Tankegodset i den agile bevægelse er meget fint, og i it-funktionerne har det bredt sig som en steppebrand. På den baggrund er udbredelsen faktisk ikke vildt imponerende.
Som en rimelig trofast tilhænger af den agile filosofi tror jeg, at vi især støder på grænsen, når vi bevæger os længere væk fra it og udviklingsfunktionen.
Problemerne opstår i grænselandet mellem forretning og it. Her har vi i it-faget vores pendant til Bermuda-trekanten, hvor mange it-projekter er gået ned med mus og mænd.
Pointen er, at hvis struktur og organisation generelt ikke følger med, så bliver agiliteten en arbejdsmetode til software-udvikling og ikke en værdiskabende metode til transformation.
Realtidsforbindelse til problemet
Paradokset med SAFe og andre hyper-præskriptive rammeværk, er, at de tit bliver meget rigide i deres agilitet.
Nu hvor Agile er blevet voksen, er det vigtigt at den ikke bliver for konservativ og glemmer sin rebelske ungdom.
Agilitet skal baseres på principper, der fostrer et agilt mindset, i stedet for regler, der fostrer detaljerede projektplaner.
Hvis man zoomer lidt ud fra den sande lære i for eksmempel SAFe eller scrum synes jeg, at principperne minder meget om noget man kunne kalde god ledelse.
Metoden i en nøddeskal er at holde en realtidsforbindelse mellem problemet og den ankommende løsning. Altså det modsatte af vandfald og rigide kravsspecifikationer.
Det fører så til, at det måske ikke er så afgørende, at vi bruger alle de rigtige termer og holder os formelt til de roller, metoder og tidsplaner, som eksempelvis SAFe foreskriver?
Badebro eller Storebæltsbro?
Det handler om skalering. Metoden må følge problemet, mener en god kollega.
Han er passioneret agilist og har alle rygmærker som coach og transformationskonsulent med en værktøjskasse fuld af Scrum, SAFe, Kanban, Less og Nexus.
Han har også 20 års erfaring fra projekter i USA for Disney, Miramax og Wells Fargo Bank med flere.
Synspunktet er, at der er forskel på en badebro og en Storebæltsbro, og derfor kan du nok ikke bruge den samme metode og proces.
På samme måde er der enorm forskel på at være en megaorganisation, der selv udruller softwareprodukter, og en lille virksomhed, der skal lave en tilpasning i ny og næ.
Agil er ikke svaret på alt. Ligesom alt andet procesledelse, så tror jeg, at hvis du kender forretningen/produktet/domænet, bliver du en bedre procesleder. Hvis man ved, hvad det handler om, så fungerer alt bedre.
Drop landkortet
Hvor et kompleks som SAFe fungerer helt perfekt for en stor softwareproducerende organisation, så er det måske overkill for andre.
Der er langt fra Disney-koncernen eller Ørsted til den typiske danske SMV-virksomhed.
Vi må altså ikke være så firkantede og rene i troen på metoden, at vi kun kan samarbejde med forretningen, hvis det hedder det rigtige og kører 100 procent efter bogen.
Vi skal kunne være agile, så snart vi har realtidsforbindelsen med den gode ledelse og dermed ”problemet”.
Sat på spidsen: Hvis din organisation er ved at kaste op over at bruge seks timer på backlog-grooming, så skal I måske lade være.
Når vi møder en modstand fra forretningen, må vi forlade den rene lære og undersøge om modstanden måske giver god mening.
Alternativet er jo at stå endnu hårdere på metodisk præcision og risikere at smide barnet ud med badevandet.
Belært af min hjemvendte agilistiske kollega med den amerikanske bagage tror jeg, at vi skal være fleksible nok til at droppe landkortet, hvis det ikke passer med det landskab, vi står midt i.
Den agile tænkning ER helt rigtig, men den skal altid bruges med hyperfølsomhed for den kulturelle og forretningsmæssige kontekst.
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.