Recent am avut o conversatie foarte interesanta cu Steve Porter de la Scrum.org. Am discutat despre o echipa Scrum in care programatorii nu isi aleg singuri sarcinile. In schimb, un programator senior, in timpul intalnirii zilnice Scrum , selecteaza elementele de Product Backlog la care se va lucra in acea zi. Acest dezvoltator senior este un membru respectat al echipei de dezvoltare. Asa ca intrebarea a fost, daca un Scrum Master ar trebui sa faca ceva in legatura cu asta?

Pe de o parte, ghidul Scrum nu cere in mod explicit membrilor Echipei de Dezvoltare sa sa isi aleaga singuri sarcinile. Ghidul Scrum afirma, de asemenea, ca "nimeni (nici macar un Scrum Master) nu ii spune Echipei de Dezvoltare cum sa transforme un Product Backlog in “Increments of potentially releasable functionality”. Se pare deci Echipa de dezvoltare face Scrum, si nu este nevoie ca un Scrum Master sa intervina. Cu toate acestea, ar putea exista multe motive posibile pentru care aceasta situatie ar putea necesita o interventie din partea unui Scrum Master. Iata doua: definitia Echipei de dezvoltare si a Valorilor Scrum.

In primul rand, aceasta situatie ar putea sa fie in contradictie cu definitia Echipei de dezvoltare din ghidul Scrum. Ghidul Scrum nu descrie un Grup de dezvoltare. Mai degraba echipa Scrum are o Echipa de dezvoltare. Cred ca termenul "echipa" a fost folosit in mod intentionat si unul dintre principalele motive pentru care Scrum este atat de eficient este ca se bazeaza pe "o echipa", mai degraba decat pe "un grup". Prin definitie, o echipa este "un grup de oameni care impartasesc un scop comun al echipei si un numar de obiective care trebuie indeplinite; membrii echipei se dedica reciproc obiectivelor si unii altora". Intr-un context Scrum, putem lua in considerare livrarea “potentially releasable Increments” ca fiind scopul Echipei de Dezvoltare si Sprint Backlog ca un set de obiective provocatoare.

Dar este greu sa ai un nivel ridicat de angajament fata de un lucru pe care nu il faci voluntar. Dimpotriva, o situatie in care cineva da unei persoane ceva de lucru face acea persoana sa aiba un potential nivel de angajament mai scazut legat de finalizarea sarcinii. Un angajament este o responsabilitate, dar daca nu se ia o decizie, el sau ea nu isi va asuma responsabilitatea pentru aceasta decizie. Cel mai bun lucru pe care il puteti obtine intr-o astfel de situatie este o obligatie, dar nu ownership fata de sarcina. Prin atribuirea elementelor din Sprint Backlog membrilor Echipei de Dezvoltare, un dezvoltator senior afecteaza capacitatea unei echipe de a fi o echipa. Aceasta situatie ar putea, de asemenea, sa incalce principiul egalitatii Echipei de dezvoltare: "Scrum nu recunoaste titluri pentru membrii Echipei de Dezvoltare, indiferent de activitatea efectuata de persoana respectiva". Dar aici ar putea fi o situatie precum "toti dezvoltatorii sunt egali, dar unii dezvoltatori sunt mai egali decat altii”.

In al doilea rand, aceasta situatie pare sa contrazica valorile Scrum. Vom incepe cu un citat din Ghidul Scrum: "When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.". Am descris deja mai sus modul in care aceasta abordare poate afecta capacitatea echipei in ceea ce priveste asumarea unui angajament. Oamenii nu isi iau un angajament personal sa atinga obiectivele Echipei Scrum.

Aceasta situatie poate fi, de asemenea, un semn de lipsa de respect. Ghidul Scrum defineste respectul astfel "Scrum Team members respect each other to be capable, independent people.". Dar situatia in care cineva stabileste ce activitate ar trebui sa faca o persoana intr-o anumita zi este departe de idea de a trata aceasta persoana ca fiind capabila si independenta (ca sa nu mai vorbim despre idea de respect). Aceasta este mai degraba o demonstratie a lipsei de incredere in capacitatea cuiva. O astfel de situatie este foarte toxica pentru moralul si performanta echipei.

Tinand cont de toate acestea am ajuns la concluzia ca echipa nu face Scrum si un Scrum Master ar trebui sa intervina pentru a creste gradul de constientizare a echipei legat de ceea ce se intampla si despre modul in care acest lucru influenteaza o echipa. Fiind destul de increzator in concluzia mea, am impartasit acest lucru cu Steve, iar raspunsul sau a fost: "ai grija sa nu tragi concluzii cu privire la modul in care o Echipa de Dezvoltare decide sa lucreze. Daca observi un comportament pe care nu il intelegi sau nu il poti imbunatati, abordeaza situatia initial cu curiozitate. Aminteste-ti faptul ca, oamenii cei mai implicati in activitate sunt in cea mai buna pozitie sa decida ce este bine si rau.”. M-am gandit: "Tu erai cel care vorbea despre mintea incepatorului si importanta contextului si ai facut greseala pe care ii inveti pe altii sa o evite!”. Lucrand mult timp pentru marile companii, am fost literalmente platit pentru a avea raspunsurile.

La un moment dat, mi-am dat seama ca succesul meu s-a datorat faptului ca am pus intrebari si ca am ajutat echipa mea sa gaseasca cel mai bun raspuns posibil. Nu am venit cu propriile mele solutii. Acesta a fost motivul pentru care am inceput sa invat despre Agile, Scrum, auto-organizare, echipa etc. In general, de aceea nu incetam sa invat lucruri. Si asta incerc sa ii invat so pe altii. " Aminteste-ti de propria ignoranta" — acesta a fost sfatul meu pentru cei carora le faceam coaching. Si acum nu am reusit sa ma ridic la nivelul propriilor sfaturi. Asta m-a trezit de-a binelea!

Cand lucrati cu oameni, lucrurile sunt rareori asa cum se vad la suprafata. Fiecare situatie, fiecare problema depinde de context, deci puteti avea solutii diferite pentru doua intrebari (aparent) similare ale aceleiasi persoane - pentru ca aceste doua intrebari se afla intr-un context diferit. Deci, doar privind la suprafata nu este suficient. Chiar daca lucrurile par a fi evidente, pentru ca exista o sansa serioasa ca acestea sa nu fie. Este foarte usor sa te bucuri cand actionezi "ca un tip destept" si ai un raspuns clar la orice intrebare. Fiind expert. Dupa cum Mike Maddoc scrie in blogul Forbes "In calitate de experti, suntem platiti mai mult, exista incredere mai multa in noi si, uneori, suntem respectati mai mult. Parintii nostri sunt mandri, partenerii nostri sunt mandri si, uneori, chiar si copiii nostri cred ca suntem cool.” Asta duce la o gandire foarte directa. Stim prea multe si uitam lectia lui Socrate ca nu stim nimic. Si asta duce la decizii gresite, uneori cu consecinte proaste, uneori cu unele catastrofale.

Si nu vreau sa fiu acest gen de persoana. Vreau sa evit capcana expertilor. Eu aleg sa am mai putina incredere in ceea ce este considerat ca fiind mai bun. Aleg sa fiu curios, sa pun intrebari si sa fiu deschis in a afla raspunsuri. Ma voi intreba: "Ce altceva mai exista? Ce imi lipseste? Ce m-ar putea conduce la o concluzie contrara? "Asa ca am scris o mantra pe un carton pe care il am acum in portofel si o recitesc de mai multe ori pe zi:

Aminteste-ti de propria ignoranta

Esti interesat de zona Agile? Descopera cursurile noastre.

Sergey Makarkin
Chief Program Manager