De ce un Scrum Master bun are multe probleme nerezolvate?

Reading Time: 3 minutes

Toti oamenii fac greseli. Si Scrum Masterii sunt pana la urma oameni. Nu vreau sa intelegeti din titlu ca cei care fac bine meseria de Scrum Master gresesc mai des decat ceilalti. Mai degraba ca transparenta reflectata in actiunile, rationamentul si deciziile lor face imposibila eliminarea tuturor problemelor. Ba chiar le evidentiaza si creeaza si alte probleme. Si toata lumea va fi constienta de ele. Dar cunoasterea problemelor nu constituie o vulnerabilitate. Ci un obiectiv pentru Scrum Master.

De la ce poate porni un Scrum Master pentru a deveni “bun”?
Sa luam de pilda ca si ghid de comportament pentru Scrum Master cele 5 valori din Scrum Guide.
Daca pe acestea Scrum Masterul le traieste si le pune in practica si in fata celorlalti zi de zi, a castigat deja jumatate din batalie. Nu asa ati spune?

Cum creeaza totusi cele 5 valori ale Scrum probleme atunci cand sunt adoptate de Scrum Master? Si de ce e bine ca o fac?

Sa le luam pe rand:

Commitment – s-ar traduce prin “angajament”. E vorba despre asumarea individuala, facuta de fiecare dintre membrii echipei, deci si de Scrum Master, ca obiectivele sprintului vor fi indeplinite. Sau mai exact ca fiecare dintre ei va face ceea ce tine de persoana sa pentru a contribui la indeplinirea obiectivelor.
O problema de proces ramasa neclara sau un impediment pe care echipa nu il poate inlatura sunt tipurile de evenimente unde Scrum Masterul arata aceasta asumare, sau “commitment”. Si pentru a le rezolva, mai intai le explica, le expune, le exacerbeaza, pentru a obtine atentia si concentrarea celor care pot sa le solutioneze. Ati auzit vreodata un Scrum Master spunand: “Hhmmm – -asta e o problema minora. Ma duc la masa”? Probabil asa nu le-ar rezolva niciodata.

Courage – sau curajul de a spune lucrurilor pe nume, de a lua decizii grele atunci cand este necesar si de a nu da inapoi, de a nu capitula. Ca atunci cand toata echipa considera un eveniment intamplat recent ca fiind catastrofal pentru obiectivul sprintului, si spun toti ”Este clar ca lumina zilei, NU o sa terminam la timp” iar Scrum Masterul spune: “doar daca ….”, creand o noua problema de rezolvat.
Apoi se lasa linistea vreo 5 secunde si cineva din echipa spune, “Va fi greu dar putem incerca”.

Focus – este capacitatea de focalize pe obiectivul Sprintului. Si de multe ori pentru Scrum Master sunt asa de multe lucruri care distrag atentia de la sprintul curent, cum ar fi diverse raportari cerute de stakeholderi, implicarea in discutii tehnice cu echipa sau de business cu Product Ownerul, sau de proces cu alte echipe si Scrum Masteri din organizatie. Toate de asemenea utile dar nu pentru obiectivul asumat al sprintului curent.
Odata am intalnit un ScrumMaster care le spunea membrilor echipei la intalnirea zilnica cum ziua trecuta lucrase la ceva aparut “pe neasteptate”, despre care ceilalti nu aveau habar, si care nu ajuta cu nimic echipa pentru scopul lor propus. Inchipuiti-va “entuziasmul” echipei in aceasta situate si interesul cu care se mai raportau si ei la obiectivul asumat pentru sprint.
Evident, un Scrum Master bun se focalizeaza pe problemele sprintului si lasa in urma alte lucruri nefacute, nerezolvate – deci creeaza probleme in toate aceste alte parti. Dar ca Scrum Master ti-ai facut datoria principala.

Openness, sau “deschidere” – aceasta valoare provine din “transparenta” pe care o impune modelul empiric de control al procesului, pe care se bazeaza metoda Scrum.
Scrum Masterul practica aceasta “deschidere” de fiecare data cand vorbeste cu Product Ownerul despre problemele intampinate de echipa si despre nevoia renegocierii “scope”-ului, dar si cand vorbeste cu echipa despre importanta respectarii prioritatilor asumate.
Ambele categorii de discutii ii vor aduce probleme, dar e mai bine sa se afle despre ele mai devreme si sa fie rezolvate atunci decat sa fie mascate si gasite abia la sfarsitul sprintului.

Respect – surprinzator, pana si respectul poate duce la probleme. Ca atunci cand din respect pentru faptul ca membrii echipei sunt diferiti, si nu putem astepta aceeasi implicare si performante de la fiecare dintre ei, Scrum Masterul alege sa medieze un conflict cu riscul unui compromis tehnic sau de eficienta a procesului, pentru a nu distruge o relatie de lucru sau un echilibru al echipei. Si trebuie sa recunoasca ca a creat de fapt o problema, desi a rezolvat o problema de relationare in echipa.

Concluzie: Imi place sa numesc rolul Scrum Masterului un rol de “sef al problemelor echipei”. Si iata ca de multe ori chiar el creeaza sau expune aceste probleme. Dar daca o face,  Scrum Masterul poate fi multumit ca si-a facut bine treaba. Vor fi vizibile, si toata lumea va pune “DA, avem probleme si nu suntem inca unde ne doream”. Si de aici vor porni din nou.

Rating: 5.0/5. From 9 votes.
Please wait...

3 thoughts on “De ce un Scrum Master bun are multe probleme nerezolvate?

  1. De regula toata lumea de afaceri fuge de probleme lasand rezolvarea lor in sarcina celor care le identifica ! Succes !

    No votes yet.
    Please wait...
    1. Multumesc George, interesanta observatia ta. Oare de ce se intampla asta?
      Probabil din acest motiv avem in Manifestul Agile un principiu care spune “Busines people and developers must work together daily, throughout the project” – citat aproximativ din memorie.
      Si in care “developers” inseamna de fapt echipa cu toate functiunile ei.

      No votes yet.
      Please wait...
      1. Raspunsul e simplu, pentru ca este mai usor asa. Sau pentru ca uneori este politica de companie. Sau pentru ca e la moda trendul gandirii pozitive prost inteleasa, habar n-am de ce se intampla asa, zic si eu … Cine este dispus sa discute cu acea persoana care identifica probleme si provoaca spre rezolvarea lor?

        No votes yet.
        Please wait...

Leave a Reply

Your email address will not be published. Required fields are marked *