Sådan starter en velkendt gåde. Svaret afhænger af hvilken variant man hører. Gåden er ofte tænkt som et humoristisk indslag og bruges til at lufte fordomme, men er der et gran af sandhed i den?
Definition: Ringlemann effekten Tendensen hvor den individuelle performance per individ ændrer sig i takt med at teamet ændrer sig.
Den franske ingeniør Maximillien Ringlemann fandt i 1913 frem til ovenstående definition, som sidenhen blev navngivet ”Ringlemann effekten”. Hans observation blev understreget med følgende anekdote:
Forestil dig to hold bestående af hver 2 personer af omtrentlig samme styrke dyste i tovtrækning.
Første runde sættes i gang og de to hold begynder at trække. Hver person trække efter bedste evne. Marginaler afgør hvilket hold der vinder.
Inden næste runde udskiftes bagerste mand på begge hold. Hold 1 får tilføjet en stor stærk skovhugger mens hold 2 får tilføjet en ung konfirmand i stiveste puds.
Anden runde sættes i gang. På hold 1 ved den forreste mand, fra det oprindelige hold, at der står en stærk arbejdskraft bag ham og det kan måles at hans individuelle trækkraft er nedsat. Han slapper af og overlader ansvaret til den stærke skovhugger. På hold 2 opleves en anden tendens. Forreste mand, fra det oprindelig hold, ved at han er nødt til at trække ekstra hårdt for at vinde dysten, da holdets nye mand har mindre trækkraft end den tidligere.
Hvilket hold vinder? Hvilket hold er det bedste? Det nævner hverken teorien eller anekdoten – og det er for så vidt også uinteressant i denne kontekst.
I mit virke som agile coach har jeg ofte observeret noget tilsvarende hos it-udviklingsteams. Hvis vi udskifter tovtrækning med softwareudvikling, den stærke skovhugger med en erfaren udvikler og den unge konfirmand med en nyansat – så har vi en cocktail der kan genkendes i de fleste udviklingsorganisationer. Det er vigtig at være bevidst om denne effekt hvis man ønsker et effektivt team. Et team bliver sårbart hvis alle de svære og tunge opgaver primært bliver løst af de erfarne udviklere og alle de lette opgaver bliver løst af de mindre erfarne. Der findes mange løsninger på udfordringen, f.eks. pair programming, mentor ordning, træning og meget andet.
Har du oplevet noget tilsvarende og hvad har du gjort for at løse det?
Når et teammedlem ikke længere udfylder et ansvarsområde de ellers længe har påtaget sig f.eks. i forbindelse med sygdom eller ferie har jeg ofte set det have en effekt på de andre team-medlemmer. Som regel er der en der “vokser med opgaven” – og lever op til rollen i stedet. Det er sjovt nok ikke altid den man troede der ville gøre det – og jeg tror det er sundt at få teamdynamikken rystet igennem engang imellem.
Omvendt har jeg også set at hvis et enkelt teammedlem påtager sig for meget solo-ansvar, så træder de andre tilbage og bliver inaktive. Det er en effekt som er svær at vende selv efter det ansvarstagende team-medlem forsøger at inddrage de andre mere igen. Den slags teams har som regel brug for en ordentlig rystetur – f.eks. en krise som kun kan løses i flok.
Når et teammedlem ikke længere udfylder et ansvarsområde de ellers længe har påtaget sig f.eks. i forbindelse med sygdom eller ferie har jeg ofte set det have en effekt på de andre team-medlemmer. Som regel er der en der “vokser med opgaven” – og lever op til rollen i stedet. Det er sjovt nok ikke altid den man troede der ville gøre det – og jeg tror det er sundt at få teamdynamikken rystet igennem engang imellem.
Omvendt har jeg også set at hvis et enkelt teammedlem påtager sig for meget solo-ansvar, så træder de andre tilbage og bliver inaktive. Det er en effekt som er svær at vende selv efter det ansvarstagende team-medlem forsøger at inddrage de andre mere igen. Den slags teams har som regel brug for en ordentlig rystetur – f.eks. en krise som kun kan løses i flok.
Det vigtige er at holde problemstillingen for øje.
Der findes formentlig ikke en silverbullet. En krise kan måske være med til at løse problemet alternativt kan enten en team building event eller et vel-faciliteret retrospektiv møde være løsningen.
I samme åndedræt skal det også præciseres at der kun er et problem, hvis der er et problem. Med det mener jeg at det kan være en team beslutning at de erfarne udviklere tager de tunge og svære opgaver mens de uerfarne løser de lettere opgaver.
De situationer jeg har i tankerne er opstået ved teams der har gennemgået en del strukturelle ændringer med skiftende bemanding. Her har de tilbageværende følt at de “trak læsset” og at nye red på “frihul”. Løsningen her var en serie produktive retrospektiv møder med handlinger som pair programming, videndeling og mentorordning.
Det vigtige er at holde problemstillingen for øje.
Der findes formentlig ikke en silverbullet. En krise kan måske være med til at løse problemet alternativt kan enten en team building event eller et vel-faciliteret retrospektiv møde være løsningen.
I samme åndedræt skal det også præciseres at der kun er et problem, hvis der er et problem. Med det mener jeg at det kan være en team beslutning at de erfarne udviklere tager de tunge og svære opgaver mens de uerfarne løser de lettere opgaver.
De situationer jeg har i tankerne er opstået ved teams der har gennemgået en del strukturelle ændringer med skiftende bemanding. Her har de tilbageværende følt at de “trak læsset” og at nye red på “frihul”. Løsningen her var en serie produktive retrospektiv møder med handlinger som pair programming, videndeling og mentorordning.