Det er ikke altid nemt at stå som udenforstående og skulle hjælpe et software-udviklings-team til at forbedre sig. Hvis der ikke er et generelt konstant forbedrings-mindset i kulturen, så vil visse teammedlemmer implicit i opgaven lægge en utalt anklage om ikke at være god nok. Et andet problem er den gode gamle kliche – alle vil have forandring, men ingen vil forandre sig.
På den anden side står folk som ser forandring, eksperimenter og forbedring som et grundvilkår i softwareudvikling. I den kategori finder vi mange udviklere, men også scrum-mastere og agile coaches som vil have svært ved at tage den modsatte position, da det netop er deres job at sikre disse ting.
Hvordan takler man så som Scrum Master/Agil coach/ekstern konsulent den potentielle konflikt?
Min strategi er simpel. Lyt og vær til nytte – det opbygger tillid, som er det bedste fundament for rent faktisk at skabe positiv forandring. Det er bare ikke produktivt at komme ind i en fremmed organisation med en bedrevidende indstilling og en færdig opskrift på hvordan de forbedrer sig. En færdig opskrift er nok desværre nemmere at sælge til ledelsen, da de så ved hvad de køber, men one-size-fits-all vil næsten sikkert møde modstand i alle udviklingsteams, som har brug for at forstå, hvorfor de gør ting. Deres logik vil ikke acceptere et svar som “sådan er det bare” eller “sådan plejer vi at gøre”.
At opbygge tillid er ikke en nem ting. At stå udenfor teamet med et mandat til at ændre hverdagen, skaber nemt en os-og-dem stemning i stedet for samarbejde.
For at skabe tilliden som grobund for et samarbejde, har jeg disse små råd til den eksterne som skal samarbejde med et team:
– vær klar i spyttet omkring formål med din tilstedeværelse
– beskriv det fælles mål og bed om hjælp til at opnå det
– lyt
– vær til nytte
– forsøg at identificere “teamets historie”og bekræft den med teamet
– forsøg at identificere organisationens historie om teamet og bekræft den med ledelsen
– vær teamets forkæmper i organisationen
– forsøg at komme til en indsigt som teamet ikke selv kan se
De to første kan lyde ret ens, men hvis man for eksempel kommer ind som agil coach, så har man ofte et formål som spænder over en større del af organisationen. Det fælles mål jeg henviser til i punkt to er til gengæld den del af ens formål, som specifikt angår det team, man skal samarbejde med. Det er min erfaring at det hjælper at bede om hjælp – det gør det tydeligt at man søger et samarbejde og ikke er der for at diktere vejen til målet.
“Lyt” kræver næppe mere forklaring, men at være “til nytte” er mere uhåndgribeligt. Lad os sige at man kommer ind i et team, hvor der især er stort pres på produkt-ejeren (PO). Samarbejdet med en ekstern gruppe sejler og der er alt for meget at se til. En hurtig hjælp er at deltage i møder med denne eksterne gruppe og arbejde på at forbedre dette samarbejde – hvad enten det er ved at støtte produkt-ejeren i mødet, tage ansvar for en konkret opgave eller såmænd bare at tage gode noter og lave en opsummering sammen med produkt-ejeren efter mødet. Hvad der end hjælper i hverdagen. Påtag et ansvar og lav en forbedring, hvorend lille den måtte være. Hjælp til.
At identificere “teamets historie” handler om at finde ud af hvad teamets selvfølelse er. Hvilke små historier fortæller teamet om sig selv. Er de support-teamet som overbebyrdes af andre teams, så andre teams kan vise hurtig fremgang? Er de guld-teamet som andre ser op til og kommer efter hjælp hos? Er de et glemt team, som ignoreres af ledelsen? Er de dem der leverer til tiden hver gang? Er de dem der altid er for optimistiske og aldrig leverer til tiden? Er de et team med store interne konflikter? Er det et presset team som tager mange short-cuts? Efter at have lyttet til et team i et stykke tid, kan man godt tro at man har styr på historien, men når man nævner det for team-medlemmer, kan de ikke genkende det man siger. Det kan give nogle produktive og hårde diskussioner at forelægge de ting man har samlet op omkring teamets historie for teamet selv.
På samme måde kan organisationens opfattelse af teamet være brugbar at kende. Er det et dovent team? Er det et pålideligt team? Er det teamet vi altid går til, når tingene brænder på? Er det et uundværligt team? Er det et team vi ikke stoler på? Er det det team der oftest er på tværs? Er det et team der tager ansvar også udenfor deres eget domæne? Er det et team der er svært at samarbejde med? Er det et team der overleverer dårlig kode? Er det et team som andre lærer af?
At sammenholde organisationens opfattelse med teamets selvopfattelse kan ofte give noget indsigt i de dynamikker der er i spil. Det er ikke altid brugbart at forelægge organisationens opfattelse om teamet for teamet selv, men det kan give nogle gode diskussioner.
Det sidste punkt er at få en indsigt som teamet/organisationen ikke selv har. Det er naturligvis ikke simpelt, men man har det bedste udgangspunkt for det, som udefrakommende der ikke er begravet i hverdagens pligter. Ens egen erfaring fra andre organisationer kan være meget brugbar her, såvel som historier om hvad andre gør og best practices. Her kan man grave sig lidt ned i nogle detaljer. Er der f.eks. styr på release-proceduren? Tages der ansvar for produktet på teamet? Har teammedlemmerne et godt samarbejde med produktejeren? Er der indbyggede konflikter i den måde rollefordelingen er sat op? Er alle de nødvendige kompetencer til stedet på teamet? Er der uhensigtsmæssige omstændigheder udenfor teamets kontrol som presser teamet? Leveres der god kode? Er der gode vaner omkring test- og produktions-miljøer? Er teamet stolte af deres arbejde? Er der plads til læring? Er der styr på test og kvalitet? Er der konkrete konflikter mellem team-medlemmer, som skal løses? Støtter ledelsen teamet i en passende grad? Er teamets formål klart? Er der konkrete værktøjer som teamet mangler? Leveres det rigtige? Det er ikke sikkert at teamet/organisationen selv har fokus på disse ting og der kan man som udefrakommende være med til at rette spotlyset på (og indsamle data om) nogle ting der kan hjælpe.
Alt dette er råd set med en udefrakommendes øjne, men hvordan det bliver modtaget af teamet er mindst lige så vigtigt for succes. Hvis man er udvikler som skal samarbejde med en Scrum master eller en agil coach om at få de bedste team-vilkår, så er åbenhed og tillid så absolut det vigtigste. Hvis ikke man har det fra starten, så overvej, hvordan man kan skabe det. Hjælp coachen med at hjælpe jer og vær åben for andres erfaringer.
En del udviklere synes det er spild af tid at tage fokus væk fra produktet og bruge tid på at forbedre vores teams og den måde vi arbejder på, og det er da heller ikke altid lige produktiv tid. Den indstilling kan bare godt føre til at man helt forsømmer at træde et skridt tilbage og få overblikket – et overblik som kunne have sparet mange senere frustrationer. Det bedste råd, hvis man har den følelse er at forsøge at optimere den tid man bruger på at samarbejde med coachen, så der ikke er så meget spildtid… og så huske at man er en del af et team og det kræver at man investerer i de andre team-medlemmer. Vi arbejder med begreber som teknisk gæld, men vi har ikke et ord for den gæld vi opbygger ved at forsømme vores teamdynamik og optimering af vores arbejdsgange – og den gæld kan lige så godt være grunden til manglende fremtidig fremdrift som teknisk gæld.
Teknisk gæld håndteres ved at have disciplin omkring det – det samme kan siges om team-gæld.