Agile Oldtimer – Paradoxul dintre vechi și nou
Să fie reticența la schimbare (și, implicit, la nou)? Să fie o imposibilitate umană de a ne debarasa de trecut și de lucrurile care ne-au marcat la un moment dat? Sau poate amândouă, în egală măsură?
Oricum, cert este că ne place acest „amestec” nostalgic în care să includem permanent și o rămășiță din alte epoci. O facem, uneori, pentru siguranța lucrului trainic. Alteori, pentru că ultima „descoperire” nu pare suficient de stabilă și de acoperitoare. De fapt, cred că aici este problema: evoluția este atât de rapidă, transformările atât de subite încât elementele înconjurătoare (tehnologii, metodologii, standarde etc.) nu reușesc să țină pasul. Construim, adăugăm „etaje”, dar ancorele încep să cedeze. Și atunci simțim nevoia să punem un „ingredient” vechi, tradițional. E o senzație că întărim întregul eșafod și că riscăm mai puțin o demolare bruscă și foarte costisitoare.
Managementul proiectelor nu face excepție. Febra „Agile” a cuprins întreaga comunitate. Am observat întreaga paletă de emoții – de la neîncrederea specifică oricarei noi abordări până la entuziasmul asociat unei soluții îndelung așteptate. Sprinturi, cerințe adăugate pe tot parcursul proiectului, rezultate intermediare, termene reduse etc. – toate fac parte din recuzita unei umbrele de metodologii („Agile”) și promit a ne face viața de manageri de proiect mult mai ușoară.
Totuși, imediat ce entuziasmul (de sezon) s-a mai domolit, iar lucrurile au început să se mai așeze, surprizele nu au întârziat să apară. Prima (oarecum așteptată) a fost legată de domeniile în care se poate aplica abordarea Agile. Nici macar industria software – „incubatoarea” acestei abordări – nu se poate baza, în toate ramurile ei, pe Agile techniques. De celelalte domenii, nici nu mai vorbim.
Dintr-o dată, noua „abordare-minune” a început să-și dovedească limitările, dezamăgind adepții mult-prea grabiți în a generaliza. Umbrela „Agile” se dovedește insuficientă pentru a acoperi tot procesul de managementul proiectelor și suficient de instabilă pentru a deschide noi semne de întrebare. Dar nu-i nimic! Intră în funcțiune „rețeta” prezentată la început. Paradoxul e la îndemâna noastră și începem să „amestecăm”.
Nu avem suficientă vizibilitate, nu simțim un control suficient asupra fazelor unui proiect? Atunci îmbunătățim abordarea Agile cu… planificarea tradițională. Nu mai păstrăm ideea de planificare per etapă (pas cu pas), încercăm și un plan general. Nu putem evidenția legătura proiecte – strategia companiei? Cerințele, scopul – nu sunt de ajuns pentru a răspunde întrebărilor managementului? Ce ar fi să mixăm technicile Agile cu…managementul prin obiective (Management by objectives)? Chiar dacă ultima este o abordare cu ștate vechi (descrisa de Peter Drucker în 1954). Are stabilitate dovedită, succes demonstrat și e deja perfecționată. Echipa nu comunică așa cum trebuie, în ciuda faptului că am mers pe o abordare tip fractal (1 expert, 1 om de marketing, 1 dezvoltator etc.)? Hai să folosim tehnici de comunicare din managementul tradițional (și decrepit!) al proiectelor – întâlniri mai de durată cu toate echipele din proiect. Contravine principiului „Agile”? Posibil! Însă doar puțin și ne ajută să menținem controlul, să avem performanțe.
În final, obținem un amalgam care răspunde cerințelor specifice unei situații, dar care este departe de propunerea inițială. Nu pot și nu vreau să mă pronunț pentru validitatea unei astfel de abordări. Cu alte cuvinte, este și bine și rău. Pe de-o parte, este bine întrucât nicio abordare nu trebuie considerată ad-literam ci trebuie îmbunătățită/ajustată permanent. Nu exista o rețetă, iar standardele/metodologiile sunt doar „coloana vertebrală” a managementului proiectelor. Restul ține de inspirație, intuiție și experiența managerului de proiect.
Pe de altă parte, răul vine tocmai din ceea ce prezentam la început. Avalanșa de informații/tehnici/schimbări determină o nesiguranță și (de aici) o reticență cronică la asumarea riscurilor pentru ceea ce e (relativ) nou și (poate) insuficient aplicat. Și atunci, adăugăm elemente deja împământenite, cu performanțe dovedite.
Dacă îmi permiteți o comparație aluzivă – am migrat de la McArthur-i și Ioane D’Arc la „comitete și comiții” care acoperă (de multe ori) „spatele” în cazul deciziilor dificile. Clamăm aplicarea (numai a) tehnicilor noi și inovatoare. Dar, păstrăm (la loc de cinste) o „vitrina de pe vremea bunicii” din care mai scoatem o planificare tip waterfall, o comunicare top-down sau o guvernanță cu Steering Committee. Paradoxal, nu?
Dr. Ing. Cătălin-Teodor Dogaru, trainer, consultant și managing partner la TSP(smartprojects.ro), este un entuziast al managementului de proiect, program, proces, ce caută constant talentul și inovația în această industrie.
Titlul de doctor în telecomunicatii denotă pasiunea pentru perfecționare continuă și nicidecum dorința de a mai adauga un titlu lânga nume. Același lucru se poate spune și despre programul de MBA absolvit recent în Proiecte și Procese la Universitatea din Viena sau despre titlul de PMP (se pregătește intens deja pentru certificarea PgMP).