Denne klumme er et debatindlæg og er alene udtryk for skribenternes synspunkter.
Agil softwareudvikling har vundet indpas i en lang række it-virksomheder - det er undtagelsen, hvis man finder en stillingsannonce som softwareudvikler eller projektleder med ansvar for digitale leverancer, der på en eller anden måde ikke får sneget ordet “agil” ind et sted.
Evnen til at opbygge sin organisation, så den kan tilpasse sig et marked og skiftende behov er en eftertragtet kompetence, hvis man er leder - og her passer agil udvikling fint ind, for her er arbejdsmetoder og processer designet til, at man ikke designer en færdig løsning, men laver løbende forbedringer i god kvalitet og indhenter erfaringer fra brugerne, inden man påbegynder en ny iteration.
Problemet er, at det, der virker godt i nogle sammenhænge, ikke nødvendigvis virker godt, hvis skala ændrer sig.
De processer og aftaler, der fungerer godt for tre teams, der har indbyrdes afhængigheder og laver leverancer til hinanden, fungerer ikke nødvendigvis for 30 teams, der har indbyrdes afhængigheder og laver leverancer til hinanden.
En af faldgruberne ved at skalere agilt har været og er, at man tager det, der virker i det små og forsøger at replikere det op i stor skala på tværs af afdelinger og måske hele organisationer uden nødvendigvis at tage højde for den øgede kompleksitet og den mængde forandringsledelse, der skal til, når hundrede eller tusindvis af vidensarbejdere skal arbejde efter principperne i et agilt manifest, hvor udgangspunktet for manifestet var mindre, uafhængige enheder, der har autonomi og kompetencer bygget ind fra start.
Man har i industrien forsøgt at råde bod på dette ved at opfinde nye processer og værktøjer til at skalere agil softwareudvikling, så en leveranceorganisation på titusinder af ansatte kan arbejde agilt.
Det framework, der p.t. har flest markedsandele, er SAFe, men der er andre, fuldgode alternativer, hvor værdisættet bag differentierer sig - LeSS er værd at nævne her, da den mig bekendt er den eneste, der italesætter det egentlige problem helt fra start: At kontekst betyder alt, når du skal finde den rigtige løsning på et givent problem.
20 år gammelt manifest
Det agile manifest blev skrevet for små 20 år siden som en reaktion på rigide vandfaldsprocesser, hvor risikovilligheden er lig nul, fordi man rent ledelsesmæssigt ikke havde forståelsen af, at hvis du styrer risici på en god måde, så er prisen for at ændre kurs sent i processen ikke per definition en dyr omgang.
Hvis du arbejder i den fysiske verden, så kan det blive ekstremt dyrt at regne forkert.
Når du for eksempel har støbt fundamentet på et hus, så vil det være meget dyrt at foretage en ændring, så huset bliver tre meter længere, fordi du først på bagkant opdagede, at det ville være en stor fordel for det endelige resultat at have et hus på 21 meter og ikke kun 18 meter i længden.
Sådan er det i den virkelige verden, hvor mennesket ikke er herre over de fysiske love, men i software er det anderledes.
Derfor, så kan man som leder tillade sig at styre risici på en helt anden måde og opbygge et leveranceapparat, der fungerer grundlæggende forskelligt fra traditionelle projektmodeller - men kun, hvis man forstår forskellene og evner at forme sin organisation derefter.
Det er godt, at den øverste ledelse har forstået, at den er nødt til at forholde sig til digitalisering og hvordan software bliver til i dens organisation.
Erkendelse er en ting desværre, viden om årsager og virkninger er en anden historie.
Hvis man ønsker at få mere for pengene, så bliver det ikke løst af, at man indfører en ny proces som SAFe eller LeSS - men det er nemt at fortabe sig organistorisk i at dygtiggøre sig i en ny udviklingsproces, der bliver markedsført som om, at processen i sig selv er årsagen til de problemer, du tidligere har oplevet, hvis du ikke har etableret metrikker og målinger på, der er kundevendte og fokuserer på en slutbrugeroplevelse, ligesom du også er pinedød nødt til som topledelse at have en holdning til, hvordan kvalitet skal måles i det software, I leverer.
Hvordan arbejde de sammen?
Derfor er det ikke ligemeget, hvordan du indleder dit initiativ til at skalere agiliteten af din organisation.
Du bør som leder interessere dig mere for, hvordan dine teams arbejder sammen, end hvordan de arbejder internt - det er nok min største anke mod de tiltag, der pågår inden for skaleret agil softwareudvikling, hvor man træner teams i agile processer, men ikke i ledelsen italesætter og løser tekniske såvel som organisatoriske afhængigheder, som forhindrer dem i at performe.
Hvis et enkelt team er flaskehals for, at 10 andre teams er i stand til at levere hurtigere på deres backlog, så er det din vigtigste opgave som leder at fjerne denne flaskehals, så organisationen ikke opbygger en lang kø af opgaver, der venter på at blive udført.
Det er langt vigtigere, at kvalitetsmæssige udeståender såsom antal fejl i produktion eller fejlende, automatiserede tests bliver født direkte tilbage til udviklingsteamet hurtigst muligt, end at alle teams har fået træning i Scrum.
Ikke en forudsætning med godkendelse flere dage før
Det er heller ikke en forudsætning for kvalitet i en stor leveranceorganisation, at man indfører processer, så en release fra et team skal godkendes flere dage i forvejen af folk, der på ingen måde er involveret i udviklingen af det, de sidder og godkender og ikke bliver sanktioneret efterfølgende, hvis releasen går galt.
Det er derimod essentielt at kunne integrere leverancer fra forskellige teams tidligt og ofte for at kunne validere løbende, hvorvidt flere leverancer for forskellige teams er i stand til at fungere som en helhed. Her er det dit job som leder at forstå, hvorfor testautomatisering i stor skala er en forudsætning for den hastighed, du ønsker dig i jeres udviklingsprocesser.
Der er en lav, øvre grænse for både kvalitet og flow af opgaver, hvis man forlader sig på manuelle tests til at give udviklerne feedback på, hvorvidt en leverance kvalitetsmæssigt lever op til det, der bliver forventet af dem.
Hvad siger antallet af forbrugte timer eller storypoints om kvaliteten af slutproduktet? Intet - absolut intet.
Estimater er interessante for de enkelte teams, da det er input til deres løbende forbedringsprocesser, men antallet af timer forbrugt på en leverance korrelerer ikke med brugernes oplevelse af kvalitet i slutproduktet.
Deskaler kompleksiteten
For at få succes med skaleret softwareudvikling, så handler det ikke om at forøge kompleksiteten, tværtimod.
Kriterierne for succes er i stedet at deskalere kompleksitet og bygge sin organisation op omkring en teknisk platform, der sikrer, at teams kan kvalitetssikre egne leverancer tidligt og ofte.
Kravet er, at man adopterer en anden form for risikostyring end traditionel vandfalds projektledelse, sikrer fuld transparens i porteføljestyringen af initiativer og roadmaps, tillader fleksibilitet i, hvordan en leverance bliver til og at man som organisation opstiller fælles mål for hele organisationen for slutbrugerkvalitet.
Herfra, så kan du være ligeglad med, hvad jeres proces hedder. Kontekst er altafgørende, og der findes ikke en one-size-fits-all alligevel, men det er nemt at blive forelsket i procesværktøjer, der på overfladen lover at løse en række problemer, men ikke gør det, fordi rodårsagerne til problemer med lav hastighed, uigennemsigtighed i fremdriften af opgaver og lav kvalitet i slutproduktet ligger indlejret i din organisation i form af kultur, organisatorisk kompleksitet og teknisk gæld, der forhindrer dygtige vidensarbejdere i at gøre det, de godt ved er det rigtige i situationen.
Som leder skal du sætte retningen og forventningerne til, hvad, hvornår og i hvilken kvalitet, software skal leveres.
Hvordan et team udvikler software, det behøver du som leder ikke være voldsomt interesseret i, så længe det leverer til tiden, nogenlunde indenfor budget og i forhold til de forventninger til kvalitet, du har stillet op på organisationens vegne.
Hvis et team eksekverer et sprint udelukkende ved hjælp af post-it noter på væggen og er glad for det - jamen, så lad det gøre det, så længe porteføljestyringen af kommende opgaver og initiativer sker i et værktøj, der er fælles for hele jeres organisation.
Hvis det anvender Daily Scrum - fint. Hvis det lader være eller kun gør det hver tredje dag - det er sikkert også fint, sålænge andre teams ikke føler, at de mangler information eller adgang til teamet.
Hvis et team gerne vil køre iterationer af fire ugers varighed, hvor resten af organisationen kører i sprints af to uger, så er det interessant at lære baggrunden herfor, men det bør ikke være diskvalificerende at lade et team køre i iterationer af fire ugers varighed, hvis det giver mening i kontekst og ikke medfører fordyrende friktion eller ventetid andre steder i værdikæden.
Kald det agil udvikling, vandfald, DevOps, SAFe, LeSS eller noget helt femte, det er ikke vigtigt.
De organisationer, der vinder konkurrencen om fremtidens talent og vil kunne vokse uden at miste evnen til at tilpasse sig løbende forandringer vil være dem, der formår at opstille klare mål og forventninger til, hvad der bliver forventet af deres medarbejdere.
Derfra, så vil de kommende vindere turde lade dygtige medarbejdere om at finde den rigtige vej igennem ved at bringe deres høje uddannelse og erfaringer i spil - til glæde og gavn for både deres arbejdsgiver og ikke mindst de slutbrugere og kunder, der til syvende og sidst er de vigtigste interessenter i enhver virksomhed.
Her er relevant materiale i form af links og bøger på Amazon, der kan give inspiration til, hvordan man deskalerer kompleksitet og gennemfører forandringer uden at fortabe sig i proces undervejs.
Links:
Large Scale Scrum (LeSS) framework
Bøger:
Implementing Lean Software Development (Mary and Tom Poppendieck)
Leading Change (John P. Kotter)
The Goal - Theory of Constraints (Eliyaho M. Goldratt and Jeff Cox)
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.