Hvis det lyder banalt - så er det fordi, at det vitterligt er banalt. Men for pokker hvor var det svært. Jeg bokser stadig med det hver eneste dag. Mere om det længere nede. Jeg vil nemlig gerne starte med at fortælle om de første dage efter teamdannelsen.
Dag 1: R.I.P. Daily Scrum
Dagen efter, at teamsene havde dannet sig selv, var det tydeligt, at alle teams havde fået et ordentligt skud selvtillid. De ville bestemme mere, og de ville tage mere ansvar.
Der findes en ret sød stack exchange, hvor en forfærdet leder beretter om, at hans selvorganiserende team har fyret ham.
After their first retrospective (which I was not a part of), the scrum master came into my office. He said that the team has collectively agreed to "fire" me as their manager.
Fedt, mand! Så er der gang i den. Selv-organisering kan virkelig være et wakeup call for teammedlemmerne. Pludselig vil de mere.
Et af teamsene stoppede som eksempel straks med at holde Daily Scrum - et af de mest hellige ritualer i Scrum Guiden.
Prøv og hør!
Vi er fire mand.
Vi sidder lige ved siden af hinanden.
Vi teamer alligevel op det meste af dagen.
Vi ved altså godt, hvad hinanden laver.
Og sådan afgik Daily Scrum ved døden fra dag 1 i et af de nye teams.
Andre teams beholdt deres Daily, og de begyndte på eget initiativ at tage deres sprintburndown frem under Daily Scrum - uden at være blevet bedt om det. Noget helt utænkeligt før teamdannelsen, hvor sprintburndownen mest blev forbundet med et udefrakommende pres.
Det blev hurtigt tydeligt, at alting var forandret. Selvdannelse var ikke et punkt i tid. Det var en vej, vi var gået nedad.
Jeg er kommet i det bedste team!
På 1:1'er med udviklerne sagde alle, at de følte sig så heldige, at netop de var kommet i det bedste team. Altså alle udviklere i alle 6 teams følte, at de var havnet i lige netop det bedste team. Sådan føltes budskabet i hvert fald, når man sad på ledelsessiden. Det var en ret magisk oplevelse.
Men med den nye energi fulgte også nye forventninger.
Da en udvikler fx skulle flytte team, kortsluttede min hjerne og jeg indkaldte teamet for at overdrage dem nyheden. De blev vildt skuffet over mig. Jeg havde givet dem mandatet til at danne sig selv, og så kom jeg bagefter og special case'de en enkelt medarbejder. Og bemærk: Det her var 2 år efter teamdannelsen, og medbestemmelsen sad stadig så dybt i teamsene.
Den vej, vi gik ned ad, har slået dybe rødder. Og hvad gør man så som leder, når man har uddelegeret så centralt et ansvar som til teamsene. Jeg har begået fejl flere gange, fordi jeg i min handleiver har glemt, hvad det er, jeg har organiseret teamsene omkring, og hvad mit eget fokus bør være. Men det meste af tiden går det godt. Der er ikke én løsning på, hvordan man holder fast i uddelegeringen af teamdannelsen. Jeg har i stedet samlet nogle cases.
Herunder inddeler jeg dem i:
- Hyr - når vi skal ansætte til et team
- Fyr - når vi skal afskedige i et team
- Juster - når vi skal flytte udviklere mellem teams
Hyr
Det at ansætte medarbejdere er en kompetence. Det er ikke nogen nem kompetence at oparbejde, og ansættelser er beslutninger med højt impact for en virksomhed.
Vores grundregel er, at lederne kan takke nej, og teamsene kan takke ja.
I ansættelsesprocessen frasorterer lederne de kandidater, som ikke lever op til virksomhedens krav. Det lyder nemmere, end det er. For hvor tydelige er kravene egentlig, og hvordan ved man, om kandidaten kan leve op til dem.
Jeg tror stadig på grundreglen if in doubt - leave 'em out.
If in doubt - leave 'em out.
Der er sjældent kommet et godt match ud af at håbe på, at det går. Og af den årsag har jeg desværre takket nej til for mange dygtige kandidater igennem tiden. Jeg husker stadig nogle af dem, jeg fortryder og har efterfølgende prøvet at række ud til nogle af dem, men ikke overraskende falder de mig ikke om halsen. Og jeg er da også blevet mere fleksibel med tiden, men jeg har også været igennem virkelig mange interviews for at nå dertil.
Når kandidaten er kommet igennem lederens nåleøje, skal teamsene stadig takke ja. Og det hænder faktisk, at de ikke gør det. I løbet af de sidste par år har et team valgt ikke at takke ja i en lille håndfuld tilfælde. Lederen kan så overveje, om kandidaten kunne passe i et andet team og prøve igen. Ofte er det jo bare matchet mellem kandidat og team, der ikke var der.
Tager vi det alvorligt, når teamsene ikke siger ja? Ja, det gør vi. Når teamsene er små, er det svært for et enkelt teammedlem at sidde og gemme sig. Det var præcis det, vi (og teammedlemmerne selv) ønskede at undgå, så vi får problemerne på bordet hurtigt og kan reagere på dem.
Men det betyder også, at et mismatch mellem et team og bare et enkelt medlem af teamet hurtigt skaber ubalance i hele teamet.
Vi kan godt finde på at gå tilbage til teamet for at være sikre på, at de har forstået konsekvenserne af ikke at takke ja til en ny medarbejder. Men det er deres beslutning, og det forstår de godt.
Teamet forhandler ikke med kandidaten. De har ikke en opgave med at forholde sig til kandidatens lønniveau eller andre formelle ansættelsesprocedurer. Det hænger sammen med næste punkt.
Fyr
Personligt ville jeg være villig til at uddelegere afskedigelsesansvaret til et team. Men jeg har stadig til gode at møde det team, der ønsker og kan varetage det ansvar. Så i vores organisering bor det fortsat uden undtagelse hos personalelederen, og vi har aldrig overvejet andet.
Der er grænser for selvorganiseringen.
Dave Nicolette beskriver i denne fremragende artikel et tilfælde, hvor han lader et team varetage opgaven fra identifikation af et mismatch i teamet over den svære samtale med forbedringsplaner og indtil teammedlemmet selv søger sin fratrædelse.
Dave Nicolette konkluderer:
The team decided they never again wanted to deal with a human resources issue. They had discovered their own limits. They embraced self-organization whole-heartedly and effectively. When it came to self-management, they learned that they did not wish to “own” it.
Det tror jeg vil være tilfældet for næsten alle teams. Det er selvfølgelig et ekstremt tilfælde. Men pointen er vigtig nok: Der er naturlige grænser for selvorganiseringen i alle organisationer.
Derfor italesætter jeg det sådan, at teamsene kun kan takke ja til hinanden og ikke nej.
Justér
Den største power, selvdannelsen gav os, var muligheden til at uddelegere en svær bemandingsopgave til ét eller flere teams.
Jeg bliver gang på gang imponeret over teams evne til på tværs at løse svære bemandingsopgaver. Når vi identificerer et behov og giver opgaven med at løse opgaven til teamsene, er det en arbejdsdeling, de intuitivt forstår. Selvdannende teams kan godt forstå, at der er et forretningsbehov for, at de har en bestemt bemanding eller kompetencesammensætning, og de kan godt finde ud af at løse den opgave.
Det sværeste er snarere for lederen, der skal vende sig til ikke at tænke implementering, men i stedet skal overveje, hvad hans behov egentlig er. Så skal teamsene nok håndtere implementeringen.
Hvad mener jeg med implementering?
I gamle dage ville jeg have tænkt noget i retning af: Jeg har brug for, at udvikler A og B danner en task force i 3 måneder, hvor de løser problem C. Så ville jeg have talt med den ene, så den anden, og så ville jeg have kommunikeret det.
Det er en organisatorisk implementering.
Men hvad er mit organisatoriske behov egentlig?
Det er måske, at problem C har en projektafhængighed, der gør det til et akut problem, som skal løses hurtigst muligt.
Måske er der andre dele af projektet, der ikke kan starte op, før problem C er løst. Den opgave, kan selvorganiserende teams godt løse. Den kan stilles på en anden måde: Problem C er vigtigt, fordi det lige om lidt blokerer Projekt X. Projekt X skal starte om 3 måneder. Hvordan anbefaler I, at vi løser det?
Det er en helt anden måde at gå til ledelsesopgaven på, som både er befriende og vanskelig. Jeg øver mig stadig.