Ideea acestui articol mi-a venit cu mai multe luni în urmă, atunci când pregăteam o prezentare pentru conferința "…și mamuții sunt Agile" ce a avut loc la Cluj-Napoca în această primăvară. Se întâmplă uneori ca anumite lucruri să pară a fi foarte clare și evidente la un moment dat, însă atunci când le studiezi mai îndeaproape ai surpriza să constați contrariul. Așa s-a întâmplat și atunci, când dorind să studiez eficiența și beneficiile aderării la bunele practici Agile adoptate în anumite organizații sau echipe de proiect, am ajuns la concluzii ce sunt departe de a le considera optimiste.
Voi încerca în cadrul acestui articol să identific principalele elemente ce duc la ideea că a aplica practici de succes în implementarea Agile ale altor organizații/echipe în propria echipă de proiect poate să aibă mai multe dezavantaje decât avantaje.
O comparație care mie mi se pare foarte sugestivă este aceea dintre un proiect informatic și un joc de șah. Suntem tentați să spunem că ambele au câteva caracteristici de bază pe care le cunoaștem de la bun început:
Dacă mergem mai departe cu această comparație, putem spune că o abordare Agile a jocului de șah este una în care reacționăm corespunzător la fiecare mutare a partenerului de joc, în timp ce Waterfall-ul clasic este mai degrabă o încercare de a anticipa din start cât mai bine mișcările adversarului, urmând să mutăm piesele pe baza unei strategii proprii şi ignorând ce se întâmplă de cealaltă parte a mesei până când apare o "coliziune" (mod de lucru care, de multe ori, are loc și la "adversar").
Evident în modul Waterfall probabilitatea de eșec este semnificativă, lucrurile ameliorându-se în funcție de cât de repede ne "trezim" și ne coordonăm mișcările cu cele ale adversarului.
Consider că aceasta este o vedere idilică a proiectelor IT deoarece pleacă de la ideea că dacă stăpânești foarte bine procesele ce guvernează "jocul" și dacă ai mai văzut un stil de joc asemănător cu al adversarului în trecut, șansele de succes sunt mari. Strategia de succes s-ar axa pe aceste două componente esențiale care te conduc la algoritmi (aproape) infailibili în situaţii date şi care îţi şi permit să faci predicţii cât se poate de realiste.
Multitudinea de cărţi de IT project management se referă, în mare parte, la astfel de proiecte şi iau în considerare un "numitor comun" al proiectelor IT, un context aproape ideal sau care se îndepărtează într-o manieră decentă, benignă, de acest ideal, specificându-se de fiecare dată că anumite lucruri pot fi adaptate în practică în funcţie de specificul unui proiect sau altul. Project Managementul clasic se referă la proiecte ca la un context în care există un set minim de procese şi reguli şi sunt îndeplinite anumite rolurile concrete, fiind pus accent pe cicluri, mai lungi sau mai scurte, de monitorizare, coordonare şi control.
În realitate însă proiectele IT sunt mult mai imprevizibile decât ar putea fi un joc de şah. Acest lucru se întâmplă pentru faptul ca regulile se schimbă (de multe ori în timpul derulării proiectului), procesele sunt mai mult sau mai puţin respectate, iar unele roluri pot lipsi complet din "peisaj". Spunem adesea că proiectele IT nu sunt fair, surprinzându-ne cu elemente ce le scot din sfera a ceea ce cunoaştem sau am mai întâlnit deja. Aş dori să fiu bine înţeles: pornim deja de la premisa că proiectele, prin definiţia lor, sunt întreprinderi unice, care au elemente ce nu au fost întâlnite până atunci, însă caracteristicile specifice proiectelor IT (despre care am vorbit în detaliu în numărul 8 al Today Software Magazine) fac ca numărul diferenţelor într-un astfel de proiect să fie covârşitor. Iar acest lucru nu se întâmplă în cazul unor excepţii nedorite, ci în marea majoritate a proiectelor IT.
Iar unul dintre motivele principale pentru care project managementul clasic nu s-a dovedit a fi eficient în cadrul proiectelor IT este tocmai faptul că nu acoperă aceste excepţii majoritare.
Metodologia Agile a apărut ca o necesitate în a accepta şi trata "excepţiile" pomenite mai sus și fiind în primul rând, o schimbare de atitudine. Abordarea clasică "forţează" setarea unui anumit context rigid care "garantează" succesul unui proiect și oferă sugestii cu privire la modul în care ar trebui să fie tratate situațiile de excepție pentru reintra în "normal".
Filozofia Agile pornește de la ideea că aceste excepții sunt firești, și nu trebuie neapărat să adaptăm contextul la condițiile noastre, ci mai degrabă să ne adaptăm noi la condițiile impuse de context. Însă noi suntem diferiți. Modul în care reușesc eu să mă transpun și să gestionez o anumită situație cheie diferă de modul în care o fac ceilalți. Sfaturile lor și ideile lor despre cum ar trebui să abordez o anumită problemă îmi sunt folositoare atâta timp cât le trec prin filtrul personal și reușesc să le adaptez la context.Prin urmare Agile trebuie privit ca o stare de spirit, ca un mod de abordare, ca un mindset.
Pentru a mă face mai bine înțeles voi da câteva exemple despre cum nu ar trebui să procedăm în anumite situații.
Conferințele de profil abundă uneori în descrierea unor studii de caz și ale unor povești de succes despre aplicarea Agile. Foarte mulți dintre cei prezenți la astfel de conferințe vin cu speranța că vor găsi sfaturi utile pentru proiectele în care sunt implicați la momentul respectiv. Întrebările sunt foate diverse: "Cât de mare e echipa?", "Echipa este colocată sau nu?", "Product Owner-ul este la client sau din propria organizație?". Toate aceste întrebări au doar darul de a găsi un șablon cât se poate de potrivit care să fie aplicat propriului proiect pentru a garanta succesul. De cele mai multe ori însă acest lucru nu se întâmplă, și este normal să fie așa: sunt atât de multe configurații posibile și situații aparte în proiectele IT, încât este foarte greu să găsești două proiecte similare. Prin urmare, în loc să încercăm să găsim proiecte de succes similare cu ale noastre, principala întrebare pe care ar trebui să o adresăm este: "Cum reușesc să aplic și să adaptez unele dintre lucrurile auzite în rezolvarea propriilor probleme pe care le am în proiect?"
Un alt exemplu este dat de cei care, în diverse situații, spun: "Proiectul pe care lucrez nu este Agile", referindu-se în general la faptul că anumite roluri nu sunt îndeplinite corespunzător, că anumite documente nu au o structură ideală sau că anumite ședințe (sau ceremonii cum sunt ele denumite în Agile Scrum) nu se desfășoară așa cum scrie la carte, uitând faptul că rolurile, documentele sau ceremoniile sunt doar instrumente de lucru Agile. Nu proiectul este Agile, ci modul în care îl abordăm poate fi Agile. Și acest mod de abordare este și cel pe care va trebui să îl aplicăm pentru a adapta aceste instrumente (când e cazul) sau pentru a ne adapta noi la intrumentele pe care le avem la dispoziție. Nu cădeți în capcana de a stabili o singură cale adevărată de abordare Agile a unui proiect!
În sfârșit, o altă greșeală frecventă este aceea de a aplica în mod identic o abordare de succes dintr-un proiect anterior în proiectul curent. Acest lucru este o greșeală deoarece, după cum am mai subliniat, proiectele IT diferă foarte mult unele de celelalte. Într-o companie ce oferă servicii software, așa cum este și 3Pillar Global, acest lucru este dureros, pentru că în cazul fiecărui client pornești aproape de la zero. Fără doar și poate există o experiență în spate care s-a format, însă contextul va fi de fiecare dată altul și multe dintre concluziile trase în trecut nu mai sunt valabile în noua variantă.
O primă concluzie pe care o putem trage este faptul că ideea de best practices în gestiunea proiectelor software nu doar nu ajută foarte mult, dar poate chiar dăuna. Un set de worst practices ar fi mult mai util oricui este responsabil de gestionarea unui proiect IT.
O a doua concluzie este doar o reiterare a unui fapt pe care multă lume pare să-l fi uitat: nu există o formulă Agile. Agile este în principal un set de valori și principii, iar dacă cineva nu își poate imagina modalități de organizare unei echipe de proiect în jurul acestor valori și principii atunci putem spune că acea persoană nu este Agile. Aceast lucru este foarte important de înțeles într-o perioadă în care mulți devin rigizi în susținerea unui mod unic de a fi Agile.
Aș mai sublinia în încheiere că adoptarea unei metodologii Agile poate da naștere în general unei mișcări de rezistență puternice, deoarece afectează toată activitatea unei persoane implicate. În general, din ceea ce am constat eu, lumea nu se plânge de schimbarea stilului de dezvoltare ci de faptul că acesta nu se schimbă. Exista în acest moment o dorință mare de a fi Agile pe toate nivelele de senioritate și în toate categoriile de oameni implicați într-un proiect. Toti vor să devină Agile, dar Agile în sensul în care fiecare dintre ei îl văd. Fiecare are o viziune proprie despre ce înseamnă a fi Agile, fiindu-i adeseori greu să împărtășească această strategie cu ceilalți, dar manifestă o rezistență mare la schimbări în momentul în care direcția de agilitate nu este cea anticipată.
