Tibor Boné 
Cătălin Rusu Luați o ceașcă de cafea, dragi pasionați de software, pentru că suntem pe cale să ne îmbarcăm într-o călătorie în lumea adesea plină de umor, uneori tragică, dar întotdeauna edificatoare a eșecurilor de proiect. Prima noastră oprire: Stația Așteptărilor. Aici, managerii plutesc într-un ocean de optimism, conduși de curenții subțiri ai așteptărilor, în timp ce acei din proiecte, care fac munca, se simt de parcă ar fi în niște tranșee, în plin război. În condițiile în care comunicarea dintre aceștia este la fel de rară ca o zi însorită în decembrie, dezamăgirea este singurul lucru care se poate obține în mod natural. Din păcate, lucrurile nu se opresc aici. Conduși de idei și intenții bune, cum ar fi decizii și retrospective bazate pe date și fapte, avem de cele mai multe ori nefericita onoare de a fi înșelați de propriile metrici.
Oamenii, la fel ca și câinii lui Pavlov, răspund la ceea ce este măsurat. Dacă nu măsurăm ceea ce trebuie, facem ca programatorii noștri să fie mai degrabă niște alergători de clasă mondială în proverbiala roată a hamsterului decât niște rezolvatori de probleme cu ochi de vultur. Dar cât de dificilă este situația? Un procent relativ mare, de 14% din proiectele IT, eșuează complet. Mai mult, doar 29% dintre proiecte au succes, iar acest procent include atât proiectele Agile, cât și cele Waterfall (Figura 1). În ceea ce privește restul, acestea sunt o "provocare" și dacă proiectele ar fi bilete de loterie, nu am face chiar o avere, nu-i așa?
De ce eșuează proiectele atât de des? Dacă proiectele ar fi înghețată, acestea ar fi cele care cad de pe cornet, chiar în momentul în care ești pe cale să iei o mușcătură. Există chiar mulți factori care pot contribui la asta. Cum ar fi o planificare greșită, cerințe neclare, lipsa de experiență sau resurse, așteptări nerealiste și decizii arhitecturale îndoielnice. În fond, totul se reduce într-un final la trei puncte cheie:
Oameni: de multe ori întâlnim în proiecte oameni nepotriviți, în roluri nepotrivite și oricât de mult dorim să evităm, ajungem să trăim principiul lui Peter, în care oamenii care performează ajung să fie promovați în roluri până la punctul în care ajung la limita competenței sau chiar mai rău. De exemplu, dacă cineva este un arhitect bun nu înseamnă automat că va fi și un manager bun.
Comunicare: cu cât echipa crește, și numărul de canale de comunicare din interior crește cvadratic, ajungând la n*(n-1)/2 pentru o echipă cu n membri. Acest lucru determină, de cele mai multe ori, creșterea timpului în luarea unei decizii, ajungând chiar să dilueze sentimentul de responsabilitate din interiorul echipei.
Mai există totuși o dimensiune notabilă, care ar trebui menționată. Una, care nu este legată neapărat de skill, ci mai mult de mindset sau atitudine. Așa cum spunea cu înțelepciune căpitanul Jack Sparrow: "Problema nu este problemă, problema este atitudinea ta față de problemă". Cu alte cuvinte, ar trebui să existe o legătură între proiect și echipă atât la nivel de abilități, cât și la nivel de atitudine. Adică, oameni potriviți în roluri potrivite în contexte potrivite.
Probabil că fiecare dintre noi a fost la un moment dat într-un proiect care, în lipsa unui termen mai bun, poate fi spus că se află în Chaos Driven Development (CDD). În astfel de proiecte sau echipe domină stresul, moralul scăzut și comunicarea care fie sună ca piața aglomerată "Mihai Viteazul", fie ca un oraș fantomă. Toată lumea face ceea ce crede că este cel mai bine, aplică rețete care au funcționat în alte proiecte, dar fără a sta să înțeleagă contextul. Nu sunt procese definite nici pentru cele mai banale lucruri, iar răspunsurile la toate întrebările sunt luate din ghidul Scrum. Echipe confuze, cu roluri și responsabilități la fel de clare ca ceața și taskuri alocate fără logică sau corelare cu skilluri. Mai adăugăm calendare pline de discuții fără sens, întâlniri peste întâlniri pentru orice subiect, oricât de mic și meetinguri pentru a discuta organizarea de meetinguri.
Orgoliile fac lucrurile și mai complicate. Dacă arhitectul se crede un da Vinci al programării, atunci refuză să înțeleagă că și alții pot avea păreri valide, văzându-și proiectul ca pe un pet project personal. Oricum, am remarcat că, de fapt, oamenii, și nu procesele sau partea tehnică sunt în centrul fiecărei astfel de situații negative.
Cu toate acestea, în tot acest haos, cea mai mare surpriză este capacitatea noastră de adaptare. Ceea ce nu ar trebui să facem este să aducem un set prefabricat de soluții din alte proiecte. În schimb, ar trebui să ne schimbăm modul nostru de gândire pentru a ne adapta la forma, contextul și dimensiunea proiectului actual. Așadar, dacă asta sună cunoscut, să avem răbdare și curaj. Nu suntem singuri pe tărâmul CDD. Cheia este să recunoaștem unde ne aflăm și apoi să căutăm cea mai apropiată ieșire.
Pe hârtie majoritatea proiectelor sunt implementate Agile, cu diferite metodologii sau frameworkuri ca Scrum, ceremonii complexe ce trebuie respectate la milimetru, roluri trendy cum ar fi Agile Coach, Sprint-uri, Jira, Refinement-uri etc. Totuși, de ce lucrurile nu funcționează?
De cele mai multe ori, când ceva nu merge cum trebuie, primul nostru gând este să analizăm cât de Agile este proiectul. Asta, cel puțin în teorie, sună perfect, deoarece Agile este la finalul zilei un set de principii și practici care, în final, promovează colaborarea, adaptabilitatea la schimbare și livrarea în mod continuu a valorii clienților. Încurajează o comunicare strânsă între membrii echipei de dezvoltare, precum și cu clienții și utilizatorii finali, acordă prioritate celor mai importante funcționalități care aduc valoare reală clienților, recunoaște faptul că cerințele și condițiile proiectului pot evolua și încurajează echipa să fie flexibilă și să se adapteze la aceste schimbări într-un mod controlat. Modern Agile este o extensie sau o reinterpretare a principiilor Agile, aducând anumite idei și valori noi, adaptate la schimbările și cerințele actuale ale industriei software. Acesta nu este un cadru de lucru sau o metodologie separată, ci mai degrabă un set de principii și practici care se bazează pe principiile Agile de bază. La centru stau câteva principii simple (Figura 2): (i) faceți oamenii să fie grozavi (Make people awesome): să le oferim resursele, cunoștințele și instrumentele de care au nevoie pentru a-și atinge și obiectivele personale, nu doar cele ale proiectului; (ii) oferiți valoare în mod continuu (Deliver value continuously): să punem accentul pe furnizarea de valoare constantă clienților și utilizatorilor finali. Să încurajăm dezvoltarea și livrarea continuă a produselor cu beneficii reale. Prin aceasta, evităm întârzierile mari și menținem o legătură strânsă cu nevoile clienților; (iii) creați siguranță psihologică (Make safety a prerequisite): să asigurăm un mediu sigur în care membrii echipei pot experimenta, învăța și lua riscuri măsurate. Acest lucru încurajează inovația și îmbunătățirea continuă fără teama de pedepse sau consecințe negative; (iv) Experimentați și învățați rapid (Experiment&learn rapidly): să încurajăm echipa să experimenteze și să învețe rapid din rezultatele acestor experimente.
Cu toate că avem toate uneltele la îndemână, greșeala pe care mulți dintre noi o facem este că vedem agilizarea unui proiect ca o rețetă de mâncare în care avem o listă de ingrediente ce trebuie adaptate doar la mărime. Pe lângă asta, tratăm un proiect ca un bibelou, care trebuie protejat. Noi vrem ca proiectele noastre să fie robuste și rezistente ca un Nokia 3310, dar evităm să le destabilizăm. Termenul "fragile" se referă la situațiile în care o organizație sau un proiect nu aplică eficient practicile Agile sau nu adoptă mentalitatea Agile. Acest lucru duce la rigiditate în gestionarea proiectelor, la dificultăți în aducerea schimbărilor și la rezistență la adaptare. În situația asta se regăsesc din păcate multe proiecte. La polul opus se regăsește antifragile, un concept introdus de către Nassim Nicholas Taleb în cartea sa intitulată Antifragile: Things That Gain from Disorder. Conceptul se referă la capacitatea unui sistem sau a unei entități de a beneficia de dezordine, haos și stres, în loc să sufere din cauza lor. Un sistem "antifragil" ar fi un sistem care nu numai că rezistă la schimbări și perturbări, ci și prosperă sau se îmbunătățește în urma acestora. Acest lucru înseamnă că un proiect devine mai robust, mai eficient și mai adaptabil, indiferent dacă acestea sunt erori de cod, fluctuații de personal, modificări ale cerințelor sau alți factori de perturbare.
Scopul trebuie să fie crearea un mediu în care echipele nu văd eșecurile sau perturbările ca pe ceva negativ, ci ca pe oportunități de îmbunătățire și învățare. Astfel, acestea ajung să îmbrățișeze schimbările în loc să le evite și să se concentreze doar pe stabilitate și pe ce funcționează acum. Acest lucru este greu de atins, deoarece de cele mai multe ori ne concentrăm pe aspectele tehnice ale proiectului, sau pe cele organizatorice, pierzând din vedere partea cea importantă și anume cea de leadership.
Desigur că în acest context cultura companiei joacă un rol important, dar la finalul zilei cel mai important rol îl joacă leadershipul de proiect. Stilurile de conducere care rezonează cel mai bine cu antifragile și cu abordarea orientată către om a Agile-ului modern includ modelele Servant, Host și Transformațional. Liderul Servant plasează echipa în centru, promovând o cultură în care liderul este în același timp umil și protector, asigurându-se că nevoile echipei sunt prioritare. Liderul Host, pe de altă parte, joacă un rol de echilibru delicat - asigurând supravegherea atunci când este necesar, dar știind când să se retragă și să aibă încredere în expertiza echipei, încapsulând un amestec de abordări de tip hands-off, autocratic și delegator. Între timp, liderul transformațional este o sursă de inspirație, provocând mereu echipa să se străduiască să atingă o performanță mai ridicată și asigurând o comunicare fără probleme. Nu în ultimul rând, mai există și o tipologie netradițională, de "Trailblazers". Aceștia sunt un fel de Indiana Jones ai conducerii. Ei nu merg doar pe drumul bătătorit, ci sunt cei care creează noi căi, stabilesc tendințe și își provoacă echipa să viseze mai departe. Ei adaugă astfel condimentele suplimentare, făcând ca amestecul de Agile modern să fie și mai atractiv.
Aceste stiluri de conducere, combinate corespunzător, servesc un cocktail perfect pentru o abordare Agile modernă și sănătoasă. Din păcate, acest lucru nu este însă suficient. Mai avem nevoie de încă un ingredient cheie: oamenii potriviți, în rolurile potrivite. Doar așa se va produce o schimbare de mindset, care va afecta fiecare persoană din proiect în parte. Pe cale de consecință, echipele vor atinge țintele proiectului mai repede și ușor, eliberând proiectul din zona fragilă.
Sintetizând cele expuse mai sus, putem trage concluzia că eșecul nu este un mister. Se întâmplă atunci când eforturile oamenilor sunt nealiniate cu țintele proiectului sau echipelor, când sunt nesusținuți de către leadership, când contextul în care lucrează este greșit sau rigid, când comunicarea este absentă sau deficitară, iar procesele fie "dispar" și nu sunt respectate, fie se înmulțesc ca niște gremlini. Adoptând o abordare agilă modernă, putem face ca proiectele noastre să fie nu doar robuste, ci și antifragile.
Închei cu o zicere din programare, "Vorbele sunt ieftine, arată-mi codul", care se traduce în managementul de proiect cu: Hai să o facem pur și simplu!
Agile and Waterfall Project Failures - VersionOne. (2020). 13th Annual State of Agile Report. [This annual report often discusses the state of agile development, including success and failure rates.]
Expectation Management and Communication - McFarland, D.A., Diehl, D., & Rawlings, C.M. (2015). Sociological Theory in the Study of Communication Processes. Annual Review of Sociology, 41, 39-56.
Measurement and Optimization - Drucker, P. F. (1954). The Practice of Management. Harper & Row. [Peter Drucker's classic text includes the adage "What gets measured gets managed."]
Peter Principle - Peter, L.J., & Hull, R. (1969). The Peter Principle: Why Things Always Go Wrong. William Morrow & Co.
Project Communication and Failures - PMI (Project Management Institute). (2017). A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Sixth Edition. [This guide touches on aspects of project communication and the intricacies of project management.]
Agile, Fragility, and Antifragility - Taleb, N.N. (2012). Antifragile: Things That Gain from Disorder. Random House. [Taleb's work explores the concept of antifragility and how some systems benefit from chaos and disorder.]
Leadership Styles in Agile Contexts - Greenleaf, R. K. (1977). Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness. Paulist Press. - Appelo, J. (2010). Management 3.0: Leading Agile Developers, Developing Agile Leaders. Addison-Wesley Professional.
Human-oriented Agile - Denning, S. (2018). The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done. AMACOM.
