DPL Community

Lad være med bare at “Gå agil!”

Verden forandrer sig hurtigere end nogensinde, og den næste disruption venter lige om hjørnet. Mange virksomheder er derfor godt i gang med en agil transformation for at blive bedre til at tilpasse sig, men mange oplever at transformationen ikke giver den forretningsværdi, man havde forestillet sig på forhånd, og nye udfordringer dukker op, man ikke havde før.

Udfordringerne kan være forskellige

  • Nogle virksomheder prøver lidt forsigtigt det agile uden at alle er helt klare over hvad det egentlig betyder. Opfatter ledergruppen f.eks. den agile transformation som en procesforbedring i IT-afdelingen, PMO’et eller udviklingsafdelingen kan der hurtigt komme konflikter når man finder ud af at også chefen skal ændre sin måde at tænke og drive virksomheden på for at nå den forventede værdi
  • Andre kaster sig ind i den agile transformation med hele firmaets sjæl. Alle funktioner bliver omdøbt til agile termer, roller ændres over natten og ingen ved længere hvem der gør hvad. Det kan nemt ende med at det at ”blive agil” bliver målet i sig selv mens organisationen har glemt hvad forretningsmålet egentlig var
  • I praksis kan de agile værdier og principper også være svære at sluge. Vi kan blive principielt enige om at vi værdsætter ”Individer og interaktioner” højere end ”processer og værktøjer” men det kan være rigtigt svært at omsætte når virksomhedens succes er bygget på en årelang fokus på gode processer, kvalitetssystem og værktøjer. Ligeledes kan det også være svært at passe den iterative model fra f.eks. Scrum fra IT og software ind i andre af virksomhedens funktioner, der altid har været der og virket. Hvordan får man f.eks. en årlig budgetlægning til at passe med at vi ikke vil lave faste planer for vores udvikling mere end en måned ud i fremtiden?

Men hvorfor er det så svært?

Agile startede som en refleksion på at verden var blevet mere kompleks end tidligere. Det agile manifest fra 2001 er baseret på de udfordringer man havde oplevet med softwareudvikling. ”Scrum Guide” bogen af Ken Schwaber og Jeff Sutherland beskriver ligeledes at: ”Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex prolems”.

Forenklet kan man sige at formålet med agil altid var at være værktøjet der skulle løse komplekse problemer – på samme måde en skruetrækker løser skrue-problemer. Man kan måske godt bruge skruetrækkeren til at løse søm-problemer også men det kunne også være at den gode gamle hammer, vi allerede havde i værktøjskassen, var bedre til det.

Dette er en kraftig simplificering af en af pointerne Dave Snowden giver i Cynefin frameworket og i detaljer i sin seneste bog fra lige før jul ”Cynefin – Weaving Sense-Making Into the Fabric of Our World”. Jeg dykkede, i samarbejde med Dansk Projektledelse, ned i emnet på et webinar afholdt tidligere på året. På webinaret så vi også på, hvordan vi i en af Danfoss’ divisioner brugte frameworket til at definere rammen for den agile transformation. Alle detaljerne bliver for overvældende for denne artikel og for den nysgerrige vil jeg gerne anbefale at (gen-)se webinaret eller deltage, når vi gentager det tirsdag 12. oktober 2021.

Budskabet er dog enkelt nok: Kompleksitet er kodeordet og opgaver, problemer og projekter af forskellige kompleksiteter skal behandles forskelligt for at blive løst bedst muligt. Du kan se hele webinaret ved at klikke på billedet:

Men hvad er nøglen så til den agile transformation?

Nøglen er at gøre sig bevidst om kompleksiteten af de enkelte opgaver/projekter og behandle dem forskelligt. Bruge skruetrækkeren til skruerne, hammeren til sømmene:

  • Er opgaven en vi har lavet mange gange før, simpel og forudsigelig skal den bare eksekveres med mindst muligt overhead. Hvis vi f.eks. har en standard procedure eller en der ved præcis hvordan man udfører opgaven, er den optimale måde som regel ”just-do-it”. Her giver det agile ikke mening og er i værste fald en forhindring for at udføre opgaven med effektivt
  • Er opgaven mere kompliceret men stadig forudsigelig – hvis den kan analyseres med eksperter, så man kan lave en god plan up front, skal man endelig gøre det. Er det f.eks. 10. gang vi laver en ny variant af et kendt produkt eller vi laver en mindre ændring, hvor vi kan planlægge det med de rigtige produkteksperter, vil det som regel være den ideelle måde at gøre det på. Vandfaldsmodellen virker fortrinligt her og sikrer man metodisk kommer igennem alle de læringer man har fra tidligere med involvering af alle de rigtige eksperter der sikrer sig man har gjort det rigtige inden man fortsætter
  • Kun hvis opgaven er uforudsigelig og kompleks får man den helt store værdi af den agile arbejdsform. Når vi ikke helt ved hvad der sker om 2-3 skridt er vi nødt til at prøve os frem, sikre hurtige læringsiterationer og at vi kan ændre kurs som vi lærer hvad der virker. Her giver det værdi at forholde sig kritisk, reviewe med kunden og interessenter for at afklare om vi gør det rigtige, værdsætte og udnytte forandringer osv.

Alle virksomheder jeg er stødt på, har opgaver og projekter af alle kategorier. Større projekter og programmer kan også ofte indeholder opgaver af forskellige kompleksiteter og man vil også (forhåbentligt) opleve at et komplekst projekt bevæger sig mod at blive mere forudsigelig efterhånden som teamet lærer.

Dette er en vigtig erkendelse for det må jo betyde at man ikke blot kan anvende 1 model der dækker alle de opgaver man har. Det vil som regel være bedre at have en værktøjskasse med skruetrækker, hammer og bidetang end at prøve at lave en ”skrue-hammer-tang” hybrid der ikke rigtig er god til nogen af problemerne.

Skal vi så stoppe de agile transformationer?

En agil transformation kan, hvis den bliver gjort godt, give rigtig stor værdi og hjælpe med at blive bedre til de komplekse opgaver. Jeg har været med til at redde kritiske projekter, reducere time to market og øge profitabilitet ved at anvende agile metoder. Det virker – på de komplekse projekter. Men, man skal passe på ikke religiøst at konvertere hele virksomheden. Man risikerer nemlig at blive dårligere til de mere forudsigelige opgaver som i mange virksomheder er de der vejer tungest på dette års overskud.

Eller sagt på en anden måde: Lad være med bare at gå agil, men lad kompleksitet drive jeres agilitet!

Mark Madsen

Mark har mere end 20 års erfaring med ledelse af projekt- og kvalitetsorganisationer fra virksomheder som Danfoss, Saab, Mærsk og Lego. Han har også 15 års erfaring med agile transformationer og har både set hvilke signifikante forbedringer man kan opnå ved at anvende de agile metoder, men også hvilke forhindringer der kan være på rejsen og hvor agil gør mere skade end gavn. I juli 2020 startede han virksomheden Aspire Innovation sammen med amerikanske og tyske partnere med formålet at hjælpe virksomheder blive hurtigere fra idé til profit gennem effektiv projekt- og porteføljestyring.


Styrk dit netværk

Bliv en del af et stærkt netværk, der tør videndele og udveksle erfaringer for at løfte ledelse af projekter.

Bliv medlem af DPL

leave a reply