Gæstebloggen

For mange agile projekter ender i ren ragnarok

Agil coach.

Alene udtrykket får hårene til at rejse sig i nakken. Det er på alle tænkelige måder en forkert og underspillet titel for den person, der skal gennemføre en så stor forandring i en organisation, som agil udvikling og implementering kræver.

Søren Riggelsen er managementkonsulent og indehaver af konsulentfirmaet Sigma Q. Foto: Sigma Q

Vi har hørt og læst om agil udvikling i de sidste 10-15 år, og den agile model er på alle tænkelige måder helt rigtig. ¨ Den øger overskuelighed og gennemsigtighed, giver manøvredygtighed undervejs, reducerer fejl og forsinkelser, og virksomheder kan komme til markedet til aftalt tid og pris.

Dog transformeres både metode og organisation med agil udvikling. Derfor bliver omstillingen dobbelt kompleks.

Ved overgangen til agil udvikling er organisationen oppe mod en mangeårig organisationsstruktur, som er meget fast forankret. Den har opnået sin form og det liv den har gennem en periode på måske 20-30 år og udskiftes derfor ikke henover natten.

Hvis man som agil coach eller ansvarlig for den agile omstilling ikke har årelang erfaring med både agile arbejdsmetodikker, projektstyring gennem høj sø og change management – organisatorisk såvel som teknisk - kan det meget vel ende i en katastrofe. For alle involverede. Og så er vejen til succes endnu længere.

Læg teoribogen på hylden

I øjeblikket har virksomheder og koncerner fokus på forretningsudvikling, innovation og digitalisering. Kunderne er troløse, nye leverandører står på spring, og det er tvingende nødvendigt at komme til markedet med nye og bedre services. Helst i går. Der skal udvikles mirakler til kunderne, samtidig med at der ikke er tid til forulykkede it-projekter.

Den agile coach har en stor, stor opgave foran sig, og jeg mener, at der er diskrepans mellem titel og ansvar.

Når jeg anfægter agile coaches – og for den sags skyld også de direktører og bestyrelsesmedlemmer, der oprindelig har besluttet sig for at rulle agil udvikling ud over hele organisationen, skyldes det én ting: De tænker agil udvikling ’by the book’ og tager ikke højde for den enorme change management-proces, som er nødvendig for at lykkes.

Jeg har set agile transformationer falde fra hinanden mange gange i store danske og internationale virksomheder. Direktionen sætter full speed på båden i ukendt farvand. Og forventningerne til den agile omstilling forbliver uindfriede for alle parter.

Undgå – for alt i verden – at medarbejderne mister modet

Ved agil omstilling overgår den traditionelle organisation til noget, der ligner selvstyrende grupper – lad os kalde dem agile enheder.

Metodikken i disse enheder er markant anderledes end den, medarbejderne kender i forvejen. I en agil organisation skal medarbejderne kunne identificere mere på kortere tid, løse flere opgaver hurtigere og hjælpe sig selv i mange flere situationer end tidligere. Med andre ord får de ganske mange flere kasketter på, end de havde tidligere.

Det værste er ikke, at medarbejdere begår fejl eller er langsomme til at absorbere forandringer. Det værste er uden sammenligning, at de kan miste modet.

Når alle medarbejdere på én gang skal arbejde på en helt ny måde med en metode, de ikke kender, opstår udfordringerne.

De kompetencer, man har brug for til hvert projekt, skal nu findes inden for hver gruppe. Der flyttes rundt på kompetencerne, og dem der før sad sammen opsplittes og fordels i nye grupper. Måske har man ikke de rette kompetencer og skal finde nye?

Alt i alt bliver det dyrere og mindre supporterbart at distribuere kompetencerne på en ny måde – det skal man gøre sig klart.

Samtidig skal man finde ud af, om der bør være nogle fælles funktioner på tværs af grupperne, så man får en stram linje i forhold til fx it-infrastrukturen.

En infrastrukturansvarlig i én gruppe har ikke nødvendigvis samme billede af den samlede infrastruktur som en infrastrukturansvarlig i en anden gruppe. Derfor giver det mening at samle nogle centrale funktioner.

Når ledelsen i en stor virksomhed træffer beslutning om, at vandfaldsmetoden er forældet, og at det er på høje tid at overgå til agil udvikling, bør man som ansvarlig for processen kippe med flaget og sikre, at den organisatoriske forandringsproces går hånd i hånd med de agile projekter.

Sådan lykkes du med agil omstilling

Løsningen er at sætte ét enkelt skib i søen ad gangen. Ved at starte med et overskueligt projekt giver man med stor sandsynlighed de involverede medarbejdere en succesoplevelse i stedet for en syngende lussing. Dermed videreføres motivation og den positive ånd til næste agile enhed.

En tjekliste kan derfor se således ud:

1. Tilgang:

  • Vær bevidst om at tage små skridt ind i den agile verden, så summen af samtidige ændringer ikke bliver for stor.
  • Etabler først én eller få agil(e) enhed(er), som skal lave ét projekt. Få erfaring, inden I etablerer en ny gruppe og inden I etablerer fælles funktioner.
  • Tag folk med i gruppen, som kan være gode ambassadører for de øvrige medarbejdere i organisationen. Den positive ånd smitter.
  • Tænk change management ind fra start. Det er alt for sent, hvis man starter en uge inden go live. Tegn processerne op og klæd alle i organisationen på. Også selvom I starter med én eller få agil(e) enhed(er). Jo bedre forberedt medarbejderne er, jo mindre kaospilotering kræves efterfølgende.

2. Planlægning:

  • Få udarbejdet en overordnet kravspec uden for mange detaljer og skær leverancen ned til noget forståeligt og overkommeligt for alle involverede.
  • Brug tid på at præcisere funktionalitet, sprints og opgaveløsning. Hvad indgår i hver opgave? Hvilke tests skal laves? Og hvornår?
  • Sørg for at alle funktionaliteter og planer er forhandlet på plads med kunde og leverandør, så det til enhver tid er klart, hvilken funktion bliver udviklet/erstattet, og hvordan.

3. Produktionsfasen:

  • Sæt en grænse på max. 8 timer til hver del-opgaveløsning. Det kan sagtens lade sig gøre!
  • Hold stand-up møde eller telefonkald hver morgen for at høre, hvad hver person i gruppen har arbejdet med dagen før, hvad de skal arbejde med i dag, og om der er opstået udfordringer undervejs. Det er i den daglige dialog, at man finder ud af, om det vi har brugt lang tid på at beskrive nu også kan realiseres. 15-20 minutters stand-up-møde om dagen kan være guld værd!

4. Leverance:

  • Lav en demo, der følger det oprindelige oplæg. Dermed ved alle, hvad de kan forvente.
  • Følg op på alle udfordringer og sørg for, at de bliver løst i næste sprint. Det er altafgørende for succes.

Løsningen ligger i forberedelserne. God arbejdslyst!

Kommentarer (3)
Tobias Tobiasen

"Sæt en grænse på max. 8 timer til hver del-opgaveløsning. Det kan sagtens lade sig gøre!"

Det er et meget brugt mantra og lyder rart på overfladen. Men ofte oplever jeg det kræver urimeligt meget arbejde at bryde ting ned i max 8 timer. Og hvis man gør så bliver opdelingen kunstig.

Lad mig komme med et eksempel:
Product owner vil gerne have udført en load test og når resultatet af load testen foreligger så skal der rettes op på de værste ting.
I dette tilfælde vil jeg ligge en 5 dages opgave ind hvor der står "Udfør load test, find easy wins, fiks dem og skriv en liste over 'not so easy wins'." for man ved jo ikke på forhånd om det er et index i database, en cache eller en connection pool der er problemet.
- har du en dygtig udvikler så får du en masse fornøjelse og meget lidt overhead.

Hvis man skal dele det op i max 8 timer så tænker jeg det bliver:
* Implementer load test
* Kør load test
* Lav forslag til hvilke forbedringer der skal laves.
Så skal der laves en række nye tasks til næste sprint, de skal så diskuteres forståes af alle, estimeres og forhåbentlig planlægges til næste sprint. Det ender med at man bruger en masse timer på refinement møder i stedet for at lave optimeringer. I yderste konsekvens bruger man adskillige timer på at diskutere et database index der tager 30 minuter at tilføje.
Og har man 3 ugers sprints så går der virkelig lang tid før man får noget brugbart kode ud.

Hvordan ville du dele sådan opgave op i max 8 timer?

Anders Ahrentzen

"Følg op på alle udfordringer og sørg for, at de bliver løst i næste sprint. Det er altafgørende for succes."

At løse alle udfordringer i næste sprint lyder ekstremt ambitiøst i mine ører (med mindre man har et virkeligt velkørende team).

Jeg vil foreslå at man fokuserer på at få den løst dén vigtigste udfordring først, og derefter går videre til den næste. Ellers ender det nemt med at man render rundt om sig selv uden at komme nogen vegne.

Log ind eller Opret konto for at kommentere