Tillid gør samarbejdet meget lettere — sørg for at bevare den.
Agilt samarbejde kræver en god del tillid, både internt på teamet og mellem teamet og omgivelserne. Særligt har man brug for udstrakt tillid fra beslutningstagerne rundt omkring projektet — de skal stole på, at vi gør vores bedste, og at vores bedste er godt nok.
Jeg har forklaret mange ledelser om ideerne i agile metoder og hvorfor (og hvornår) de virker. Mine forklaringer ser ud til at virke og have effekt, når jeg har deres tillid. Derimod ser de slet ikke ud til at gøre indtryk, hvis jeg ikke har deres tillid.
Når der er tillid
Når der er tillid til, at vi gør vores bedste, og at vores bedste er godt nok, så snakker vi åbent og ærligt sammen om fremskridt og mangel på samme. Ingen føler, at de skal forsvare sig, så instinktet i samtalen er at være åbne og kommunikere så klart som muligt.
Når der er tillid, så virker de agile planlægningspraktikker godt: vi udvælger sammen det mest værdifulde ting at samarbejde om, og vi laver en forventningsafstemning om, hvad vi kan have klar om 2 uger. Og så går vi i gang.
Når der er tillid, så er der tilfredshed med en forsikring om, at vi hele tiden laver det, der giver mest værdi — "vi ved ikke præcis, hvad produktet indeholder om et år, men vi ved, at det er det mest værdifulde".
Når der er tillid, er der tillid til, at teamet løfter i flok.
Når der er tillid, så er der lydhørhed, når man forklarer, at man gerne vil bruge lidt mere tid på at rydde op, refaktorere, forbedre koden, så den bliver ved med at være let at arbejde med.
Når der er tillid, er opgaver noget, man kan snakke om på overskriftsniveau: "Vi skal have en måde at nulstille passwords".
Når der er tillid, så går 98% af opgaverne let, og så er der 2% af opgaverne, som skal have en tur til eller 10. Det har vi jo så tid til, når de fleste opgaver blev klaret hurtigt.
Når der ikke er tillid
Hvis tilliden mangler, så er det menneskeligt at passe på sig selv ved at spekulere i, hvordan man bliver opfattet. Hvordan skal jeg forklare den forsinkelse, så de ikke synes, at det er mig der er dum eller doven?
Hvis tilliden mangler, så er det måske klogt at "puste sine estimater lidt op", så man ikke risikerer at skuffe, og får en indbygget buffer.
Hvis tilliden mangler, så er en almindelig plan for sprintet ikke nok. Så skal der måske suppleres med et "commitment" og et "stretch goal" — og en diskussion af, hvad der så skal ske, hvis/når commitment ikke nås.
Hvis tilliden mangler, så skal der være svar på "hvornår vi er færdige", "hvad er med om et år? og om to?".
Hvis tilliden mangler, så skal der være "accountability": hvem har ansvaret for, hvis dit eller dat ikke lykkes?
Hvis tilliden mangler, så bliver udviklernes snak om, at man gerne vil forbedre koden, opfattet som "gold plating" eller et tegn på, at man ikke kunne finde ud af at lave det ordentligt i første omgang.
Hvis tilliden mangler, så skal opgaver trackes og styres og leve op til alle mulige formkrav, og vi bruger længere tid på at specificere og designe featuren til at nulstille et password, end det ville tage at bare at lave den.
Hvis tilliden mangler, så bruger vi længere tid på alle opgaverne, for at forsøge at sikre os, at ingen af dem kommer til at koste mere tid end de andre.
Et selvforstærkende problem
Hvis tilliden er der, så er vi effektive og responsive, aftagerne bliver gladere, og tilliden går op.
Hvis tilliden først mangler, så er det hele mere besværligt og langsomt. Alting tager længere tid. Alle bliver frustrerede. Og tilliden går ned.
Tillidskontoen
Derfor snakker vi tit om en tillidskonto for et projekt. Hvor meget tillid har ledelsen til projektet? Hvor meget tillid har projektet til ledelsen?
Generelt har vi et plus på kontoen, når vi starter, for ellers havde vi ikke fået lov at gå i gang.
Når vi leverer (laver en god release, eller giver en god demo), så sætter vi ind på tillidskontoen.
Når vi skuffer (bliver forsinkede, rammer ved siden af, eller på anden vis ikke lever op til forventningerne), så hæver vi på tillidskontoen.
Når kontoen kommer under nul, så er vi i tillidsunderskud, og så kommer der ekstra krav og kontrol og bureaukrati, og risikoen for at havne i den nedadgående spiral er overhængende.
Derfor skal vi reagere inden vi når 0. Mens vi stadig har tillid tilbage skal vi sørge for at imponere og levere, så vi får sat ind på kontoen og erobrer noget tillid tilbage (og fortjene den). Hvis vi venter til vi er under 0, så skal vi både levere og leve op til de ekstra kontrolkrav, som bliver stillet, når tilliden er røget.
Derfor skal vi starte med at levere tidligt. Når projektet starter har vi et lille plus. Sørg for at komme hurtigt i gang med at levere, sende noget håndgribeligt i produktion. Så har vi et større plus og mere albuerum til at tage de næste skridt.
Det sværeste er at grave sig op, når man først står i et tillidshul. Man kan måske forklare sig og bede om en chance mere, snakke sig til et "tillidslån", men det er svært, og man får ikke mange af de chancer, så i så fald skal man også gribe chancen og levere og tanke tillid ind på kontoen.
Hvis der er underskud er det særligt vigtigt at levere, at fortjene mere tillid, at sætte ind på tillidskontoen. Det kan være nødvendigt at leve op til de ekstra kontrolkrav (og her kan det være særligt nyttigt at hjælpe med at finde nogle måder at levere følelsen af mere kontrol, uden at teamet skal bruge al for meget tid på det), men sørg for også at have tid og kræfter til at levere nogle successer, så kontoen kan komme i plus.
Og måske kan et projekt komme så langt i tillidsunderskud, at man skal væk, at nogle andre skal overtage, eller projektet skal genstartes med nogle andre personer. Ikke fordi nye koste fejer bedre, men fordi de kan starte uden overtræk på tillidskontoen.
