Kære leder – dit glasgulv er dine medarbejderes glastag

Er du en af de ledere, der har investeret i agile arbejdsformer – og nu undrer dig over, hvorfor det ikke virker som lovet?

En af dem, der har brugt store mængder tid og penge på at styrke autonome teams, så de kan tage ansvar for udviklingen af de produkter, de ejer. Enten fordi du oprigtigt tror på de fordele, det giver – både i effektivitet og i den værdi, produkterne skaber.

Eller fordi du er blevet påvirket af tidens tendenser eller dyre konsulenter som McKinsey m.fl., der nu også anbefaler moderne produktteams som den måde, man bør organisere sig på for at imødekomme fremtidens udfordringer. Det er de samme løfter, vi har hørt gennem de sidste tre årtier – ja, siden Agile blev født.

Gennemsigtighed var også en del af pakken, men for mange føles det mere som at stå på et glasgulv: Man kan godt se, hvad der foregår i organisationen, men det er svært at forstå og handle på det.

Mange har taget idéen om øget agilitet til sig – for at kunne konkurrere bedre og slippe fri af de tunge processer, der bremsede organisationen. Men for mange har det vist sig, at de store løfter er svære at indfri – og fulde af udfordringer.

Gennemsigtighed var også en del af pakken, men for mange føles det mere som at stå på et glasgulv: Man kan godt se, hvad der foregår i organisationen, men det er svært at forstå og handle på det.

Mange ledere savner den tid, hvor de kunne stille klare krav og følge tydelig projektfremdrift. Hvordan endte vi her?

Samtidig har det overrasket mange, at stærkere, mere selvkørende teams ofte reagerer med modstand på den traditionelle kommandovej og klassiske ledelsesadfærd.

Pludselig begynder teams at:

• Sætte spørgsmålstegn ved strategien
• Finde porteføljeplanlægning mangelfuld
• Kræve eller modsætte sig organisationsændringer
• Afvige fra enterprise-arkitektur
• Afvise deadlines
• Modsætte sig målinger
• Osv.

Hvornår blev det teamenes ansvar? Det er jo ledernes opgave at styre organisationen!

Hvorfor leverer de ikke bare det, de skal – til tiden?

Hvordan er lederne endt på et glasgulv, der forhindrer dem i at udføre deres job? De kan godt se, hvad der foregår på overfladen, men de kan ikke få fat i det. Det føles som om, man har mistet kontrollen.

Skabte lederne selv glasgulvet, eller gjorde teamene det?

Hvis du er en af de ledere, der kan genkende denne frustration, bør du læse denne artikel for at forstå, hvad der sker. Ved at forstå den anden side af udfordringen kan du muligvis løse den. For det vil altid være dit ansvar, at organisationen leverer. Hvis du ikke selv er leder, kan du bruge indsigten til at hjælpe din organisation med at afstemme forventningerne mellem ledelse og teams.

Du skal arbejde dig igennem glasgulvet for at flytte organisationen fra agilitet på team-niveau til organisatorisk forretningsagilitet.

Teamets perspektiv

Hvor du oplever problemerne som et glasgulv, som teamet ikke vil lade dig trænge igennem, har agile coaches og Scrum Masters i årevis omtalt dette mismatch som det agile glastag (”The agile glass ceiling") – et tag, der forhindrer dem i at interagere med organisationen ud over teamniveau.

Det er det samme problem, de samme glasplader, de ser. Det ser bare forskelligt ud afhængig af, om man er over eller under glasset. Organisationen under glasset har radikalt ændret måden, de arbejder på, mens resten af organisationen fortsætter som før.

Fra deres perspektiv stammer denne skævhed fra, at teams er blevet bedt om at ændre deres arbejdsformer, mens resten af organisationen ikke tager højde for, hvor grundlæggende disse ændringer er.

Teams ser ledere, der fortsætter som før. De har svært ved at få den nye autonomi og de gamle ledelsesstrukturer til at hænge sammen. Ledere lever uforvarende ikke op til løftet om empowerment; altså handlefrihed i det enkelte team. Den eksisterende økonomiske og strukturelle model er ikke designet til autonome teams, der derfor alligevel ikke er helt selvstyrende.

De organisatoriske emner ovenfor er blot nogle få eksempler på, hvor der eksisterer uoverensstemmelser over og under glasloftet eller -gulvet. Det er suboptimalt. Det skaber friktion, og det koster penge.

Med friktion mener jeg her de tab, der opstår som konsekvens af:

• Misforståelser i kommunikation

• Manglende fælles retning

• Mistede gevinster ved genbrug

• Endeløse diskussioner

• Lavere motivation

Disse forskellige perspektiver er måske ikke nye, men i traditionelle organisationer havde lederne per definition ret, og organisationen fulgte med. Det har dog ændret sig: Empowerment af teams betyder, at deres perspektiver skal respekteres – i det omfang, de har mulighed for at træffe langt flere beslutninger, der påvirker den værdi, de skaber for brugerne.

Så længe de beslutter i tråd med de overordnede retningslinjer, er det normalt ikke et problem, at teams tager beslutninger. Det er det heller ikke, når presset er lavt: Når konkurrencen er lav, pengene tjener sig selv, og kunderne er glade.

Når det ikke er tilfældet, er det dit ansvar som leder at sikre, at "trappen" fungerer – også i overensstemmelse med løftet om autonomi og empowerment. Det kræver, at du selv ændrer adfærd og leder samt faciliterer løsninger, som måske tidligere virkede utænkelige.

Organisationen under glasset har radikalt ændret måden, de arbejder på, mens resten af organisationen fortsætter som før

Eksempler på misforståede perspektiver

Lad os se nærmere på nogle af de situationer, hvor ledelsens og teamenes perspektiver ikke stemmer overens:

Strategi set fra teams

Ledere forstår ofte strategi som noget, der handler om at skabe forretningsmæssig vækst, mens teams fokuserer på at hjælpe brugerne til bedre at kunne udføre deres arbejde. Begge perspektiver kan være rigtige samtidig, da et bedre produkt skaber større kundeloyalitet og dermed vækst. Men vejen dertil afhænger af, hvem der får lov at tage beslutningerne.

Et lille eksempel:

Et forsikringsselskab ville øge salget af tillæg til basisforsikringer. Et udviklingsteam blev derfor bedt om at bygge en webløsning, der gjorde det nemt at købe tillægsforsikringer.

Teamet gik videre og gennemførte et eksperiment, hvor kunder også kunne fravælge tillægsforsikringer – noget der gik imod den eksisterende strategi, da man frygtede tabt indtjening.

Men eksperimentet viste, at salget blev fordoblet, selvom 10 % fravalgte. Det viser styrken i empowerment. Men hvad hvis eksperimentet var fejlet? Skal teams så kun gøre, hvad de får besked på, eller skal strategisk indsigt og beslutningskompetence fordeles anderledes?

Organisationsstruktur set fra teams

Ledere ændrer organisationen for at nå mål: økonomi, medarbejdertilfredshed, teknologi mv. Men den logik passer ikke altid til teamenes virkelighed.

Dette eksempel stammer fra et stort finansielt datacenter, som blev kraftigt påvirket af en omfattende reguleringspakke fra EU. Reglerne skulle implementeres inden for en meget stram tidsfrist, selvom lovteksten og vejledningerne langt fra var færdige.

Reglerne påvirkede næsten alle dele af de mange systemer, som bankerne – datacenterets kunder – bruger i deres daglige drift.

Hvis ikke kravene blev opfyldt rettidigt, risikerede bankerne at miste deres licens til at operere.

Hvordan løser man en opgave af den størrelse og kompleksitet inden for en snæver deadline og med så store konsekvenser? Ledelsen i datacentret og i bankerne gik – naturligvis – i gang med at analysere sig frem til et projekt, der kunne løfte opgaven.

De forestillede sig et projekt med 100 % fokus på netop denne opgave. Præcis som de fleste af os ville have gjort.

Men organisationen havde gennemgået en agil transformation i de foregående år og havde implementeret teams, der havde stærkt ejerskab til deres produkter og gode relationer til brugerne i bankerne.

Da disse teams hørte, at det store regulatoriske projekt var på vej, forstod de også, at de sandsynligvis ville blive splittet op, og at nye teams ville arbejde på 'deres' produkter – nogle med 100 % fokus på reguleringsopgaven, andre med fokus på den resterende roadmap, bugfixes osv. De indså, at omkostningerne ved at lære nye systemer og brugere at kende ville være enorme.

Derfor foreslog de at bevare den produktorienterede organisering, de allerede havde, og i stedet justere kapaciteten i de eksisterende teams, efterhånden som opgaven blev bedre forstået. De afholdt heldagsworkshops for at forstå kravene og hvordan de passede ind i deres respektive produkter. De identificerede også fælles ressourcer – fx nye datakilder – og aftalte, hvilke teams der skulle være ansvarlige for hvad.

Det fjernede naturligvis ikke risikoen eller opgavens alvor, men det viste, at eksisterende velfungerende teams kunne fortsætte deres leveranceflow uden at blive splittet op. Over tid viste det sig også, at de etablerede relationer mellem teams og brugere gjorde det lettere at indgå kompromiser, når tidsfristen krævede det, og at andre forbedringer fra roadmap’en kunne leveres sideløbende med den kritiske reguleringsfunktionalitet. Brugerne var engagerede og tilfredse.

Da projektet officielt var afsluttet, viste det sig, at teamenes tilgang også havde den fordel, at afslutningen – de sidste detaljer – blev håndteret uden problemer. Der var ingen overdragelsestab, fordi teamene følte ejerskab før, under og efter opgaven.

Det blev en vigtig læring for organisationen: Søg først løsninger i den produktorienterede struktur, før man splitter alt op for at skabe et klassisk projekt. Man tilføjede blot enkelte personer til at understøtte samarbejdet på tværs og kommunikere klart til ledelse, kunder og brugere. Opgaven blev løftet af teamsene – især deres Product Owners.

Hvad ville der være sket, hvis teamene ikke havde været modige nok til at foreslå et alternativ – og hvis ledelsen ikke havde stolet på dem? Det får vi aldrig at vide.

Enterprise-arkitektur set fra teams

Som ansvarlige ledere ønsker vi, at alle vores teams følger den definerede enterprise-arkitektur. Det giver mulighed for øget genbrug, konsistens for brugerne, højere kvalitet, større agilitet osv.

Eller – det er i hvert fald hensigten med at håndhæve begrænsningerne i de foruddefinerede rammer for teams.

Typisk har vi dedikerede enterprise-arkitekter, som udarbejder arkitekturen på baggrund af overordnede principper. De konsulterer ofte dyre eksterne specialister. Når arkitekturen er besluttet, forventes det, at hvert team følger disse rammer.

Teams står dog ofte over for forretnings- eller brugerkrav, som enten ikke blev taget i betragtning, da arkitekturen blev fastlagt, eller hvor de projekter, der skulle muliggøre de teknologiske ændringer, slet ikke blev prioriteret. I begge tilfælde må teamene selv afgøre, hvordan deres lokale arkitektur skal se ud, fordi de skal levere konkret værdi til brugerne.

Det eksempel, jeg vil fremhæve her, kommer fra en finansiel organisation, hvor mange systemer i årenes løb var blevet forbundet gennem en lang række projekter. Den strategiske ambition var at skifte til en ’enterprise service bus’, som i princippet skulle give alle mulighed for – via simpel konfiguration – at genbruge enhver integration. Det erstattede den arkitekturmæssige kompleksitet ved én-til-én-integrationer med en enkelt boks forbundet til alle systemer (se illustrationen herunder). Det krævede ’blot’ et projekt, der omskrev alle integrationer.

Ikke overraskende var det svært at få prioriteret et projekt uden direkte forretningsmæssig effekt.
‍
‍

Da organisationen blev omlagt til produktteams, blev det tydeligt, at vedligeholdelse af de eksisterende integrationer var blevet en tung byrde for integrationsudviklerne.

De skulle udvikle nye integrationer, men oplevede gang på gang at være flaskehalsen for at få arbejdet færdigt. De havde ganske enkelt ikke kapacitet til at implementere servicebussen. Alligevel formåede de – som et praksisfællesskab på tværs af teams – at beslutte, at hver gang de skulle ændre en integration, oprette en ny eller rette en gammel fejl, ville de yde en ekstra indsats for at fjerne de individuelle løsninger og i stedet udbygge den fælles base. Det forbedrede fejl¬håndtering, drift, osv.

De forbedrede også dokumentationen, så alle kunne vedligeholde alle integrationer. I løbet af årets første kvartal havde de skabt den vedligeholdelsesvenlighed, som det store projekt skulle have givet.

Integrationsudviklerne tog ansvar og løste et arkitektonisk problem – ikke på den måde, ledelsen og enterprise-arkitekterne havde planlagt, men på den måde, der rent faktisk kunne lade sig gøre, når det nødvendige projekt aldrig blev prioriteret. En lang række små, lokale beslutninger i autonome teams løste (bag kulisserne) et smertefuldt problem.

Hvor ville de have været, hvis Product Owners i teamene ikke havde forstået, at deres langsigtede succes afhang af at give integrationsudviklerne lidt albuerum? Hvis de i stedet havde klaget over, at de ikke kunne levere som lovet til ledelsen?

Dit ansvar

Fælles for de tre eksempler er, at teamene så verden markant anderledes end ledelsen – og at de nogle gange, selv når ledelsesdirektiver pegede i en anden retning, formåede at ændre både strategi, organisering og arkitektur.

Det er eksempler på succesfulde gennembrud gennem glasgulvet – eller glastaget – hvor teams over tid har gjort en forskel for organisationen. Selvstyrende teams greb muligheden for at forbedre deres arbejdsvilkår og levere mere værdi til brugerne.

Men ikke alle tilfælde, hvor teams går imod centrale beslutninger, ender lykkeligt. Bestemt ikke. Og pointen her er ikke, at pendulet bør svinge helt over til den anden side med fuld autonomi.

Konsekvensen ved at ignorere kompleksiteten er tabte forretningsmuligheder.

‍

Som nævnt i begyndelsen ønsker jeg blot at give et andet perspektiv og inspirere til at se værdien i at inddrage medarbejdere tæt på forretningens kompleksitet. De tre eksempler viser organisationer med komplekse brugerbehov, komplekse strukturer og komplekse teknologier.

Jeg vil mene, at produktudvikling er kompleks i enhver organisation – på grund af organisationens størrelse, de problemer produkterne skal løse, og den nødvendige teknologi. Kompleksiteten er givet – det nytter ikke at ønske, den var mindre, eller forsøge at skære det fra, der fra ledelsens perspektiv ligner unødig kompleksitet. Det er det sjældent.  Konsekvensen ved at ignorere kompleksiteten er tabte forretningsmuligheder.

Lederens opgave er ikke at reducere kompleksiteten i selve arbejdet, men at skabe et miljø, hvor folk kan arbejde effektivt med kompleksitet – hvor de rette praksisser og rammer mindsker modstand og gør komplekst arbejde sjovt, udfordrende og produktivt.

Det bør ikke være op til teams alene at tage initiativ til at skabe sådan en organisation – men de bør inddrages. De tre eksempler viser, at de faktisk kan bidrage til at løse meget komplekse opgaver på en bedre måde.

I sidste ende er det dit ansvar at bygge en organisation, der skaber forretningsmæssig succes. Vil du tage den udfordring op og omfavne kompleksiteten sammen med dine teams?

Er du klar til at investere tid i at bygge bro mellem livet over og under glasbarrieren?

Efter sommerferien kan du læse en artikel, der kommer med flere konkrete bud på, hvordan du som leder kan understøtte denne udvikling i praksis.