by De ce pandemia mi-a aratat ca putem avea 2 Scrum Masteri intr-o echipa Scrum
Orice ti s-ar spune in compania ta, oriunde ai cauta pe internet, orice carte ai citi despre Scrum si echipe de Scrum, vei gasi o regula pe care nimeni nu o incalca: o echipa de Scrum trebuie sa aiba un Scrum Master, mereu la datorie. Intrebarea pe care mi-o pun insistent de cand coordonez echipe exclusiv remote este daca nu cumva a venit timpul pentru un Scrum 2.0: epoca in care in acelasi proiect exista 2 Scrum Masteri.
Gandeste-te putin: in contextul pandemiei, am ajuns sa lucram cu totii exclusiv online. Echipele full-time remote devin din ce in ce mai dificil de gestionat de catre o singura persoana, mai ales atunci cand vorbim de mai mult de 8-9 membri.
Problemele care apar sunt diverse si sunt convins ca te-ai lovit si tu de cel putin una dintre ele in ultimele luni: de la comunicarea incompleta la conexiuni la internet care cedeaza chiar inainte sa intri in call, sedinte care se suprapun atunci cand lucrezi simultan la mai multe proiecte sau – deloc de neglijat – presiunea psihica, fie ca tine de dificultatile socio-profesionale aduse de pandemie, fie de practica call-urilor interminabile.
Beneficiile aduse de 2 Scrum Masteri la o echipa de proiect de mari dimensiuni ar fi considerabile. Sunt un mare fan al metodologiei Scrum si desi in general imi place sa respect procedurile, cred ca uneori e cazul sa le schimbam pentru a ne face vietile profesionale mai usoare.
In cele ce urmeaza, iti voi povesti cum am ajuns sa ma gandesc la un Scrum mai eficient ce poate fi implementat pe scara larga, pornind de la o solutie de moment, si iti voi prezenta plusurile si minusurile, astfel incat si tu sa poti face saltul catre Scrum 2.0 atunci cand consideri ca e nevoie.
Un model nou, testat pe propria-mi piele
In ceea ce priveste gestionarea de proiecte, compania in care lucrez se afla intr-o perioada de tranzitie de la metodologia Waterfall la Agile. Ei bine, in urma cu cateva luni am fost invitat sa preiau rolul de Scrum Master intr-o echipa deja formata.
Era pentru prima data cand intram intr-o echipa de Scrum in care nu fusesem membru de la inceput. Fostul Scrum Master trebuia sa intre rapid intr-un alt proiect si nu am reusit sa avem suficiente sedinte de predare. Echipa pe care urma sa o coordonez era una matura, cu aproape 2 ani vechime, formata din programatori foarte implicati, care livrau intr-un ritm si cu o viteza bune pentru mai multe proiecte interne, precum si pentru alti clienti externi companiei. Backlog-ul era foarte mare, hranit constant de catre Product Owner cu cerinte din intern sau extern.
Din acest moment au inceput sa apara provocarile pentru rolul meu de Scrum Master. Echipa cea noua incalca orice regula de bun-simt a metodologiei pe care trebuia sa o aplic:
- Dimensiune mult prea mare
Prima surpriza am avut-o cand am aflat ca echipa va fi formata din 22 de oameni – incluzand 1 Scrum Master, 1 Product Owner, 3 QA, 1 Dev Lead si 16 Developeri. Cum stim cu totii, framework-ul Scrum spune ca echipele de Scrum trebuie sa fie aiba intre 3 si 9 oameni.
- O echipa hibrid
A doua surpriza a fost cand am aflat ca nu este o echipa pur Scrum ci mai curand o echipa Dev/Ops sau Hybrid Scrum/DevOps. Echipa nu era implicata numai in dezvoltare si testare. O alta sarcina importanta o reprezenta suportul oferit echipelor de Ops pentru deployment support in productie.
- Sprinturi prea aglomerate
A treia surpriza a venit cand am descoperit, uitandu-ma pe graficele sprinturilor anterioare, volumul de foarte mare de story points pe care echipa isi asuma intr-un sprint de 2 saptamani, cu mult mai mare decat valorile recomandate. In mod cu totul neasteptat, numarul real de story points pe care reuseau sa-l livreze in final era apropiat de valoarea asumata, o valoare impresionanta la randul ei.
Cu toate astea, performanta echipei era una ridicata, nivelul de implicare la fel de ridicat, echipa fiind uneori dispusa sa lucreze ore suplimentare sau in weekend.
Am aflat si directia pe care cei din Management si-o doreau pentru echipa: voiau sa o sparga in doua echipe mai mici, care urma sa se intalneasca la fiecare 3 luni intr-un PI planning complex, prioritizat in backlog comun.
Cum vom face asta? era intrebarea pe care mi-o puneam. Doua echipe de Scrum inseamna doi Scrum Masteri. In plus, nu poti sa rupi o echipa in doua aleatoriu, ca atunci cand imparti jucatorii in doua echipe de fotbal din curtea scolii. Ar fi fost nevoie de o perioada de tranzitie in formula completa in care sa aducem un al doilea Scrum Master. Calculul initial ne arata ca dupa maxim 2-3 sprinturi urma sa facem impartirea si in maxim 6 saptamani cele doua echipe vor fi finalizate.
Usor de spus, greu de facut. Tranzitia s-a suprapus cu vacanta de vara din August. Am avut o parte din echipa in concediu de odihna, dupa care in timp ce unii colegi se intorceau, altii plecau. Am evitat sa facem impartirea in absenta cuiva. Astfel, planul initial de 6 saptamani s-a intins in final pe 16 saptamani, o durata de aproape trei ori mai mare decat cea planificata initial. In tot acest timp, echipa a functionat cu 2 Scrum Masteri. Asta se traduce in 8 sprinturi, 16 pre-sprint plannings, 8 sprint plannings si peste 160 DSU (daily stand-up).
Scrum 2.0: Plusuri si minusuri
In mod surprinzator, rezultatul final al “experimentului” nostru a fost peste asteptari, iar mie mi-a schimbat viziunea legata de cum putem adapta metodologia in astfel de situatii. Voi face o lista de plusuri si minusuri pe care le-am observat pana acum:
- Management mai eficient
Echipa a avut doi Scrum Masteri dedicati care au putut sa gestioneze toate problemele zilnice dintr-o activitate normala (BAU challenges);
Fiind vorba de o echipa mare, de 22 de colegi, sansa aparitiei de probleme de diferite naturi era ridicata. O parte din echipa era formata din contractori externi pusi la dispozitie de un vendor partener. In aceeasi perioada de timp, 3 membri au parasite echipa si alti 3 au venit in locul lor. Am avut de gestionat diverse situatii pentru creare de noi useri, drepturi de acces pe diverse platforme interne precum Jira/Confluence;
- Back-up pentru DSU (daily stand up)
Avand 2 Scrum Masters, am avut posibilitatea sa facem cu schimbul sustinerea DSU-urilor. Cand unul dintre nou nu era disponibil, celalalt i-a putut tine locul. Intr-o situatie normala de mers la birou zilnic sau aproape zilnic, aceasta problema nu ar aparea. Dar lucrand intr-un mediu full WFH, in timpul unei pandemii, cu situatii neasteptate in care poti ramane fara conexiune la internet, urgente in familie atat pentru cei care au copii mici cat si pentru cei care nu au, faptul ca am avut in echipa 2 SM a fost o adevarata gura de oxigen. Cu toate ca echipele de Scrum ajung sa fie la un moment dat self-managed, un DSU in care zilnic participa un Scrum Master ajuta pentru ca discutiile sunt directe si nu off-line.
Atat eu, cat si celalalt SM, aveam si alte proiecte pe care le gestionam in acelasi timp, si atunci a fost foarte util faptul ca macar unul dintre noi a putut sa fie prezent la DSU.
- Suport reciproc in timpul sedintelor de pre-planning si sprint planning;
Sedintele de pre-planning si sprint planning pot sa fie foarte obositoare. Cateva ore bune, in cateva zile consecutive, in care se discuta si se analizeaza impreuna cu echipa scopul pe sprintul urmator. Faptul ca poti sa faci schimb cu un coleg este de mare ajutor; Ca bonus, la fel ai pe cine sa lasi in locul tau in timpul concediilor; Un coleg SM te poate ajuta foarte mult pentru ca iti ofera sansa sa ai cu cine sa te consulti si sa intelegi mai repede despre ce e vorba in proiect. Nu este deloc usor sa pornesti intr-o echipa deja formata peste 1,5 ani de lucrat impreuna, sa intelegi obiectivele, personalitatea membrilor echipei, problemele si riscurile prezente, stakeholderii proiectului, etc.
Ca minus, exista sansa sa se amane/uite anumite teme de lucru, pentru ca fiecare SM va astepta de la celalalt sa preia anumite teme – dar asta se poate rezolva usor prin supra-comunicare (over-communication), cuvantul-cheie acum in perioada pandemiei si a full WFH;
Ca nota de final, tin sa precizez ca o echipa de Scrum cu 2 SM nu respecta regulile framework-ului Scrum. Avem practic in fata un Scrum re-interpretat, un Scrum 2.0, pe care il propun oricarui PM care considera ca il poate folosi atunci cand contextul o cere.
Fiecare pas evolutiv a venit impreuna cu incalcarea regulilor existente si cu adaptarea unor obiceiuri utile la modul personal de lucru al fiecaruia. Asa apare inovatia. Iei ceva bun si-l faci mai bun.
Putem sa avem 2 SM intr-o echipa Scrum? Da si nu. Cu siguranta depinde de echipa, de cultura companiei, precum si despre personalitatile celor 2 SM, pentru ca in final, ei sunt cei care trebuie sa lucreze impreuna in beneficiul echipei.
Sunt curios care sunt parerile voastre. Daca ati experimentat ceva asemanator sau sunteti tentati sa incercati, astept comentariile voastre.
