Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
Vi skriver 2018. Det er 17 år siden, at en række ledere, forfattere og konsulenter indenfor softwareudvikling såsom Martin Fowler, Kent Beck, Ward Cunningham, Jeff Sutherland med flere mødtes i 2001 i Utah i USA og skrev det sidenhen berømte og siden hen meget omdiskuterede “Agile Manifesto.”
Manifestet beskriver, som en del læsere er bekendt med, en række værdier for softwareudvikling - eksempelvis at mennesker og samarbejde er vigtigere i processen med at udvikle software end processer og værktøjer.
Budskabet er, at for eksempel processer og værktøjer tilfører stor værdi i et softwareudviklingsprojekt, men menneskelige relationer og samarbejde efter disse menneskers mening er vigtigere elementer end processer og værktøjer.
Det primære fokus bør derfor være mennesker og relationer frem for processer og værktøjer.
Manifestet anses af mange for “grundloven” indenfor agil softwareudvikling.
Det bør læses i sin helhed, og du kan finde det på dette link - specielt optakten til, hvordan manifestet blev til, er interessant læsning.
For hvordan går det egentlig med det der “agil” softwareudvikling?
Tjo… man kan argumentere for, at “agil” har vundet indpas. Der findes vel ikke et projektstyringsværktøj med respekt for sig selv, der ikke tilbyder en SCRUM-template eller tilsvarende til at understøtte teams, der arbejder efter agile principper og værdier.
Nuvel. En ting er beskrevet ovenfor bekendt processer og værktøjer.
Men hvordan med mennesker og samarbejde?
Mere interessant er spørgsmålet om, hvordan det egentlig går med det der omkring mennesker og samarbejde, som manifestet påpeger trods alt er det vigtigste?
Her er det interessant at læse Martin Fowlers indlæg fra august 2018, hvor han reflekterer over de seneste 17 år, siden han og andre mødtes og udarbejdede det agile manifest.
Han er ikke imponeret, for det står ikke for godt til.
Hovedkonklusionen i hans artikel er, at selv om “agile” er blevet udbredt til at være allestedsnærværende i enhver diskussion om processer og softwareudvikling - også i enterprise virksomhederne, så har de ikke knækket koden endnu forstået sådan, at værktøjer, processer og et fælles sprog som sådan er på plads ude i dagligdagen hos virksomheder, der udvikler software.
Det, der mangler, er de bagvedliggende værdier i agile, som ofte enten ikke har vundet indpas, bliver fejlfortolkede eller måske blot ignoreret.
Rent faktisk, så er vi ifølge Fowler desværre der, hvor enterpriseverdenen tror, at den er agil uden at være det.
Det grundlæggende er ikke på plads
Virksomhederne har etableret koncepter omkring selvstyrende teams, der er Daily Standups, der er en backlog og man planlægger op mod sprints af en fast længde på to-fire uger - men hverken værdierne eller de bagvedliggende principper for “agile” er på plads.
Det er et farligt sted at være for en stor virksomhed.
For set fra ledelsens synspunkt ser alting jo ganske agilt ud, og man markedsfører og brander sig som “agile”, men inde i motoren ligner det i grelle tilfælde forskellige gradbøjninger af den form for softwareudvikling, som det foregår, når Scott Adams tegner sine berømte Dilbert-striber.
Fowlers eksempel på, hvordan udviklere i et tilsyneladende agilt setup er blevet direkte forment adgang til brugerne af den software, de udvikler, er ikke enestående.
Det kan jeg bekræfte, når jeg deler historier fra skyttegravene med kollegaer og konsulenter i Danmark.
Hvad er gået galt?
Intentionerne ude i enterprisevirksomhederne er de bedste, så hvad er det, der er gået galt?
Fowler selv kommer med et par bud: Et af dem handler om “the Agile Industrial Complex”, hvor firmaer siger og udtrykker udadtil, at teams selv må bestemme, uden at de rent faktisk sætter handling bag.
Sat på spidsen: Hvis man ikke forstår, at teams arbejder bedst, når de er selvstyrende, så har man ikke forstået, hvad agil udvikling handler om.
Hvis et agilt team for eksempel ikke selv kan bestemme egne arbejdsprocesser og frekvens i deres leverancer, er det per definition frarøvet sin agilitet.
Konsekvens: Lavere hastighed, frustration og retrospectives, hvor forhindringer ikke til sidst ikke bliver nævnt med et ord, fordi man alligevel er frarøvet muligheden for at gøre noget ved dem - et typisk anti-pattern, hvis underlæggende årsag ofte er, at teamet gerne vil, men af forskellige årsager ikke har mandat til at løse egne problemer på egen hånd
Agil udvikling handler om, at teams involveret i udvikling af et stykke software bestemmer 100 procent, hvad der skal laves og hvordan. Ikke 85 procent eller 97 procent, men 100 procent.
Skal man bruge teknologi A, B eller C? Skal man levere software 10 gange om dagen, efter et sprint eller en gang hvert halve år? Skal man overhovedet arbejde i sprints?
Skal man estimere eller giver det mere mening bare at kode løs på det, vi godt ved, der skal laves?
Hvis vi ikke når vores deadlines, hvad skal vi så gøre fremadrettet for at øge forudsigeligheden? Hvornår er en opgave veldefineret? Hvordan er processen for fejlrettelser, og hvordan registrerer vi fejl og mangler i software, der er leveret?
I et agilt setup, så har man en ScrumMaster eller tilsvarende, der sørger for at stille den slags og mange andre frække spørgsmål til teamet - og så har man en produktejer, der fortæller teamet, hvad visionen er for det, det laver og om forretningens højniveau-prioriteringer per dags dato.
Simpelt - men svært at få til at virke
Det er faktisk præcist lige så simpelt, som det er svært at få til at virke i dagligdagen, i store såvel som små virksomheder, hvor teams godt kan have den fulde kontrol, som agilitet forudsætter, men hvor mennesker eller kompetencer i teamet eller organisationen står i vejen for, at de rigtige beslutninger bliver truffet på de rigtige tidspunkter.
En anden problemstilling, Fowler italesætter, er et manglende fokus og anerkendelse af, hvor vigtigt det er at have dygtige udviklere, der kan udtrykke forretningens behov i kode, der løbende bliver refaktoreret.
Dygtige udviklere er en mangelvare, og der er for lidt fokus på, at det kræver endog meget dygtige teknikere at få et agilt setup til at fungere.
Refaktorering er en kernekompetence hos en dygtig softwareudvikler, men til gengæld et område, der ikke får den nødvendige kærlighed og den plads på en backlog, som den skal have, for at teamet kan reagere hurtigt, når kravene ændrer sig.
Projekt-teams
Et tredje problem er de såkaldte “projekt-teams”, der opstår og nedlægges løbende.
Det hindrer agiliteten at forme projektteams, der knopskyder features ind på et produkt, for manglende domæneviden og forskellige visioner for produktet forringer kvaliteten af den software, der bliver leveret.
Det er langt bedre at forme produkt-teams, der lever længere og som over tid er bedre i stand til at fastholde den samme vision for et produkt uagtet, at folk udskiftes undervejs eller at prioriteringer i forretningen ændrer sig.
Fowler taler om, at man skal fokusere på “business capabilities” fremfor projekter - på den måde bliver opgraderingsprojekter også bare noget, som et produktteam som udgangspunkt tager på sig og skalerer sig op til at kunne håndtere fremfor et udgangspunkt, hvor man sætter et team sammen for at opgradere økonomisystem XYZ.
Fowlers konklusion læser jeg som, at han ikke er optimist - han er heller ikke voldsomt imponeret. Der er lang vej igen, inden agile værdier bliver udlevet i praksis ude i virksomhederne.
Min egen erfaring er da også på tværs af virksomheder, at SCRUM er grundlæggende noget, vi egentlig gerne vil, for vi vil godt have mere og bedre software end det, vi får i dag, men vi tør ikke rigtigt slippe vores teams løs og lade dem træffe deres egne beslutninger for alvor, for vi kan ikke overskue konsekvenserne.
Begrænse og sanktionere
I stedet for at springe ud på det dybe vand vælger mange virksomheder, tro mod den menneskelige natur, at sikre virksomheden ved at begrænse og sanktionere - man vælger at bygge hegn og ansætte grænsevagter i forventningen om, at fejl og mangler i software bliver fanget, inden de rammer kunderne.
Der er i mine øjne flere problemer med den form for risikostyring.
For det første, så virker den ikke specielt godt.
Jeg anerkender fuldstændigt virksomhedernes behov for processer, afrapportering og at banen skal kridtes op for, hvad der er rigtigt og forkert - lad os lige få det på plads som det første.
Jeg anfægter i stedet måderne, jeg ser det udført på i praksis, for det ender som regel med at medføre præcis den adfærd og de slutresultater, reglerne og processerne blev sat i verden for at forhindre.
Regler og processer, der ikke bliver forklaret og kommunikeret i øjenhøjde, gør egentligt bare, at softwareudvikleren arbejder sig udenom, hvor det er muligt.
Vi lever af at løse problemer
Vi lever af at løse problemer og vores tolerancetærskel overfor processer, der ikke giver mening er ganske lille, så hvis vi møder en forhindring på vores vej, så er rygmarvsreaktionen: “Omgå forhindring for at nå i mål”.
Så “låner” man brugernavne og rettigheder fra en serviceaccount til at logge på en server, når nu ens egen profil ikke selv har rettigheder på trods af, at man i flere år har fået adgang i øst og vest til alle mulige andre sensitive data uden nogen former for proces overhovedet.
Man køber måske en softwarelicens til 50 dollar for sine egne penge, når man ikke orker bureaukratiet og processerne for softwareindkøb, der er konstrueret til indkøb af Office-produkter mere end et eller andet stykke software til få hundrede kroner, der løser et presserende problem for hele teamet.
Forstå mig ret: Processer omkring eksempelvis indkøb af software er på sin plads i den rette sammenhæng, der er store besparelser at hente, når softwarelicenser købes i bundter fremfor drypvist, ingen tvivl om det, så der er masser af rationale i at centralisere den slags processer, ligesom man er nødt til at vide sikkerhedsmæssigt, hvad der kører på virksomhedens infrastruktur.
Problemet er, at den færdige proces sjældent har en hurtig-kø - alle bliver tvunget igennem den samme proces, hvor man skal retfærdiggøre et behov i prosa, afholde et møde, vente på svar og udfylde formularer med et hav af påkrævede felter, ingen aner, hvad betyder og som ikke er dokumenteret nogen steder.
Når vi møder en ellers valid proces, hvor den ikke giver mening og ingen kan forklare den for os - så kører vi altså udenom, graver en tunnel eller bygger en luftballon og flyver hen over den. Eksemplerne er talrige og et udtryk for, at præcis den adfærd, som virksomhederne forsøger at undgå blomstrer i dagligdagen, når processer og regler ikke fungerer i det domæne, teamet er født ind i.
For det andet, så har jeg set eksempler i flere forskellige sammenhænge, at årsagen til regler og begrænsninger bunder i en underliggende præmis, hvor softwareudviklere sættes i bås som en flok nogle libertarianske cowboys, der vrænger af regler og processer og anser ethvert forsøg på regulering som et overgreb.
Jeg har personligt selv oplevet for år tilbage, at et ønske pr. standard procedure via et servicedesk-system blev pure afvist og når man så investerer et par timer i at køre over til den afdeling, hvor der sidder nogle beslutningstagere og forklarer dem situationen, så viser det sig, at de havde nogle fordomme om softwareudviklere, der ikke viste sig at holde stik, da en af dem pludselig troppede op og viste sig at være et menneske af kød og blod, der egentlig bare havde behov for en hurtig løsning på et presserende problem.
Det kan så godt være, jeg ikke fik det, jeg oprindeligt bad om, men vi fandt en anden løsning, der også fungerede - det endte som en god oplevelse for alle involverede.
Det er lige præcis det, Fowler og hans trosfæller mente tilbage i 2001 i Utah - mennesker og relationer er vigtigere end processer og værktøjer og det sker hele tiden i det små, men det er båret af ildsjæle og sjældent sat i system - det er som om virksomhederne godt kan se ideen, men ikke tør tage risikoen, så de putter sig stadig og tør ikke give los.
Chancen for, at det bliver bedre de første 10-20 år er i mine øjne egentligt ikke ret stor, for den form for transformation tror jeg vil tage en halv til en hel generation, inden toget begynder at rulle for alvor.
Det kræver, tror jeg, at de unge mennesker, der er i begyndelsen af 20’erne i dag og som er vokset op med internettet, bliver gamle nok til at blive CxO'er i de store mastodonter, der i dag gennemlever det, Martin Fowler i sin artikel fra før beskriver som “faux agile”.
Vi softwareudviklere fixer problemer og forstår, hvordan en organisation skal bygges for at understøtte agil softwareudvikling, men vi er jo netop det der små-introverte folk, der ikke har lederambitioner i stor skala.
Havde vi ambitioner om at arbejde strategisk samt lede og fordele arbejde for andre, så lavede vi firkantet sagt noget mere karrierestige-agtigt fremfor at skrive software, der løser andres behov for nye features.
Sætter min lid til næste generation
Jeg sætter min lid til næste generation af topledere i erhvervslivet.
De vil som gruppe have bedre forudsætninger, da de vil være vokset op med Internettet som et grundvilkår og et ledermiljø, hvor du ikke har succes, hvis du ikke forstår, at agilitet er lig evnen til at kunne reagere hurtigt og tilpasse dit produkt eller din virksomhed hurtigere end dine konkurrenter.
De vil have flere underordnede ledere, der ligeledes forstår agile.
Deres forudsætninger vil være bedre, for jeg forventer, de vil genkende og forstå præmisserne for softwareudvikling i et agilt setup, fordi det er, hvad de vil have set fungere, siden de blev gamle nok til at reflektere over, hvad der virker og ikke virker i forhold til de mål, de vil sætte sig.
De vil forhåbentligt forstå, at centralisering skaber afhængigheder i organisationen, der er en tilbagevendende rod-årsag til, at agilitet ikke fungerer i praksis - og indrette deres organisation derefter samt være i stand til at italesætte og forsvare et tilsyneladende spild i manglende centralisering med den øgede kvalitet og hastighed på de leverancer, udviklingsorganisationen så omvendt skal vise, de kan levere.
Frihed under ansvar fungerer, når du har dygtige folk omkring dig og tør lade dem træffe beslutninger, små som store.
De store virksomheder kan kun håbe på, de mest talentfulde CxO-aspiranter vil interessere sig for overhovedet at blive ansat i en dinosaur af en enterprisevirksomhed, hvor unødigt bureaukrati trives og intet enkelt menneske kan absorbere den mængde data, der skal til for at forstå, hvad der reelt foregår på grund af den skala, tingene foregår i.
Agile lever og har det godt, men overordnet set ikke i virksomheder af en vis størrelse.
De kan håbe på, fremtidige ledere med talent og visioner om agile vil interessere sig nok for enterpriseverdenen til at ville lade sig ansætte ind i den. Uanset hvad vil en transformation, hvor værdierne langsomt udskiftes i en stor virksomhed, tage rigtigt lang tid og der er meget arbejde foran os, der skal gøres, før vi kommer derhen på alle niveauer i alle virksomheder.
Derfor må vi, der bekender sig til agile værdier, hver dag sætte det gode eksempel ved at argumentere vores sag i værdikampen ude på vores arbejdspladser, fejre små og store sejre og minde os selv om, at uanset hvor tossede regler og processer og vandfaldsforelskede projektledere, vi møder i dagligdagen, så er de i 90 procent af tilfældene udtænkt i den bedste mening af mennesker som os selv - og aldrig glemme at tage diskussionen derfra.
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 noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.