Scrum Guide | 39. De mest almindelige fejl under en Sprint Retrospektiv

Sprint Retrospektiv er den begivenhed, der afslutter hver Sprint. Og samtidig en af de sværeste Scrum Team-møder. De mest almindelige fejl under en Sprint Retrospektiv involverer at undgå samtaler om følsomme emner, samt manglen på konkrete forpligtelser, der fører til løsning af allerede diagnosticerede problemer.

Almindelige fejl under en Sprint Retrospektiv – indholdsfortegnelse:

1. Introduktion
2. Utilstrækkelig gennemsigtighed
3. Fokus på engangsproblemer eller succeser
4. Overrepræsentation af Product Owner
5. Selvledelsesproblemer
6. For mange forpligtelser
7. Almindelige fejl under en Sprint Retrospektiv – Resumé

Introduktion

Fejl under en Sprint Retrospektiv er desværre meget almindelige. Dette skyldes, at det er et af de sværeste møder at gennemføre med succes, da det kræver meget modenhed fra teamet. Derfor er det værd at se på de problemer, der oftest opstår i andre teams, så du lettere kan spotte deres symptomer, når du gennemfører Sprint Retrospektiv i dit Scrum Team.

Utilstrækkelig gennemsigtighed

Ifølge Scrum Guiden er hvert medlem af Scrum Team forpligtet til at være ærlig og modig i at udtrykke bekymringer og at give deres mening til kende under Sprint Retrospektiv. Men i praksis er forpligtelsen til gennemsigtighed meget krævende. På grund af dette forsøger medlemmerne af Scrum Team ofte at omgå det.

Et problem, der er svært at spotte og løse, er at undgå diskussion af observerede mangler i Scrum Teamets arbejde. Dette kan føre til meget mere alvorlige problemer på lang sigt.

Scrum Masterens opgave er derfor at holde nøje øje med situationen i teamet og opfordre alle teammedlemmer til at være proaktive fra starten af Sprint Retrospektiv.

Fokus på engangsproblemer eller succeser

Et andet problem, der kan opstå under Sprint Retrospektiv, er utilstrækkelig opmærksomhed på cykliske og gentagne teamadfærd, og deres indvirkning på teamets effektivitet.

Det er altid godt at lykønske Scrum Team-medlemmer, hvis de har opnået en ekstraordinær succes. Men Sprint Review bør ikke dedikeres til at fejre det. Det samme gælder for fejl. Hvis noget mislykkedes på grund af tilfældige årsager eller en allerede diagnosticeret fejl, er det ikke værd at overanalysere hændelsen under Sprint Review.

Nogle gange bruger teamet dog en stor del af Sprint Retrospektiv på sådanne begivenheder. Husk dog, at formålet med Sprint Retrospektiv er at søge efter måder at forbedre teamets daglige arbejde. Derfor bør mødet ikke dreje sig om engangs succeser eller problemer, der højst sandsynligt ikke vil ske igen.

Overrepræsentation af Product Owner

I mange organisationer ligestilles stillingen som Product Owner med den som Product Manager. Product Owner betragtes ofte som tilsynsførende for Scrum Teamet. Af denne grund sker det, at udviklingsteamet ikke ønsker at tale om samarbejdsproblemer i hans eller hendes tilstedeværelse.

Derfor er det så vigtigt at opbygge gensidig tillid mellem udviklingsteamet og Product Owner. Desværre er processen med at opbygge tillid vanskelig og langvarig. Derfor er det nogle gange en god idé for Product Owner at give afkald på deltagelse i hele eller dele af Sprint Retrospektiv for at give plads til, at resten af teamet kan diskutere frit.

Selvledelsesproblemer

Selvledelse betyder, at medlemmerne af Scrum Team træffer deres egne beslutninger om, hvem blandt dem der vil udføre bestemte opgaver, hvornår og hvordan. Under Sprint Retrospektiv diskuterer teamet mennesker, deres interaktioner samt teampraksis. Det beslutter derefter, hvilke problemer der skal løses i den kommende Sprint, hvordan det skal gøres sammen med hvem der vil bære ansvaret for at tage handling.

Hvis der opstår mere alvorlige problemer i et selvledende team, kan der være en fristelse i Scrum Teamet til at fraskrive sig ansvaret.

Af og til ønsker teammedlemmer ikke at deltage i diskussionen og forsøger at skubbe ledelsesansvaret over på nogen andre. For at forhindre dette er det ekstremt vigtigt at diskoere selv små problemer regelmæssigt for at forhindre deres ophobning.

For mange forpligtelser

Et aktivt Scrum Team, der arbejder efter de tre søjler af empirisme: gennemsigtighed, inspektion og tilpasning, kan støde på problemet med at lave for mange forpligtelser på én gang.

Hvis de forpligtelser, der er lavet af Scrum Team under en Sprint Retrospektiv, er for mange, er der en betydelig risiko for, at:

• ingen af forpligtelserne vil blive gennemført ordentligt
• nogle forpligtelser ikke vil blive gennemført overhovedet
• de ændringer, der er foretaget, ikke vil være permanente

Derfor er en god praksis at påtage sig ikke mere end fire forbedringer i hver Sprint. Dette muliggør en gradvis, men effektiv forbedring af teamets præstation.

Almindelige fejl under en Sprint Retrospektiv – Resumé

Da Sprint Retrospektiv er en udfordrende begivenhed, opstår der ofte problemer under dens gennemførelse. For at håndtere dem lettere er det værd at bemærke dem, der opstår oftest. Almindelige fejl under en Sprint Retrospektiv er:

• utilstrækkelig gennemsigtighed – når medlemmerne af Scrum Team ikke formår at håndtere ærlighed i mere vanskelige teamsituationer
• fokus på engangsproblemer eller succeser – når medlemmerne af Scrum Team fokuserer på at diskutere succeser og fejl i stedet for at diskutere den langsigtede effektivitet af teamets arbejde
• overrepræsentation af Product Owner – når medlemmerne af Scrum Team behandler Product Owner med begrænset tillid, som om han eller hun var nogen uden for teamet eller en tilsynsførende
• selvledelsesproblemer – når medlemmerne af Scrum Team forsøger at skubbe ansvaret for problemer og beslutningstagning.

Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.