de Dan Mircea Suciu

Să se revizuiască, dar să nu se schimbe nimic…

Motto: „Din două una, dați-mi voie: ori să se revizuiască, primesc!
dar să nu se schimbe nimica; ori să nu se revizuiască, primesc!
dar atunci să se schimbe pe ici pe colo, şi anume în punctele… esențiale.”
I.L. Caragiale, O scrisoare pierdută

Am simțit nevoia să revin, prin acest articol, asupra unui subiect pe care de-a lungul timpului l-am întors pe toate părțile: schimbarea. Chiar în Today Software Magazine, în 6 dintre cele 13 articole pe care le-am publicat, am vorbit într-un fel sau altul despre schimbare. Ba că e necesară ([1], [5]), ba că e naturală și firească ([3]); uneori descriind procese sau framework-uri care ne-ar putea ajuta în adaptare ([2], [4]), alteori propunând schimbarea modului de abordare a… schimbării ([6]).
În slalomul meu printre aceste teme am repetat faptul că schimbarea e dificilă. Nu am considerat nici util nici necesar să insist asupra acestui aspect pentru că am considerat că este de la sine înțeles de ce se întâmplă acest lucru. Am constatat însă că există o atitudine constantă de respingere a schimbării chiar și în contexte neașteptate, unde capacitatea de acceptare și adaptare la schimbare ne așteptăm să fie una ridicată. Iată de ce voi extinde în acest articol unele dintre gândurile expuse în [6] ca rezultat al eforturilor mele de a(-mi) explica de ce ne deranjează atât de mult schimbările și în ce condiții acestea pot deveni nocive chiar și în medii sau organizații considerate agile.

Primul din 12
În ultimii 4 ani de zile de când m-am dedica exclusiv activităților de instruire, mentorare și coaching am avut ocazia să vorbesc de multe ori despre schimbare. În cursuri sau training-uri. Am sentimentul că este un subiect relevant, în special atunci când vorbim despre un context Agile.
Mereu încep discuția de la bază. De la fundamente. Mereu încep de la valorile Agile, valori enunțate în urmă cu mai bine de 20 de ani în Manifestul Agile [7].

Cu toții știm sau simțim cât de importanți pentru atingerea succesului sunt oamenii cu care lucrăm și mai ales modul în care interacționăm sau colaborăm cu ei, fie că e vorba de alți colegi din echipa de dezvoltare sau de clienți și reprezentanți ai acestora. În același timp este la fel de important ca ceea ce facem să aibă un sens, să fie de folos cuiva, să rezolve o problemă concretă, să ducă la atingerea unor obiective importante. Cu alte cuvinte să funcționeze! Iar în această lume VUCA [9], această lume volatilă, incertă, complexă și atât de ambiguă, este important să ne putem adapta, să avem capacitatea de a ne reconfigura traseul cu ușurință.

Prin urmare ”individuals and interactions”, ”working software”, ”customer collaboration” și ”responding to change” au devenit în mod natural o necesitatea pentru o echipă de succes și, implicit, parte a valorilor enunțate de Manifestul Agile.
Dar acestea sunt valori abstracte. Este foarte dificil ca o echipă să înțeleagă ce trebuie să facă exact pentru a instala aceste valori în mintea sau în mentalitatea membrilor săi. De aceea, pentru a aduce mai multă claritate, fondatorii Agile Manifesto au propus 12 principii, mai concrete în ceea ce privește aplicabilitatea [8]. Cele 12 principii Agile reprezintă o combinație foarte puternică.
A fi agil înseamnă a urma toate aceste principii, nu doar o parte dintre ele. Dar deși toate principiile sunt la fel de importante, ele nu sunt și la fel de ușor de implementat.

De obicei, după ce fac o trecere în revistă a celor 4 valori și 12 principii Agile, acesta e momentul în care întreb care dintre principii reprezintă cea mai mare provocare, care este cel mai dificil principiu de implementat? Și pun aceeași întrebare atât studenților mei de la cursul de Agile de la programele de master de informatică ale Universității Babeș-Bolyai cât și participanților la training-urile livrate în diverse organizații, indiferent dacă lucrează deja de multă vreme într-un mediu Agile sau sunt în plin proces de transformare Agile.

Am pus cap la cap toate răspunsurile primite în ultimii 4 ani de zile și am constatat că unul dintre principii este considerat mereu ca fiind cel mai dificil de urmat sau de îmbrățișat. Iar acest principiu câștigă detașat însumând de fiecare dată în jur de 40% dintre opinii. Este vorba despre principiul al doilea, cel care se referă la îmbrățișarea schimbării și la convertirea acesteia în avantaj competitiv pentru clienți (în original: ”Welcome changing requirements, even late in the project. Agile processes harness change for the customer’s competitive advantage”).

Pe poziția a doua este principiul 10, despre construirea de soluții simple, iar pe poziția a treia este principiul al patrulea, cel referitor la comunicare zilnică cu clienții.
Dar oare de ce se întâmplă asta? De ce îmbrățișarea schimbării este atât de dificilă într-o echipă de proiect? Am încercat să detaliez în următoarele secțiuni 3 dintre motivele pe eu le consider esențiale:
A. înclinația de a identifica șabloane;
B. cultura;
C. atașamentul față de propriile rezultate;

Șabloane și confort
În [6] detaliam o idee expusă de un binecunoscut designer de jocuri video într-o celebră carte a sa, și anume aceea că creierul uman este în mai mare parte un devorator de șabloane, de tipare [11]. A învăța ceva înseamnă în esență a descoperi acele șabloane care pot fi repetate ulterior în diverse contexte. Percepem mai toate lucrurile și evenimentele din jurul nostru ca încadrându-se într-un tipar sau altul, mai mult sau mai puțin subtil. Facem asta pentru ne conserva energia. Creierului nostru nu îi place să gândească. Și asta din simplu motiv că procesul de gândire, de concentrare duce la un consum de peste 25% din energia corpului. De aceea creierul nostru are nevoie de aceste șabloane pentru a automatiza cât mai mult comportamentul nostru în rezolvarea problemelor.

Probabil că cel mai specializat șablon este cel al feței umane. O parte surprinzător de mare a creierului uman este dedicată identificării fețelor și o mare parte din puterea sa de procesare se consumă pe interpretarea înfățișării. Creierul nostru devine încă din primele zile specializat în recunoaștere facială, iar această specializare se datorează faptului că fizionomiile sunt extrem de importante pentru modul în care funcționează societatea umană. Nu de puține ori am regăsit „fețe” în dispunerea aleatorie a norilor de pe cer, în zugrăveala pereților sau în secțiuni de cartofi, ca să dau doar câteva exemple.

Capacitatea de a distinge o față într-o schiță de câteva linii și de a interpreta emoțiile subtile din aceasta indică lucrul pe care creierul știe să îl facă cel mai bine: să recunoască tipare și să umple „golurile” atunci când tiparele par a fi incomplete, pe baza tiparelor recunoscute anterior.

De asemenea, capacitatea noastră de a identifica șabloane este folosită intens în măsurarea inteligenței. Însă cercetările arată că pe măsură ce ne crește capacitatea de a descoperi mai repede diferite șabloane în jurul nostru, suntem mai predispuși să ne atașăm de stereotipuri. În special oamenilor cu un IQ ridicat le este mai dificil să își reconfigureze convingerile și credințele. De foarte multe ori convingerile pe care le avem ne determină să respingem sau să ignorăm argumentele pe care le pot aduce ceilalți. Noi deja avem răspunsurile, nu-i așa? Aceste convingeri ne fac să acceptăm mult mai greu al doilea principiu al Manifestului Agile.

Cultura lui ”așa cum trebuie”
Nici cultura nu ne ajută prea mult. Unul dintre cele mai interesante mecanisme în ceea ce privește analiza diferențelor culturale este teoria dimensiunilor culturale dezvoltată de Geert Hofstede [10]. Aceasta arată efectele culturii unei societăți asupra valorilor membrilor săi și modul în care aceste valori se raportează la comportament. Teoria propune șase dimensiuni de-a lungul cărora ar putea fi analizate valorile culturale:

1. distanța de putere (referindu-se la forța ierarhiei sociale);
2. individualism vs. colectivism;
3. motivarea de realizare și succes;
4. evitarea incertitudinii;
5. orientarea pe termen lung/scurt;
6. indulgență vs. reținere.

Relevant pentru articolul de față este indicele de evitare a incertitudinii, care este definit ca fiind „toleranța unei societăți față de ambiguitate”, în care oamenii îmbrățișează sau evită un eveniment neașteptat, necunoscut sau care îi îndepărtează de status quo. Un scor mai mic pentru acest indice arată un grad mai mare de acceptare a gândurilor sau ideilor diferite. Societatea tinde să impună mai puține reglementări, ambiguitatea nu este privită ca un aspect negativ, iar mediul este mai liber. În contrast, societățile care obțin un scor ridicat în acest indice optează pentru coduri rigide de comportament, legi mai stricte și, în general, se bazează pe adevărul absolut sau pe credința că un singur adevăr dictează totul și că oamenii știu care este acesta.

România înregistrează un scor foarte ridicat pentru dimensiunea de evitare a incertitudinii, și anume 90 (figura 1). Acest lucru se reflectă în munca noastră de zi cu zi prin încercarea de a obține specificații complete pentru fiecare sarcină pe care trebuie să o dezvoltăm, încercăm să identificăm sau să anticipăm cât mai multe excepții, punem multe întrebări înainte de a începe să lucrăm la un user story și simțim o frustrare uriașă atunci când specificațiile se schimbă după ce ne-am apucat de lucru. Nu de puține ori simțim că aceste schimbări sunt o consecință a slabei pregătiri profesionale a clienților noștri.

Vedem echipe care au o definiție foarte rigidă a user story-urilor sau echipe care au tendința de a sări peste ședințele de revizuire a iterațiilor, deoarece consideră că aceste ședințe sunt doar o invitație pentru stakeholder-i de a propune modificări.

Evident nici acest comportament nu ajută prea mult la adoptarea celui de-al doilea principiu al Manifestului Agile.

Bad Romance
În echipele noastre de proiect ne lovim zilnic de probleme care trebuie rezolvate. Pentru fiecare problemă analizăm, proiectăm și scriem cod pentru a dezvolta cea mai potrivită soluție. Nu de puține ori însă, problema se schimbă între timp și brusc soluția noastră devine inutilă. Reacția instinctivă este aceea de a ne apăra soluția: ”Hei, soluția noastră e bună! Noua problemă este greșită sau inadecvată.” Acest comportament este unul normal deoarece reflectă atașamentul nostru față de propria soluție și este greu să acceptăm că tot entuziasmul și efortul nostru au devenit inutile. Oricât de greu ne este însă, aceasta e realitatea.

În urmă cu doi ani am aflat de povestea podului de peste Choluteca, un râu aflat în zona sudică a Hondurasului. Construit inițial în 1930, podul a fost reconstruit de mai multe ori deoarece zona s-a confruntat de-a lungul timpului cu condiții meteorologice extreme. În 1997 Guvernul din Honduras a angajat unele dintre cele mai bune minți arhitecturale din lume pentru a construi un pod care să reziste oricărui uragan. Din păcate, în 1998, Hondurasul a fost lovit de uraganul Mitch, o furtună de categoria 5 care a devastat regiunea. Drumurile au fost distruse, clădirile au suferit pagube considerabile, iar toate celelalte poduri din Honduras au fost grav afectate. Cu toate acestea, podul de peste Choluteca a rezistat și a supraviețuit în condiții aproape perfecte. A fost, întradevăr, o realizare arhitecturală uimitoare. Sau, cel puțin, astfel ar fi trebuit să rămână în memoria noastră dacă nu ar fi fost o problemă: uraganul a fost suficient de puternic pentru a ”forța” râul să își croiască o cale complet nouă, să își sape o nouă albie care, din păcate, nu mai trecea pe sub pod. Prin urmare, podul cel robust nu mai trecea peste râu, devenind astfel inutil.

Este remarcabil cât de repede se pot schimba lucrurile. Această istorie demonstrează cum chiar și lucrurile care ni se par foarte greu sau puțin probabil de schimbat se schimbă. Iar noi nu putem influența sau controla aceste situații.

Concluzia ar fi aceea că nu trebuie să ne îndrăgostim de soluțiile noastre, ci de problemă, cum foarte bine sugera Uri Levine, confondator al Waze, în cartea sa [12]. Atașamentul față de o problemă ne obligă să ne întrebăm de ce există aceasta și de ce nu a fost încă rezolvată. Ne cere să ne întrebăm de ce lucrurile care par a fi soluții nu sunt. Ne cere să explorăm și să căutăm cauzele profunde și să întâmpinăm, cu deschidere, surprizele.

Concluzii
Cum ne descurcăm în aceste condiții? Cum facem față unei lumi VUCA? În primul rând trebuie să considerăm schimbările ca fiind ceva normal. Schimbările într-un proiect, în special într-un proiect software, nu sunt excepții. Ele sunt de multe ori o consecință a faptului că am luat-o pe un drum greșit. Mindsetul trebuie să fie mereu acela al experimentării. Fiecare nou rezultat/livrabil reprezintă o posibilă soluție, cu siguranță una mult mai apropiată de ceea ce trebuie să obținem decât soluțiile anterioare. Și asta produce valoare pentru clienții noștri. Cu alte cuvinte, cel mai greu lucru într-un context Agile este înțelegerea profundă a nevoii de a fi agil și evitarea de modele de gândire exprimate chiar de titlul acestui articol!

Un alt sfat important e acela de a implementa soluții cât mai simple. Este suficient că problemele pe care trebuie să le rezolvăm sunt complexe. Să nu înrăutățim exponențial lucrurile implementând și soluții complexe. Soluțiile noastre trebuie să fie cât mai simple posibil. Nu simpliste, doar simple. Există multe exemple care ne demonstrează cu implementarea de cod reutilizabil, proiectarea de arhitecturi multinivel sau utilizarea excesivă de framework-uri conduc la o creștere exponențială a complexității soluțiilor software pe care le dezvoltăm.

Dar dacă revenim asupra topului nostru, cu cele mai dificile principii Agile de urmat, observăm că pe a doua poziție se află exact principiul simplității (în original: ”Simplicity — the art of maximising the amount of work not done — is essential”). Deci nu ar strica să actualizăm lista principalelor motive pentru care principiul al doilea este greu de urmat cu un nou punct, al patrulea:
D. apetența pentru complexitate.

Nici nu am terminat bine articolul și deja avem propuneri de a schimba conținutul.

Well, change is normal! 😊

Referințe

1. D.M. Suciu, “Particularităţi ale proiectelor informatice”, TSM, nr 8, ianuarie 2013, pp. 11-13
2. D.M. Suciu, “Best Practices in Agile”, TSM, nr 16, noiembrie 2013, pp. 13-15
3. D.M. Suciu, “Agile Humanum Est”, TSM, nr 39, septembrie 2015, pp. 12-14
4. D.M. Suciu, “Agile și adaptarea la schimbare”, TSM, nr 63, septembrie 2017, pp. 15-16
5. D.M. Suciu, “Fragile Sofware Development”, TSM, nr 90, Cluj-Napoca, decembrie 2019, pp. 12-14
6. D.M. Suciu, “(Re)Gândește Agile”, TSM, nr 111, Cluj-Napoca, septembrie 2021, pp. 6-8
7. Manifesto for Agile Software Development , 2001
8. Principles behind the Agile Manifesto, 2001
9. U.S. Army Heritage and Education Center, „Who first originated the term VUCA (Volatility, Uncertainty, Complexity and Ambiguity)?”, USAHEC Ask Us a Question, The United States Army War College, 2018
10. Geert Hofstede, “Cultures and Organizations: Software of the Mind”, Third Edition, McGraw-Hill Education – Europe, iulie 2010
11. Raph Koster, “Theory of Fun for Game Design”, Second Edition, O’Reilly Media, 2013
12. Uri Levine, ”Fall in Love with the Problem, Not the Solution: A Handbook for Entrepreneurs”, Matt Holt, 2023