Ghid Scrum | 39. Cele mai frecvente greșeli în timpul unei retrospective de sprint

Publicat: 2022-07-20

Sprint Retrospective este evenimentul care încheie fiecare Sprint. Și, în același timp, una dintre cele mai dificile întâlniri ale echipei Scrum. Cele mai frecvente greșeli în timpul unei Retrospective Sprint implică evitarea conversațiilor despre probleme sensibile, precum și lipsa angajamentelor concrete care să conducă la rezolvarea problemelor deja diagnosticate.

Greșeli frecvente în timpul unei retrospective Sprint – cuprins:

  1. Introducere
  2. Transparență insuficientă
  3. Concentrați-vă pe probleme sau succese unice
  4. Suprareprezentare a Product Ownerului
  5. Probleme de autogestionare
  6. Prea multe angajamente
  7. Greșeli frecvente în timpul unei retrospective Sprint – Rezumat

Introducere

Greșelile în timpul unei retrospective Sprint sunt, din păcate, foarte frecvente. Acest lucru se datorează faptului că este una dintre cele mai dificile întâlniri de executat cu succes, deoarece necesită multă maturitate din partea echipei. De aceea, merită să aruncați o privire asupra problemelor care apar cel mai des în alte echipe, astfel încât să puteți identifica mai ușor simptomele acestora atunci când desfășurați Sprint Retrospective în echipa dvs. Scrum.

Common mistakes during a Sprint Retrospective

Transparență insuficientă

Conform Ghidului Scrum, fiecare membru al echipei Scrum este obligat să fie onest și îndrăzneț în exprimarea preocupărilor și să își exprime opinia în timpul Retrospectivei Sprint. Cu toate acestea, în practică, angajamentul față de transparență este foarte solicitant. Din această cauză, membrii echipei Scrum încearcă adesea să o ocolească.

O problemă care este greu de identificat și rezolvat este evitarea discuțiilor despre deficiențele observate în activitatea echipei Scrum. Acest lucru poate duce la probleme mult mai grave pe termen lung.

Prin urmare, sarcina Scrum Master este să urmărească îndeaproape situația din echipă și să încurajeze toți membrii echipei să fie proactivi încă de la începutul Retrospectivei Sprint.

Concentrați-vă pe probleme sau succese unice

O altă problemă care poate apărea în timpul Sprint Retrospective este acordarea unei atenții insuficiente comportamentelor ciclice și repetitive ale echipei și impactul acestora asupra eficienței echipei.

Este întotdeauna bine să felicităm membrii echipei Scrum dacă au obținut un succes excepțional. Cu toate acestea, Sprint Review nu ar trebui să fie dedicat sărbătoririi acestuia. Același lucru este valabil și pentru eșecuri. Dacă ceva a eșuat din motive fortuite sau dintr-o eroare deja diagnosticată, nu merită să supraanalizați evenimentul în timpul Sprint Review.

Uneori, însă, echipa dedică o mare parte din Retrospectiva Sprint unor astfel de evenimente. Rețineți totuși că scopul Sprint Retrospective este de a căuta modalități de a îmbunătăți munca zilnică a echipei. Prin urmare, întâlnirea nu ar trebui să se învârte în jurul succeselor unice sau a problemelor care este foarte probabil să nu se repete.

Suprareprezentare a Product Ownerului

În multe organizații, poziția de Product Owner este echivalată cu cea de Product Manager. Product Owner este atunci adesea considerat supervizorul echipei Scrum. Din acest motiv, se întâmplă ca Echipa de Dezvoltare să nu dorească să vorbească despre probleme de lucru în echipă în prezența sa.

De aceea este atât de important să construim încredere reciprocă între echipa de dezvoltare și proprietarul produsului. Din păcate, procesul de construire a încrederii este dificil și lung. De aceea, uneori, este o idee bună ca Product Owner să renunțe la participarea la tot sau la o parte a Sprint Retrospective pentru a lăsa spațiu pentru ca restul echipei să discute liber.

Probleme de autogestionare

Autogestionarea înseamnă că membrii echipei Scrum iau propriile decizii cu privire la cine dintre ei va îndeplini anumite sarcini, când și cum. În timpul Sprint Retrospective, echipa discută despre oameni, despre interacțiunile lor, precum și despre practicile echipei. Apoi decide ce probleme trebuie rezolvate în viitorul Sprint, cum să o facă împreună cu cine va purta responsabilitatea pentru a lua măsuri.

Dacă apar probleme mai serioase într-o echipă autogestionată, poate exista o tentație în echipa Scrum de a abdica de la responsabilitate.

Ocazional, membrii echipei nu doresc să ia parte la discuție și încearcă să împingă responsabilitatea managementului asupra altcuiva. Pentru a preveni acest lucru, este extrem de important să discutăm în mod regulat chiar și despre problemele mici pentru a preveni acumularea acestora.

 Most common mistakes during a Sprint Retrospective

Prea multe angajamente

O echipă Scrum activă care funcționează după cei trei piloni ai empirismului : transparență, inspecție și adaptare, poate întâmpina problema de a lua prea multe angajamente simultan.

Dacă angajamentele luate de echipa Scrum în timpul unei retrospective de sprint sunt prea multe, există un risc considerabil ca:

  • niciunul dintre angajamente nu va fi implementat în mod corespunzător
  • unele angajamente nu vor fi implementate deloc
  • modificările efectuate nu vor fi permanente

Prin urmare, o bună practică este să nu întreprindeți mai mult de patru îmbunătățiri în fiecare Sprint. Acest lucru permite o îmbunătățire treptată, dar eficientă a performanței echipei.

Greșeli frecvente în timpul unei retrospective Sprint – Rezumat

Deoarece Sprint Retrospective este un eveniment provocator, adesea apar probleme în timpul desfășurării acestuia. Pentru a le trata mai ușor, merită remarcate cele care apar cel mai des. Greșelile frecvente în timpul unei retrospective Sprint sunt:

  • transparență insuficientă – atunci când membrii echipei Scrum nu reușesc să se ocupe de onestitate în situații mai dificile ale echipei
  • concentrați-vă pe probleme sau succese unice - atunci când membrii echipei Scrum se concentrează pe discutarea succeselor și eșecurilor, în loc să discute eficacitatea pe termen lung a muncii echipei
  • Suprareprezentare a Product Ownerului – atunci când membrii echipei Scrum îl tratează pe Product Owner cu încredere limitată ca și cum ar fi cineva din afara echipei sau un supervizor
  • probleme de autogestionare – când membrii echipei Scrum încearcă să-și schimbe responsabilitatea pentru probleme și luarea deciziilor.

Dacă vă place conținutul nostru, alăturați-vă comunității noastre de albine ocupate pe Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 39. Most common mistakes during a Sprint Retrospective caroline becker avatar 1background

Autor: Caroline Becker

În calitate de manager de proiect, Caroline este expertă în găsirea de noi metode de a proiecta cele mai bune fluxuri de lucru și de a optimiza procesele. Abilitățile ei de organizare și capacitatea de a lucra sub presiunea timpului o fac cea mai bună persoană pentru a transforma proiectele complicate în realitate.

Ghid Scrum:

  1. Glosar de termeni de bază, roluri și noțiuni
  2. Ce este Scrum?
  3. Valorile Scrum
  4. Cum implementezi Scrum în compania ta?
  5. Echipa Scrum - ce este și cum funcționează?
  6. Cine este un proprietar de produs?
  7. Cele mai frecvente greșeli ale Product Ownerului
  8. Cine este Scrum Master?
  9. Caracteristicile unui bun Scrum Master
  10. Cele mai frecvente greșeli ale Scrum Master
  11. Ce statistici și valori ar trebui să urmărească Scrum Master?
  12. Cooperare între Product Owner și Scrum Master
  13. Echipa de dezvoltare în Scrum
  14. Cele mai frecvente greșeli ale dezvoltatorilor
  15. Artefacte Scrum
  16. Scaling Scrum
  17. Sprint Backlog
  18. Ce este Product Backlog?
  19. Ce sunt User Stories?
  20. Crearea celei mai bune povești de utilizator cu INVEST
  21. Cele mai frecvente greșeli ale User Story
  22. Criterii de acceptare a poveștii utilizatorului
  23. Estimare și Story Points în Scrum
  24. Planificarea Pokerului
  25. Joc de estimare a echipei
  26. Definirea creșterii
  27. Evenimente Scrum
  28. Ce este Sprint în Scrum?
  29. Angajamentele echipei Scrum - Obiectiv de produs, obiectiv de sprint și definiția finalizării
  30. Ce este un grafic Burndown?
  31. Cum se creează și se interpretează un grafic de ardere?
  32. Avantajele și dezavantajele diagramei de ardere
  33. Panouri Kanban în Scrum și Scrumban
  34. Viteza în Scrum - Viteza echipei de dezvoltare
  35. Scrum zilnic
  36. Planificarea sprintului
  37. Sprint Review
  38. Ce este o retrospectivă Sprint?
  39. Greșeli frecvente în timpul unei retrospective de sprint
  40. Creșterea backlog-ului de produse