#47 - SCRUM Dos and Don'ts

Pe 29 mai 2025, la American Corner – Biblioteca Astra, am avut plăcerea să-l avem din nou alături de noi pe Paul-Gheorghe Barbu, într-o sesiune practică despre SCRUM: ce funcționează, ce nu, ce adaptări sunt utile și cum putem construi un proces sănătos de dezvoltare software într-un mediu real – nu într-un manual ideal.

Discuția a fost una vie, alimentată de experiențele participanților din diferite roluri: dezvoltatori, product owneri, scrum masteri și manageri. A rezultat o imagine realistă și profundă asupra modului în care SCRUM poate (și trebuie) să fie adaptat la contextul fiecărei echipe.

✅ Dos – Ce ar merita să faci într-o echipă SCRUM

1. Claritate și transparență în backlog

Un backlog bine definit este fundamentul unui sprint reușit. Taskurile trebuie să fie clare, iar cerințele să fie formulate astfel încât dezvoltatorii să știe ce au de făcut fără să „ghicească”. Paul a subliniat cât de important este ca user stories-urile să conțină suficient context: “Nu e suficient să spui ‘vrem autentificare’. E nevoie de detalii funcționale, scenarii, așteptări.”

2. Respectarea cadrelor de lucru (ceremonii SCRUM)

Sprint Planning, Daily Standup, Sprint Review și Retrospective nu sunt opționale și nici simple formalități. Ele creează ritm, oferă vizibilitate și sunt momente de recalibrare. Daily-ul, spre exemplu, nu e locul unde se face debug live – ci o oportunitate de aliniere și identificare rapidă a blocajelor.

3. Implicarea activă a Product Owner-ului

Un PO implicat constant face diferența. Ideal, el trebuie să fie prezent în sprint – chiar dacă nu full-time – și să ofere clarificări rapide. Mai mult, este esențial să fie unică voce decizională pentru produs. Acolo unde există mai mulți “mini-PO”, apar contradicții care creează confuzie și demotivare în echipă.

4. Retrospective autentice și constructive

Retrospectivele sunt oportunități reale de îmbunătățire. Paul a recomandat un format prietenos și vizual, cum ar fi “Sailboat Retro”, pentru a încuraja participarea și onestitatea. Atmosfera contează – echipele se deschid mai ușor când feedback-ul nu e perceput ca reproș, ci ca o cale spre un proces mai bun.

5. Story Introduction Meetings înainte de sprint

Una dintre cele mai valoroase practici descrise a fost organizarea de sesiuni de tip story introduction cu toată echipa, cu câteva zile înainte de începerea sprintului. Astfel, PO-ul, arhitectul și designerii pot clarifica împreună scopul fiecărei funcționalități. Acest pas reduce neclaritățile din timpul sprintului și îmbunătățește calitatea livrabilului.

❌ Don’ts – Ce ar trebui să eviți într-o echipă SCRUM

1. Folosirea SCRUM doar de formă

Faptul că o echipă are sprinturi și face stand-up-uri nu înseamnă automat că aplică SCRUM. Dacă taskurile nu sunt clare, dacă nu există ownership, dacă planificările sunt superficiale sau retrospectivele inexistente, atunci framework-ul nu funcționează. Paul a spus-o clar: “Your SCRUM is not my SCRUM”. Nu copiați un model fără să-l adaptați realității voastre.

2. Modificarea sprint backlog-ului în timpul sprintului

Unul dintre cele mai frecvente derapaje este introducerea de noi taskuri în mijlocul unui sprint. De cele mai multe ori, asta duce la demotivare, livrări incomplete și lipsă de predictibilitate. Dacă apare o urgență reală, se poate interveni, dar regula ar trebui să fie stabilitate și protejarea focusului echipei.

3. Neglijarea definiției clare a “Done”

Lipsa unui “Definition of Done” creează interpretări diferite și, inevitabil, conflicte. Este vital ca echipa să știe clar când un task este considerat finalizat – cu ce teste, validări, documentație sau integrare. Altfel, se pierde timp și apar “surprize” în review-uri sau QA.

4. PO sau stakeholderi multipli, fără ierarhie clară

Când mai mulți stakeholderi trag în direcții diferite, echipa ajunge blocată. Paul a insistat că trebuie să existe un singur PO cu autoritate decizională sau o ierarhie clară, în special când feature-ul afectează mai multe produse.

5. Suprasolicitarea echipelor prin estimări nerealiste

Estimările în story points sunt utile tocmai pentru că reduc presiunea și evită comparațiile directe cu timpul. Totuși, e important ca echipele să nu fie supraîncărcate. Lasă loc pentru neprevăzut (debugging, suport, urgențe) și construiește în timp o predictibilitate realistă pe baza velocității.

SCRUM e un cadru, nu o soluție magică

Dacă ar fi să rămânem cu un singur lucru din discuția cu Paul, acesta ar fi: SCRUM nu este o soluție universală, ci un cadru care evidențiază problemele existente. El nu le rezolvă automat, dar oferă echipei instrumentele necesare să le vadă și să le abordeze împreună.

Paul ne-a oferit o privire sinceră asupra modului în care echipa lui implementează SCRUM într-un context complex, cu hardware, firmware și software care trebuie să colaboreze. A vorbit despre ce funcționează, ce s-a schimbat în timp, cum folosesc story introductions, template-uri în Confluence, planning poker cu Fibonacci și mai ales, cum prioritizează comunicarea și adaptarea.

Este important să înțelegem că fiecare echipă va avea propria versiune de SCRUM, iar cheia succesului este să o modelezi în jurul oamenilor și nevoilor reale. Procesul nu trebuie să fie rigid, ci clar, documentat, adaptabil și orientat spre produs.

În final, SCRUM nu este despre a livra “taskuri”, ci despre a construi produse funcționale, valoroase și cu sens, într-un mod sustenabil, colaborativ și transparent.

🔁 Ai folosit SCRUM într-un mod diferit? Ai provocări similare în echipa ta? Vino să le discutăm la următoarea ediție Sibiu Web Meetup – locul unde comunitatea învață împreună, lunar.