Cum faci o retrospectivă de sprint care chiar schimbă ceva?
Retrospectiva utilă produce maxim 2 acțiuni concrete cu owner, deadline și definiție de "done" — și verifică la următorul retro ce s-a întâmplat cu acțiunile din precedent. Fără follow-through, retro e doar terapie.
Cele mai multe retrospective de sprint sunt rituale moarte. Echipa enumeră 20 de probleme, scrie "să comunicăm mai bine", toată lumea pleacă, peste 2 săptămâni reapare aceeași listă. O retro utilă produce acțiuni concrete și verifică follow-through — altfel devine doar oră de plâns colectiv.
1. Începe cu verificarea acțiunilor anterioare
Primul punct pe agendă: ce s-a întâmplat cu acțiunile din retro precedent? Fiecare acțiune are status: Done, In Progress, Dropped (cu motiv). Asta semnalează imediat dacă retro produce sau nu rezultate.
Dacă 80% din acțiunile precedente n-au mers nicăieri, oprește retro și discută: de ce nu am livrat? Lipsa de timp? Acțiuni prost definite? Lipsa de buy-in al management-ului? Rezolvă cauza, nu mai produce alte acțiuni.
2. Format clar, fără brainstorm liber
Format clasic "Start / Stop / Continue" sau "Glad / Sad / Mad" funcționează. Brainstorm liber ("ce vă deranjează?") fără structură eșuează — fie nimeni nu vorbește, fie cei vocali domină, fie discuția se duce într-un tunel pe o singură problemă.
Schimbă formatul ocazional pentru a evita ritualizarea. La fiecare 3-4 sprinturi, încearcă "Sailboat" (vânt = ce ne propulsează, ancore = ce ne ține înapoi) sau "4Ls" (Liked / Learned / Lacked / Longed for). Format nou = perspective noi.
3. Maxim 2 acțiuni concrete per retro
O echipă nu poate îmbunătăți 10 lucruri simultan. Alege maxim 2 acțiuni, fiecare cu: owner clar (o persoană, nu "echipa"), deadline (data exactă, nu "în curând"), definiție de "done" (cum știm că s-a întâmplat).
Exemplu prost: "Comunicăm mai bine în sprint." Exemplu bun: "Maria implementează status update zilnic pe Slack la 17:00, începând de luni, verificăm la următorul retro dacă echipa simte că ajută." Concret, ownership, deadline, criteriu de succes.
4. Concentrat pe sistem, nu pe persoane
"X a livrat târziu" e ineficient. "Sprintul a livrat târziu pentru că dependența între task-urile A și B nu era clară la planning" e actionable. Atacă procesul, nu individul.
Excepția: dacă apar tipare repetate de comportament problematic, conversația trebuie purtată — dar 1-on-1, nu în retro. Retro nu e locul de evaluare individuală. Folosește feedback direct sau performance reviews pentru asta.
5. Safety psihologică — fără ea retro e teatru
Dacă echipa nu se simte safe să spună "scope-ul ăsta a fost nerealist", retro produce doar lucruri inofensive. Dacă PM-ul sau tech lead-ul reacționează defensiv la critică, echipa învață rapid să-și înghită feedback-ul.
Facilitatorul retro (Scrum Master sau rotativ) are rolul explicit să creeze spațiul. Anonim brainstorming în primele 5 min, regula "nu interuptam când cineva vorbește", absența management-ului din retro tehnic — toate acestea contribuie. Fără safety, retro e doar bifa unei ceremonii.
Retro cu follow-through în 4myprojects
Retro board nativ cu Start/Stop/Continue, acțiuni cu owner și deadline atașate la sprintul următor, verificare automată la următorul retro — și AI care îți spune ce tipare ai discutat de 3 retros la rând fără să rezolvi.