by De cand am început sa lucrez într-o abordare agile, retrospectivele mi s-au părut printre cele mai greu de facilitat evenimente, indiferent ca au fost retrospective de iterație, de release sau anuale. Adeseori, am avut sentimentul că nu reușesc să facilitez retrospectivele într-un mod care să ajute echipele, care să fie antrenant și să nu plictisească, deopotriva.
De multe ori, deși s-a explicat care este scopul unei retrospective și care trebuie sa fie rezultatul acestei ceremonii, echipele își pierd interesul pe parcurs și nu mai oferă informațiile necesare și pentru a stabili pașii următori pentru îmbunătățirea și învățarea continuă. Nu pentru că nu își doresc neapărat, dar retrospectivele adeseori sunt privite ca niște sedinte plictisitoare si nu toti membri unei echipe sunt dispusi sa se deschidă și să își expună opiniile și ideile.
Zilele trecute m-am gandit la ce s-a intamplat în echipa din care fac parte în ultimul an și ceva. Ne-au ajutat sau nu retrospectivele? Ce am făcut bine și ce nu? De-a lungul timpului am avut de multe ori senzația ca nu progresam, ca nu invatam din greselile trecutului si ca batem pasul pe loc pe diferite subiecte discutate în retrospective. Și, cu toate acestea, privind în retrospectivă, mi-am dat seama ca nu este chiar așa, ca am făcut progrese majore, că am învățat multe lucruri și că avem anumite acțiuni în derulare, toate reiesite din retrospectivele susținute.
Si atunci? Unde este problema mea? Probabil ca este vorba strict de o percepție personală: micile îmbunătățiri, care se intampla pe perioada unei iterații ajung sa fie o obisnuinta si tinzi să uiți că, la un moment dat, au fost propuneri de îmbunătățire în retrospective.
Iar marile schimbări, care necesita modificări de procese, de moduri de livrare, cu impact asupra echipelor, etc, au o durata de implementare mai lungă, mai multe acțiuni de realizat, și trec persoanele implicate prin procesul Kübler-Ross (curba schimbării – mai multe informații aici)
În concluzie, mi-am dat seama că am reușit, în ciuda senzației mele inițiale, să aducem foarte multe îmbunătățiri în urma ideilor discutate în retrospective. Cateva exemple concrete:
- am îmbunătățit productivitatea, prin adaugarea de unit teste și mai multe teste automate, scazand astfel necesitatea de reface sau rescrie cod.
- am îmbunătățit capabilitatea membrilor echipei, prin faptul ca pentru functionalitatile mari, nu a mai existat o singura persoana care știe detaliile, ceea ce conducea la blocaje, ne-am organizat astfel incat sa existe minim 2 persoane care sa poată oferi informații în caz de necesitate.
- am îmbunătățit calitatea livrării, printr-un management al cerințelor mult mai riguros și printr-o comunicare mai buna între business și tehnic. Cerințele și detaliile necesare sunt mult mai bine analizate și rafinate, și ne asigurăm ca sunt îndeplinite DoR și DoD înainte de a duce o functionalitate în producție.
- am îmbunătățit capacitatea de livrare prin modificări aduse modului de lucru, prin implementarea de bune practici agile, reușind sa mărim numărul de release-uri în producție semnificativ, aducand astfel clientului valoare de business mai rapid.
Hmm, se pare ca pana la urma nu am făcut o treaba chiar așa de rea, cum am crezut inițial, inclusiv retrospectivele s-au îmbunătățit față de momentul în care am intrat în proiect. Am aplicat diverse moduri de facilitare, am utilizat activități diverse pentru a mari gradul de implicare al oamenilor atunci cand am simțit ca este nevoie, am utilizat unelte online specifice, pe scurt, am diversificat. Și, iată că, deși poate nu mereu am conștientizat, ne-am îmbunătățit continuu, și ne propunem sa o facem în continuare. Pentru ca, nu-i asa?, continuous improvement și continuous learning 🙂
Sa ne auzim cu bine!
Manolo
PS. Acest post este inspirat de lectura cartii “Agile Retrospectives – Making Good Teams Great” scrisa de Esther Derby si Diana Larsen.
