Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Vi er på vej væk fra en ”religiøs” tilgang til agile principper.
Forleden så jeg, at it-ledere fra både Bankdata og Energinet bløder op i forhold til de agile metoder. Både med en mere fleksibel tilgang til at bruge principperne og ved at kombinere med klassisk planlægning.
For mig at se afspejler det en tilbagevenden til det balancerede (digitale) lederskab. Digitaliseringsprojekter er og bliver komplekse sager, og vi kan ikke flygte ind i et nok så skinnende metodeapparat.
Det sidste seriøse forsøg var netop de agile metoder.
Mange organisationer undveg it-tilværelsens ulidelige kompleksitet ved at sætte sig på de agile metoders sorte skolebænke. Vi kunne stolt erklære os 100 procent agile, og vi havde en masse givne svar i takt med at scrum, sprint og SAFe sneg sig ind i vores ordforråd ved siden af sødmælk og forandringsparathed.
Nu er vi lidt klogere, for selv de mest dogmatiske og rettroende agile udviklingsorganisationer er ikke vågnet op i baronens seng midt i den syvende himmel. De agile metoder har vist deres styrke og deres svaghed. Nu vælger vi til og fra afhængig af opgaven, styringsmodellen med mere.
Stor berettigelse
Jeg vil gerne slå fast med syvtommersøm, at den agile tankegang har fat i noget helt rigtigt (ja, vi har selv agile coaches og konsulenter, som hjælper organisationer med at få værdi ud af eksempelvis SAFe eller for den sags skyld tilpasse et metoderammeværk og nogle gange afliver tilsvarende).
Den agile filosofi rammer meget præcist ind i samspillet mellem behov og it-produkt, mellem forretning og udviklingsorganisation og mellem kultur og processer.
Det er især relevant i projekter med høj kompleksitet og mange bevægelige dele, hvor løbende tilpasning og fleksibilitet er helt uomgængelig.
Den klassiske udviklerprofil er givetvis ved at få røde knopper af sprints og PI-planning. Fra den gamle position lyder irritationen cirka sådan: ”Hvad laver sådan en marketingchef, kan hun ikke bare sige, hvad pokker hun vil have, så skal jeg nok kode det?”
Rigtigt nok, hvis endemålet er et stykke kode.
Men hvis slutproduktet er den optimale forretningsmæssige virkelighed (der som bekendt omfatter mennesker, kompetencer, konkurrenter, produkter, medier og kanaler), så er den grumme sandhed jo, at i takt med at vi ser funktionaliteten vokse, får vi nye ideer til, hvad vi også har brug for.
Vi bliver altså mere afklarede hen ad vejen – ikke mindst fordi mange personer er involveret i slutproduktet. Derfor har vi brug for den agile tilgangs løbende samtale og tilpasning. Ellers får vi problemer.
Hvem sidder tilbage med Sorte-Per?
Både internt i organisationer mellem forretning og it og i spillet mellem kunde og leverandør kan Sorte-Per være på spil.
Hvis partnerskaber ikke handler om at nå det samlet set optimale resultat men om at distribuere risiko, ja, så kan nogen ende med at sidde med Sorte-Per.
Fastpris, javel, men er du som opdragsgiver så fast i kødet, at man som udvikler tør binde an med opgaven? Vi har lige indgået en kundeaftale, hvor vi både arbejder på fastpris og det modsatte. På samme måde arbejder vi agilt, når opgaven kræver det, mens vi bruger traditionel projektstyring på andre områder.
Den helt simple analogi er den hybride arbejdsplads. Vi mødes nogle gange på Teams, andre gange i kontorlokalerne og atter andre gange på en gåtur rundt om søen.
På samme måde skal valget af styringsmodel og metode afspejle opgavens karakter. Vi skal vælge den agile tilgang på komplekse udviklingsopgaver med behov for fleksibilitet, og jo mere vi nærmer os drift og ”udrulning” skal vi skrue ned for sprinteriet. Her ligger opgøret med de agile fundamentalisters sorte skole, og fantasien om det 1.000 procent agile himmerige.
Den går desværre ikke, Granberg. Lederskab er den røde tråd, og vi kan ikke låse os til en metode for at undgå de ubehagelige spørgsmål. Metode og styringsmodel skal afspejle, hvor opgaven befinder sig i spændingerne mellem internt og eksternt, statisk og dynamisk, formelt og uformelt, need-to-have og nice-to-have. Og så videre.
Den slemme dreng i projektklassen
En af verdens mest citerede forskere inden for projektledelse er danske Bent Flyvbjerg som sammen med forskerkolleger har indsamlet data om 5000 it-projekter, og sammenlignet dem med andre typer af komplicerede projekter (eksempelvis dæmninger, OL, jernbaner, solenergianlæg, vindmølleparker).
It-projekter bonger ud som de i særklasse mest risikable med langt de største budgetoverskridelser. En femtedel af projekterne bliver fem gange dyrere end planlagt. Ret så vildt. Derfor er den fortsatte metodeudvikling nødvendig og ønskelig.
Når det så er sagt, så har digitale udviklingsprojekter i min optik mange flere bevægelige dele end et stykke fysisk infrastruktur.
Mennesker har kun bygget it-systemer i en håndfuld årtier, men vi har bygget broer i en snes århundreder. Og fordi de digitale byggesten ændrer sig hele tiden, vil digitaliseringsprojekter nok forblive den slemme dreng i projektklassen.
Fremover skal vi hylde metodefriheden, og vi skal lade den givne opgave styre valget af metode. Vi åbner døren på klem for at miste den optimale sammenhæng mellem problem og metode, hvis vi bliver for radikaliserede og dømmer det ene 100 procent ude og det andet 100 procent inde.
Hvis du kun har en hammer i værktøjskassen, ligner alle opgaver som bekendt et søm.
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.
