Sådan dannede vores teams sig selv

Men det føltes ikke specielt modigt. Jeg var ikke på noget tidspunkt i tvivl om, at det kunne de godt. Ah, måske bortset fra under selve teamdannelsen, hvor jeg med en halv time til deadline fortsat ikke havde hørt fra teamsene. Der tilstår jeg, at jeg var rastløs. Bare lidt. Mere om det senere.

Men af alle de risici, vi løber i hverdagen, når vi bygger software i en industri, der i sin moderne form dårligt nok er 20 år gammel, virkede det her ikke specielt risikabelt. Hvorfor skulle de ikke danne nogle gode teams, når de selv skulle bo i dem efterfølgende? Og er det egentlig ikke lidt indbildsk at forestille sig, at jeg kunne gøre det bedre?

Altså: Du skal selv løse en opgave, og du skal selv leve med alle konsekvenserne.

Forstå mig ret. Det var slet ikke nogen nem opgave for teammedlemmerne.

Det er det værste, jeg nogensinde har oplevet, og jeg ønsker aldrig at gøre det igen!

For nogle af dem var det en direkte forfærdelig opgave. Den feedback, jeg fik bagefter, strakte sig fra: "Tak, fordi vi fik lov til at gøre det her!" til "Det er det værste, jeg nogensinde har oplevet, og jeg ønsker aldrig at gøre det igen!". Begge medarbejdere er heldigvis stadig hos os. Og begge er her 2½ år efter fortsat i det team, de selv dannede.

Jeg har hørt eksempler på ledelser, der efter at have sat papkort på væggen med elefantsnot gik direkte ud og satte teamstrukturen til afstemning i en Doodle via en alle-mail. Vær ikke den ledelse! Teamdannelsen skal have et formål og være gennemarbejdet. Og teammedlemmerne skal være med ombord. Det er trods alt dem, der skal bo i de nye teams.

Her er den korte udgave af, hvad vi gjorde:

1. Hav en årsag!  Vi havde været igennem en periode med meget høj opmanding, og vi havde brug for at dele vores 3 store teams ud i flere små teams. Det var den akutte årsag. Men vi havde også andre ambitioner, som jeg vil komme ind på.

2. Forberedelse. Forberedelse. Forberedelse. Vi brugte næsten et helt år på at forberede teamdannelsen. Med lidt spredte indsatser forstås, men det tog lang tid. Hvis vi havde været mere klare fra starten, kunne vi måske have gjort det på et halvt år. Men nok ikke hurtigere end det. Hvorfor? Fordi teammedlemmerne skulle være med, og alle skulle modne deres egne tanker.

3. På dagen. Vi satte en hel arbejdsdag af. Alle fysisk ind i samme lokale. To udenlandske medarbejdere blev fløjet ind. Ingen ledere til stede under teamdannelsen. Grundreglerne var, at der skulle køres mange iterationer, og at alle skulle være tilfredse, før der kunne finde en teamdannelse sted. Hvis teamdannelsen ikke lykkedes - og det var okay - så var det mig, der bestemte teamsene. Der ville ikke være en Runde 2.

Der var dagene efter:

Honeymoon-perioden, hvor alle meldte, at netop de var havnet i det allerbedste team. Det var vildt fedt.

Men der var også hangover-perioden. For hvilke nye forventninger skaber man til hinanden som leder og medarbejder, når man lader teamsene danne sig selv? Hvordan ansætter man til selvdannende teams? Hvordan afskediger man i et selvdannende team? Kan man flytte medarbejdere rundt mellem teams efter forretningsbehov, og hvordan gør man det med respekt for de dannede teams? Skal man have flere teamdannelser?

Alt det er spørgsmål til et andet blogindlæg.

Men lad mig i dette indlæg blot sige, at selvdannende teams ikke blot er et punkt i tid, hvor man danner teams. Det er en vej, man går ned ad.

Herunder den lidt længere forklaring til hvert af de tre trin: (1) Hav en årsag, (2) Forberedelse, hvor jeg beskriver metoden, og (3) På dagen, hvor vi gennemgår helt konkret, hvordan vi gjorde.

Trin 1. Hav en årsag!

Vi havde været ét udviklingsteam, som var vokset meget. Og vi skulle vokse endnu mere. Teamet var i den proces blevet delt i tre teams, der alle tre var ved at vokse sig for store. Vi accepterede de lidt for store teams, fordi det i vores tilfælde virkede til at være den mest effektive onboarding-strategi for de mange nye udviklere. Mindre teams bliver hurtigt mere skrøbelige, hvis der ikke er nok af de gamle eksperter at "fordele" ud i teamsene. Så for os var årsagen skalering.

Men vi havde også en anden ambition. For vi ville samtidig også styrke teamsene i en stærkere selvorganisering, og derfor virkede det naturligt, at selvorganiserende teams også skulle have indflydelse på deres egen sammensætning.

I mit oplæg fra dengang hed det ordret:

• Vi går fra en teamstruktur, der understøtter kraftig opmanding, til en teamstruktur, der skal understøtte og skalere feature-teams.
• Vi ønsker i den proces at give rum for selvbestemmelse og skabe grobund for et endnu bedre arbejdsmiljø.
• Teamdannelse er vanskelig, og der er ingen grund til at tro, at teamsene ikke er de bedste til at danne deres egne teams.
• Derfor danner teamsene de nye teams.

Det der med, at teamdannelse er vanskeligt, havde jeg erfaret adskillige gange, når jeg selv sad og skulle kloge mig på, om Anna mon arbejdede bedst sammen med Bent eller Charles. Der er så mange hensyn at tage i en god teamdannelse, at det er virkelig svært at ramme den perfekte teamsammensætning.

Trin 2. Forberedelse

Vi startede næsten et år tidligere med at tale med teamsene om selvorganisering. Det blev muligvis mest opfattet som "flavour of the month" til at starte med. Hvad har de nu fundet på i ledelsen?

Det var ikke et forberedelsesforløb, hvor vi fra starten kørte efter en stramt styret plan. Tværtimod havde vi en idé om slutmålet: skalering og mere selvbestemmelse, men vi kendte ikke vejen dertil. Vejen dertil opdagede vi sammen. Ja, faktisk var det først midt i denne proces, at vi overhovedet besluttede os for, at en del af vejen var selvdannende teams.

Teamstørrelse

På det tidspunkt havde jeg en klar forestilling om, at vi skulle ende med at danne 4 teams. Jeg havde også en forestilling om, at det var mig, der skulle danne de 4 teams. Selvom det ikke var noget, jeg havde taget stilling til. Sådan plejede det bare at være. Ingen af de antagelser viste sig at holde.

Der var ikke en køreplan for det, men det var vigtigt for os, at alle var onboardet i ambitionerne. Der foregik derfor flere snakke med de eksisterende teams.

Her blev idéen om meget mindre teams imidlertid født. Som en af senior-udviklerne udtrykte det:

"Hvis jeg sidder i et team med 9 andre udviklere, så føler jeg, at jeg er 10 % ansvarlig. Det betyder i virkeligheden ikke det helt store, om jeg er der eller ej. Hvis vi kun er 4 udviklere, så føler jeg mig 25 % ansvarlig. Så er det en kæmpe ting for teamet, hvis én person ikke er der."

Da jeg for en god ordens skyld tjekkede citatet med ophavsmanden, korrigerede han mig: "Faktisk sagde jeg 0,1 % ansvarlig, og årsagen er, at det er min erfaring, at følelsen af ansvar næsten helt forsvinder når man sidder i et stort team, men behold bare de 10 %".

Og den følelse nikkede mange af udviklerne genkendende til. For at være sikre på, at det ikke bare var de mest højtrøstede udviklere, der fik lov at være toneangivende, stemte vi faktisk om teamstørrelsen.

Afstemningen afslørede et overvældende ønske om at udforske muligheden for at være 4 udviklere per team. Herunder er forsidesliden fra vores første fællesmøde om den mulighed.

"Dør 4" var vores metafor for "4 udviklere per team". Udviklerne havde i øvrigt tilkendegivet, at hvis vi skulle afvige fra 4, så ville de hellere gå mod 6 end mod 2.

Efter en længere dialog besluttede vi os derfor for, at et team bestod af 4-5 udviklere. En lille detalje er, at så mange mennesker var vi slet ikke. Teamsene bestod derfor reelt af 3-4 udviklere til at starte med, men det gav os netop mulighed for at skalere yderligere med 1-2 udviklere per team uden at etablere nye teams.

Den dialog, der foregik med teamsene, var en del af den agenda omkring selvbestemmelse, som jeg nævnte ovenfor under "1. Hav en årsag". Men det er en historie til et andet blogindlæg. Herunder skærer jeg derfor hele dette spor fra og fokuserer udelukkende på den forberedelse, der handlede om teamdannelsen og ikke om selvorganisering og selvbestemmelse.

Jeg vil blot nævne én ting i dette indlæg:

Teamstørrelsen er en af de beslutninger, der har afledte effekter, som spreder sig som ringe i vandet. En del af de ringe indså vi heldigvis ret tidligt, men størrelsen på teamsene havde vidtrækkende konsekvenser i forhold til virkelig mange omkringliggende forhold såsom fysisk placering, relationen mellem udviklere og ikke-udviklere (fx PO'er og Arkitekter), evnen til at skalere gnidningsfrit, sammenhængen til backloggen og bemandingen i forhold til de konkrete projekter, der skal løftes.

Tilfældets magt: En podcast gav et nyt perspektiv

Som sagt vidste vi ikke, at vi ville lade teamsene danne sig selv. Som med mange andre gode ting i livet opstod idéen om teamdannelsen lidt ved et tilfælde.

En af vores PO'er havde hørt et podcast om selvdannende teams, som hun delte med mig. Jeg hørte det mange gange og grublede længe over det, inden vi trykkede på knappen. Da vi gjorde det, lagde vi metoden fra podcastet til grund for vores egen metode. Vi stjal den nærmest. Ud over podcasten fandt vi denne præsentation fra Agile 2017. Metoden havde været brugt hos JPMorgan Chase & Co. Om den også var opfundet her, ved jeg faktisk ikke. Men det gav en vis tryghed, at andre havde indgående erfaringer med, hvordan man skulle gøre.

De to bagmænd, Adam Hsu og Gabe Abella, har sammenfattet metoden i denne model:

Vi kopierede store dele herfra, men vi lagde selvfølgelig vores egen tolkning ned over.

Fx kendte vores teammedlemmer i ret høj grad hinanden i forvejen, fordi alle sad i den samme afdeling. Derfor var der eksempelvis nogle af "ice breaker"-øvelserne, vi nedtonede. Men i det store hele genbrugte vi så meget som muligt.

En vigtig del af opstartsprocessen var at finde gode facilitatorer. Sammen med metoden tror jeg, at det var en af de vigtigste succesparametre.

Vi fik opbakning til at være facilitator fra to personer i afdelingen, som var vant til at holde workshopper, men som også selv skulle indgå i teamsene efterfølgende. Det besluttede vi for at opretholde princippet om, at alle, der var til stede i lokalet, ville skulle indgå i et team, og at der ikke ville være ledere eller ledende medarbejdere til stede.

Selvorganisering og teamdesign

Det var en stor beslutning at nå frem til teamstørrelsen. Altså, hvor mange medlemmer, der skulle være i et team. Men det var lige så vigtigt at designe teamsene og deres ansvar. En vigtig erkendelse var også, at de to ting hænger sammen. Små teams giver flere teams, og både størrelsen på teams og antallet af teams skal passe sammen med teamdesignet.

For at tydeliggøre teamdesignet blev ansvarsområderne i de 6 teams, der skulle dannes, beskrevet før teamdannelsen og vendt med alle teammedlemmerne. Nogle ansvar var fælles mellem teamsene, mens andre ansvarsområder var vidt forskellige.

Som leder hjalp det mig til at flytte mit fokus fra, hvem der skulle være i teamsene, til hvad mine behov var. Jeg blev en slags PO for organiseringen, imens teammedlemmerne besluttede implementeringen. Det føltes grundlæggende som en sund ansvarsfordeling.

Der er også forskel på at være 3 teams, som vi var vant til, og 6 teams. Vi var ikke designet til at ekspandere fra 3 til 6 teams på alle roller. Derfor var vi også nødt til at ændre på vores processer. Fx fik vi ikke 6 PO'er fra den ene dag til den anden.

Nogle teams ville fx i en periode skulle varetage dele af PO-opgaven, og alle teams skulle køre efter et you build it - you run it princip; altså når man bygger et stykke software, så har man ansvaret for softwaren efterfølgende i produktion. Så der fulgte et større ansvar med de flere teams.

Selvorganisering og samarbejde

Et team har en personlighed på samme måde som mennesker har en personlighed. Teamets personlighed er mere end summen af de personligheder, der er samlet i teammedlemmerne. Teamets personlighed har betydning for, hvordan teamet løfter de faglige opgaver, men i høj grad også for, hvordan samarbejdet flyder.

Man skal kunne arbejde sammen.

Det var vigtigt for os, at teammedlemmerne arbejdede med deres forståelse for den enkeltes særkender for at skabe det bedst mulige samarbejde. Det er okay, at bølgerne nogle gange går højt, men vi skal nærme os hinanden og være baseret på gensidig respekt.

Vores programchef fik den idé at lade alle teammedlemmer forud for teamdannelsen gennemføre en personlighedsprofil med en times personlig opfølgning ved en coach. Ledelsesgruppen gennemførte dette forløb som de første, og vi vurderede, at det var tilstrækkeligt værdifuldt til at lade alle teammedlemmer gøre det samme. Her 3 år efter er det stadig et redskab, vi indimellem anvender, når der kommer nye teammedlemmer til, eller når der opstår nye teams.

Første simmulering

Men hvad nu hvis opgaven er uløselig?

Tænk hvis vi sender 30 mand ind i et lokale for at danne 6 teams, og det viser sig, at der ikke findes en løsning?

Hvis nu der med al deres gode vilje ikke er mulighed for på forsvarlig vis at skabe de teams, vi bad om?

For at være sikre på, at opgaven var mulig at løse, kørte vi først en proxy-simmulering med papkort. Altså hvor navnet på hver medarbejder var skrevet ned på et papkort.

Her var teammedlemmerne ikke med. Det foregik kun i ledergruppen.
Men vi ville være sikre på, at der fandtes gode løsninger, før vi sendte alle medarbejderne ind i et rum.

Med papkort prøvede vi derfor hurtigt at lægge løsninger ud, som tilfredsstillede de begrænsninger, vi havde opstillet i forhold til teamdesignet. Heldigvis konstaterede vi hurtigt, at det faktisk var muligt at danne gode teams, og at der var mere end én løsning. Der skulle pusles lidt. Opgaven var ikke nem, men den var langt fra umulig.

Det gav os en vigtig følelse af tryghed at vide, at vi var i gang med at give teammedlemmerne en realistisk opgave. Papkortene blev herefter kasseret. De blev ikke brugt i anden sammenhæng, og de findes ikke længere.

Da vi var færdige, tænkte jeg - ikke uden stor selvtilfredshed - at teamsene sikkert ville nå frem til nøjagtigt den samme konstellation, som jeg selv havde vurderet var bedst. Og i "gamle dage" var vi jo stoppet her og havde stimlet alle mand sammen og fortalt, hvordan de nye teams blev. Vi forkynder: Sådan her har ledelsen tænkt! Bum.

Så kunne teamsene mon gøre det bedre?

Eller ville de bare nå frem til den samme "åbenlyse" løsning som lederne?
Det spørgsmål måtte vi vente lidt på at få besvaret.

Anden simmulering

Anden simmulering var helt anderledes. Den var nemlig teamets og foregik på samme måde som den ville skulle gøre ugen efter under selve teamdannelsen.

Formålet var at tale metoden igennem, så vi fik mest muligt effektivitet på selve teamdannelsesdagen. Formålet var også at afmystificere teamdannelsen, og at gøre den konkret, så alle var med.

Jeg deltog i en kort præsentation og forlod herefter lokalet. Ikke uden sommerfugle i maven. Jeg gad godt have været en flue på væggen.

Trin 3. På Dagen

"Management is not allowed to participate in the meeting".

Management is not allowed to participate in the meeting.

Det er ikke ofte, man som medarbejder helt ublu har mulighed for at skrive sådan en sætning i en mødeindkaldelse til et møde i en it-virksomhed, men det var jo mine egne regler, så jeg kunne dårligt brokke mig.

Jeg har valgt at gengive facilitatorernes dagsorden i sin fulde længde herunder. Dog er alle navne anonymiseret.

Jeg beskriver de væsentligste pointer efterfølgende, så du kan springe agendaen over, hvis du ikke gider mellemregningerne. Men jeg opfordrer dig til at læse den.

--------------------------------------------------

Sent: 31. oktober 2019 13:35
From: Facilitator A
To: All
Subject: Information about the self forming team day

Hi everybody,

A little information about the self forming team day.
Date and time: 5. November 9.00-16.00
Location: Valby kulturhus, Valgårdsvej 4-8, 3th floor room 4

Agenda and process for the day

Of course you will also get something to drink and eat. And we will take breaks when needed so everybody can clear their head and get time to think and talk 😊

Kind regards

Facilitator A and Facilitator B

--------------------------------------------------

På det her tidspunkt var det meste af indholdet velkendt for alle.

Principperne bag teamsenes design havde været drøftet igennem længere tid, agendaen blev sendt ud på forhånd og havde været talt igennem tidligere, og teamsene havde allerede gennemført en simmulering af en teamdannelses-session.

Men nogle ting var nye.

Der var 3 nye kollegaer, som ikke alle havde mulighed for at deltage, fordi de var nyansatte, som endnu ikke var startet hos os. Nogle havde fået lov af deres arbejdsgiver til at deltage. De fik lejlighed til at præsentere sig selv. Men andre kunne ikke få fri. Her fandt facilitatorerne på, at de deltog in absentium. De blev præsenteret for teamet, de var repræsenteret med et A4-billede, og de havde én i gruppen til at tale deres sag.

Også hele delen omkring skills identification var uafprøvet territorium. Det var teammedlemmernes opgave at vurdere, hvilke skills der var vigtige på tværs af teams. Processen er beskrevet i dagsordenen ovenfor. Herefter skulle hver enkelt teammedlem vurdere sine egne skills. Her havde facilitatorerne fundet på et twist. Teammedlemmerne skulle både vurdere deres egne kompetencer på hvert område, men også deres interesse for området: Jeg er nybegynder på frontend-udvikling, men jeg brænder for at lære det. Eller: Jeg er ekspert på al vores gamle teknologi, men jeg hader at arbejde med det. Denne del af processen var vigtig, fordi den indgik i den diskussion, der foregik efter hver runde. Hov - hvorfor endte alle frontend-udviklerne i dét team - er I sikre på, at det er hensigtsmæssigt?

Teamdannelsen

Teamdannelsen forløb over et antal runder - op til 10. Det er ikke et "første vælger - anden vælger"-princip. Dem, der har prøvet det før, siger, at man skal smide de første 2-3 runder i skraldespanden. Her teamer folk bare op med dem, de plejer at spise frokost med, og de er ikke begyndt at arbejde seriøst med konstruktionerne endnu.

Og alle skulle efter en runde stemme for de nye teams, før der var en team-dannelse.

Jeg understreger: Alle skulle stemme for.

Efter frokost var der sluppet rygter ud fra teamdannelsen. Det gik ikke godt. De kunne ikke blive enige, og der blev i hver runde ved med at være nogen, som ikke kunne stemme for.

Timerne gik, og vi hørte ikke noget. Hvor ville det være ærgerligt, hvis det ikke lykkedes, og hvor ville vi gerne være en flue på væggen inde i dét lokale.

Vi nærmede os en halv time til deadline.

I nogle af de sidste runder havde facilitatorerne improviseret og bedt nogle af de teammedlemmer, der stadig ikke kunne finde en tilfredsstillende konstellation, sms'e til facilitatorerne under en pause. De var nødt til at vide, hvorfor tingene var gået i stå. Jeg kan ikke afsløre, hvad årsagen var, for jeg ved det ikke

Herudover havde facilitatorerne en presbold, som de udnyttede skamløst. Der var nemlig et alternativ til teamdannelsen. Alternativt var: Det lykkes ikke. Det var en vigtig erkendelse forud for dagen, at der var en reel risiko for, at det ikke ville lykkes. Og det ville være okay. Det havde vi italesat på forhånd.

Men selvfølgelig ville det føles som et nederlag at bruge en hel dag sammen uden at lykkes, og foruden denne naturlige følelse var præmissen for teamdannelsen følgende:

• Hvis teamdannelsen er succesfuld, så bliver den stående uændret. Der kommer ikke en leder bagefter og ændrer teamsene. Punktum.
• Hvis teamdannelsen ikke er succesfuld, så bestemmer jeg teamsene. Succesfuld inden for deadlinen vel at mærke. Der bliver ikke en Runde 2.

Der var altså ikke blot udsigten til en potentiel fiasko, men også konsekvensen i forhold til at miste retten til at danne egne teams. Facilitatorerne pressede på for at lykkes og mindede igen og igen om, at der ikke ville blive en Runde 2.

Det var nu eller aldrig.

Et kvarter før deadline ringede facilitatorerne: Vi har dannet teams. Hvad end der gav udslaget til, at teammedlemmerne kom i mål den sidste halve time, så kom de i mål. De lykkedes med at danne teams.

Jeg havde forberedt en "peptalk", som jeg gav, da jeg ankom, men om de tog den til sig, ved jeg faktisk ikke. For det var den mest trætte gruppe mennesker, jeg mødte, og som jeg nogensinde har skullet forsøge at peptalke. Man kunne mærke, at der havde været følelser uden på tøjet, og at det havde været en dag, der havde betydet noget.

Det var her en senior-udvikler kom op til mig, så mig i øjnene og sagde: "Tak, fordi vi fik lov til at gøre det her!".

Der var udmattet stemning, nogle gik på værtshus, og andre vendte snuden hjemad. Jeg tog forbi kontoret for at hente mine ting på vejen hjem.

Her gik jeg rundt og småsnakkede med teammedlemmerne, og det var her, jeg blev mødt af den udvikler, der sagde "Det er det værste, jeg nogensinde har oplevet, og jeg ønsker aldrig at gøre det igen!". Det havde med al tydelighed været en vanskelig opgave, jeg havde stillet dem, og som de havde taget på sig selv, men de havde gjort det.

Og blev det så bedre end "min" teamdannelse?

Som beskrevet længere oppe havde jeg jo simmuleret en teamdannelse nogle uger forinden. Jeg havde for længst smidt den i skraldespanden, så jeg havde faktisk ikke en Plan B ved hånden, hvis teamsene ikke lykkedes med teamdannelsen.

Det, der slog mig, ved de teams, vi fik, var, at der var typer af problemer, der forsvandt. Altså hele problemkomplekser, som blev løst. De ville ikke bare have været vanskelige for mig at løse, men jeg ville have løst dem ringere end teamet.

Min konklusion var klar: Teamsene var - selvfølgelig - langt bedre til at danne sig selv, end jeg var.

Abonnér på nye indlæg

Vil du læse fortsættelsen? Om honeymoon- og hangover-perioden?

Abonner på nye indlæg, så sørger jeg for at give dig besked, når fortsættelsen er klar.

Andre resurser

Is team self selection the obvious choice?