Solen varmede let på kinderne, da Anders cyklede på arbejde, en ganske almindelig mandag morgen i marts. Denne dag var dog lidt særlig, da denne mandag markerede starten af den agile transformation på arbejde.
Ledelsen i IT havde i starten af året fortalt om deres planer om at blive agile. Kort tid efter var Anders og flere af kollegaerne blevet sendt på kursus i SAFe (Scaled Agile Framework) metoden, hvor de lærte om teorien bag den nye organisationsstruktur og det at arbejde i sprints. Det var noget af en ændring, det var der konsensus om i teamet.
Teams og sprints fremfor hierarki og vandfaldsprojekter
Hvert team er bygget op af et udvikler-team, en scrum master, og en product owner som er bindeleddet til forretningen. Anders er selv front-end udvikler, og ekspert i User Experience, og sidder i samme lokale som de 7 andre medlemmer i sit team. Det gør, at deres team kan være med helt fra idéudvikling, på baggrund af kravspecifikationen, til at køre projektet helt i mål.
Den organisatoriske omrokering har ændret meget. Det har været svært for nogle ledere at vænne sig til tanken om at opgive ansvar, men efter nogle måneder, var alle spændte og havde store forventninger til deres nye teams og den fokuserede måde at arbejde på. Stemningen var god og humøret højt, til teamets første stand-up møde. Det første sprint var i gang.
Men at arbejde i agile teams er krævende. Det var hårdt for teamet pludseligt at skulle agere på ny viden, hver dag. Og det var også svært at få de nye udviklingsprojekter til at flyve, når de gamle vandfaldsprojekter styrede backloggen. Det påvirkede Anders’ kollegaer, Clara og Phillip, mest. Den agile verden levede ikke op til deres forventninger, eller den ”hype” der havde været omkring det, og tilfredsheden i teamet dalede.
Fra siloer, til nye siloer?
Efter nogle travle måneder med sprints og fokuseret arbejde i teams, var det ved at gå op for Anders at han ingen idé havde om, hvad der ellers rørte sig i virksomheden. Han interagerede kun med sit eget lille team, og undrede sig over, om det egentlig var agilt?
Den feedback tog han med til toplederen, Steen, og forklarede at selv om kommunikationen internt i hans team var godt, synes han at der manglede kommunikation imellem teams. Videndeling manglede. Det havde Steen også hørt før.
Der gik nogle uger, og så kom Steen hen til Anders bord. Der havde været møde i ledelsen, og flere havde givet udtryk for de samme udfordringer. Mangel på kommunikation, mangel på tværgående alignment, og ingen fokus på langtidsplanlægning. De havde besluttet to ting, det første var at der skulle dannes grupper bestående af medlemmer fra forskellige teams, som mødtes og delte faglig viden, f.eks. iOS udviklere, eller scrum mastere. Det andet var, at de mindre teams blev del af en større gruppe, der skulle dele viden om deres sprints, scope, og fokus.
Fra at klatre karrierestigen, til fokus på udvikling
Mange af de tidligere stillinger blev opløst i det nye agile set-up, og folk fik nye roller f.eks. blev flere af projektlederne product ownere. Alle i IT-udviklingsafdelingen fik en agil rolle. Det skift i organisationsstrukturen der kom i forbindelse med teams, gjorde at organisationslagene blev brudt ned, og at IT-organisationen havde en fladere struktur.
Efter nogle måneder, var der én bekymring der fyldte meget for ledelsen. De var begyndt at blive bekymret for at medarbejderne ville miste motivationen, fordi den traditionelle karriere- og udviklingsvej var blevet sløret under de nye agile teams. Derfor begyndte de at fokusere på at italesætte både performance og udviklingen af både teamet og individuelt. Steen opfordrede Anders og teamet til at prioritere kurser og konferencer der understøttede deres roller. Det motiverede Anders, Clara og Phillip, fordi deres kompetencer og faglig udvikling blev anerkendt, og prioriteret.
Men hvad så nu?
Spol nogle måneder frem. Anders er lige mødt ind på arbejde, dagen starter med et stand-up møde, hvor teamet diskuterer det næste sprint. De afsluttede det sidste i går. De taler om deres performance, udfordringer, og fokusområder for det næste sprint.
Deres agile set-up er ikke helt efter bogen, der er nogle afdelinger der stadig kører efter vandfaldsmodeller, og der er stadig nogle udfordringer. Men, hele rejsen har været lærerig. Det Anders har bemærket mest er, at det er vigtigt at den agile tilgang er velkommunikeret, og at man fra starten af erkender at der kan være udfordringer ved ét agilt set-up. Og, så er det vigtigt, at man adresserer og løser udfordringer, når de opstår.
Hvad kan vi lære fra Anders oplevelse?
Agile transformationer er transformationer. De kan være store, omfattende, og påvirke mange medarbejdere. Derfor er det vigtigt at have en pragmatisk tilgang til agil transformation, og tilpasse metoden til virksomheden, og ikke omvendt. Når man skal i gang med en agil transformation, er det klart en fordel, at man har udført en agil modenhedsmåling, så man ved hvor man starter. Og så skal man huske at tænke alle interessenter ind og bruge forandringsledelsesprincipper, for at komme sikkert i mål.
Læs mere om udfordringerne med at skalere agile transformationer her.
*Anders og historien er baseret på inspiration fra flere der arbejder med agil transformation, men repræsenterer ikke en bestemt person eller deres oplevelse.