Termenul de "cârcoteli" din titlul l-am împrumutat de la unul dintre clienții mei care, anul trecut, într-unul din proiectele noastre de consultanță pentru implementare Agile în organizație, mi-a spus: "Avem nevoie să stați de vorbă cu oamenii noștri, să vedeți de ce cârcotesc și să rezolvați, o dată pentru totdeauna, aceste cârcoteli." Și da, e corect înțeleg foarte bine că aceste "cârcoteli" trebuie clarificate, că trebuie să răspundem la ele, dar oare e necesar să le rezolvăm "pentru totdeauna"? Sau mai degrabă am vrea ca oamenii să continue să aibă întrebări, să dezbată și să comenteze, în timp ce experimentează în spiritul Agile? Pentru că unul dintre beneficiile Agile mai puțin vizibile și mai puțin bine primite în organizații este crearea transparenței: permite identificarea elefantului din cameră, analizarea respectivului elefant și, în final, eliminarea dumnealui (adică, a ditai elefantului). Totul necesită însă discuții și, bineînțeles, un anumit nivel de asertivitate, sau, mai bine spus acel nivel de încredere în echipă care ne spune că "da, putem vorbi liber, nimeni nu ne îndeasă pumnul în gură și problemele ridicate le rezolvăm împreună."
Articolul de față prezintă trei dintre cele mai frecvente cârcoteli împotriva Agile, și o cârcoteală-bonus, pentru cititorii cârcotași. Înainte de toate, este de precizat că a cârcoti despre Agile nu înseamnă a desființa orice beneficiu al implementării Agile. Recunoaștem cu toții că Agile nu este un panaceu organizațional, un fel de baghetă magică care îți rezolvă toate problemele din proiecte, este doar un mod de lucru care funcționează super bine în anumite contexte (pentru cei care vă întrebați, bagheta magică în management încă nu s-a inventat, din păcate). Nu putem folosi aceeași abordare, unică, pentru orice tip de proiect posibil, acestea sunt mult prea variate pentru a permite abordări identice. Ba chiar abordările trebuie să fie distincte pentru că ele depind de contextul echipei, de maturitatea echipei și a organizației pentru care realizăm proiectul respectiv, de cultura organizațională. Anumite proiecte și organizații au mai mult de câștigat din implementarea modului de lucru predictiv (waterfall), alții vor avea succes folosind metode adaptive (Agile), alții vor opera în cicluri incrementale, alții vor opera iterativ, sau hibrid ș.a.m.d. (căci mai sunt...).
Pentru cei care se întreabă "Bine-bine, dar de unde știm când e mai bine waterfall, când e mai bine Agile?" fac aici o paranteză clarificatoare. Ne ajută nenea Stacey cu matricea complexității: pe axa verticală avem CE ANUME avem de făcut: cerințele din proiect sau din activitatea pe care o desfășurăm. Cât de cunoscute ne sunt ele încă de la început? În ce măsură sunt ele nu doar cunoscute, dar și convenite cu stakeholderii noștri? Pe măsură ce urcăm pe axa verticală, devin tot mai frecvente confruntările cu situația în care cei cu care lucrăm nici măcar nu și-au clarificat lor înșiși aceste cerințe, ce să mai vorbim de căderea la comun acord cu toți cei implicați. Pe axa orizontală CUM ANUME lucrăm. Poate fi vorba de procesele noastre, poate fi vorba de platforme sau de tehnologia pe care o utilizăm. Pornim de la cazul în care am mai lucrat în proiecte similare și știm ce avem de făcut, am mai folosit tehnologia de care avem nevoie. Pe măsură ce avansăm spre dreapta, întâlnim situații în care s-ar putea ca tehnologia să se schimbe, ori avem nevoie să experimentăm, să încercăm și să refacem. Abordarea tradițională, predictivă adică Waterfall merge cel mai bine atunci când specificațiile sunt foarte clare, înțelese și acceptate de părțile implicate, iar tehnologia ne este foarte familiară (știm ce avem de făcut, am mai făcut așa ceva, știm cum se face, nu avem ce să experimentăm). Dar pentru celelalte zone - avansăm acum pe ambele axe - avem cerințe neclare, care, cu siguranță, vor suferi modificări, procese de lucru nefamiliare sau tehnologii cu potențial de a fi actualizate permanent. Aici, în mod cert, e nevoie de o abordare care ne permite să asimilăm schimbarea, să experimentăm și să fim foarte flexibili în ceea ce facem. Este zona în care se recomandă abordări Agile și este, totodată, zona în care tind să apară cârcotelile.
Fig.1
"Știm că Agile ne-ar aduce oarece beneficii, însă nu ne permitem momentan o schimbare pentru că aceasta ar perturba toată activitatea."
Adevărul este că nu este niciodată momentul să faci o schimbare majoră. În schimb, ceea ce putem face cu toții este să adoptăm acea tehnică a ridiculously small objectives (obiective ridicol de mici). E ca atunci când, neantrenat fiind, te hotărăști să mergi la maraton: nu te duci direct să alergi la cursa de 10 km sperând că o vei finaliza, pentru că tot ce vei reuși va fi să alergi până îți iese sufletul, după care să nu mai ieși din casă o săptămână. Îți poți propune, în schimb, să alergi în jurul casei tale câte cinci minute pe zi. După câteva zile, poți crește la 10 minute, apoi poți crește iar cu 10 minute ș.a.m.d. Important este însă să existe o consecvență în acest antrenament, să te antrenezi zi de zi. Atunci când vrem să implementăm Agile, nu pornim cu un obiectiv major, de genul schimbării întregii organizații printr-o revoluție. Ce putem face este să începem cu pași mici: preluăm anumite concepte din Agile care pot aduce valoare echipelor, lăsăm echipele să experimenteze, să îmbunătățească modul de lucru puțin câte puțin. Și ne asigurăm că există acea consecvență care permite învățarea, integrarea în practicile organizației și optimizarea.
"Suntem pregătiți pentru o schimbare rapidă".
Atunci când ne-am hotărât să implementăm Agile, ne suflecăm mânecile, suntem gata și credem că procesul va fi instantaneu. Să schimbi un mod de lucru într-o companie nu este însă ceva ce se obține bătând din palme. E nevoie de timp, de resurse și de implicare pozitivă a managementului în implementare, astfel încât să asigurăm că există sprijinul necesar pentru ca echipele să poată lucra în mod sustenabil. Și din nou trebuie să recurgem la teorie: de data aceasta ne ajută Satir.
Figura 2: Virginia Satir Change Model
Modelul teoretic al schimbării introdus de Satir explică faptul că implementarea unui nou mod de lucru nu este un traseu liniar ascendent, așa cum am spera. Nu trecem imediat la rezultate mult mai bune imediat ce schimbarea a fost introdusă (în grafic reprezentat cu Foreign element). E nevoie de timp (a se citi: să ne înarmăm cu răbdare) pentru că în momentul în care introducem un mod nou de lucru, echipele încearcă să asimileze ceva nou, să înțeleagă ce și cum se face, cum se traduce asta în ceea ce făceau înainte. Toată această "luptă" duce invariabil la o scădere a performanței inițiale. Dacă organizația recunoaște că are nevoie de această perioadă de acomodare, de resurse și timp, atunci, trecând prin suișurile și coborâșurile inerente acceptării, adoptării și exersării modelului nou, ea poate ajunge la performanța aceea pe care o dorește de atins prin implementarea noului mod de lucru. Schimbarea însă nu se poate face rapid, oricât de mult ne-am dori noi ca lucrurile să stea altfel.
"La noi nu funcționează. Am încercat. Nu merge."
Majoritatea frameworkurilor din Agile (Scrum, XP, Crystal, Kanban, Scrumban etc) sunt așa-numite lightweight methodologies pentru care nu există rețete sau descrieri detaliate despre cum vor fi implementate. De aceea, fiecare organizație are propria înțelegere despre cum pot fi aplicate în contextul lor specific. Multitudinea de concepte și tehnici care există în Agile face necesară o triere a lor pentru a vedea ce aduce cu adevărat valoare fiecărei organizații. Nu dăm la o parte o metodologie, ci vedem cum am putea să o facem să funcționeze pentru noi. Poate preluăm doar anumite elemente, poate le combinăm între ele. Dar dacă nu avem experiență anterioară cu ele, va fi greu să jonglăm cu toate aceste posibilități. E ca atunci când încerci un nou boardgame, iei întâi instrucțiunile de joc, pui tabla și începi și... apar întrebările: cum era aici? Cine începe, care e primul pas, cum împărțim cine știe ce resurse, cine decide... întrebări care te obligă să revizitezi instrucțiunile de joc. De aceea, e nevoie de un ghid, poate un agile coach sau un scrum master experimentat, care au mai făcut acest lucru, dar care să aibă și flexibilitatea de a recunoaște nevoia de a experimenta și de a adapta metoda la organizație. În lipsa acestui ajutor e posibil ca experimentările prea multe și dese, fără siguranța că mergem pe drumul cel bun, să creeze frustrare. De aceea, fără un ghid și fără alocarea timpului necesar învățării în echipă, fără alocarea resurselor pentru a putea studia și a găsi noi oportunități de a lucra mai bine, schimbarea va fi mult îngreunată.
"Toată lumea știe exact de ce facem ce facem, le-am spus-o în nenumărate meetinguri"
În momentul în care ne dorim să supunem echipele la un efort suplimentar (am discutat până acum că trecerea la un nou mod de lucru presupune un astfel de efort) este logic ca ele să știe de ce facem asta. Adică să devină clar pentru toată lumea nu doar de ce își dorește organizația acest efort, ci și WIIFM (what's in it for me). Pentru că "milă mi-e de tine, dar de mine mi se rupe inima", dacă ar fi să ne folosim de înțelepciunea populară. Vreau să știu de ce facem asta noi ca organizație, dar în același timp vreau să înțeleg că merită și pentru mine, ca individ. Acum problema cu obiectivele organizaționale afișate pe un Power Point frumos colorat la diferite meetinguri este că au cele mai bune șanse să fie trecute la capitolul "vrăjeală corporate", să fie ignorate, să nu fie reținute. Aceste obiective, pentru a fi concretizate, trebuie să aibă atașate metrici măsurabile, revăzute și discutate frecvent pe parcursul adopției mentalității Agile. Un fel de barometru al echipei de management, transparent la nivelul fiecărui om din organizație. Vreau să știu - gândește omul din organizație - că ceea ce ați formulat voi, managementul, ca beneficii pentru organizație chiar se măsoară și sunt atinse (și nu e "vrăjeală corporate"). Astape de o parte. Pe de altă parte, WIIFM trebuie și el să fie realist definit și, da, din nou, măsurabil. Căci vreau să știu - gândește omul din organizație - că se întâmplă ceea ce mi-ai promis și că beneficiile chiar există pentru mine.
Ca orice cârcotaș, mi-a fost mult mai ușor să scot la lumină lucrurile care nu merg sau poate sunt mai dificile atunci când încercăm să implementăm Agile, dar experiența dovedește că, în pofida unui traseu cu obstacole, la final, rezultatul face să merite efortul de a parcurge drumul.
Stacey, R. (2012). The Tools and Techniques of Leadership and Management: Meeting the challenge of complexity. Routledge, London.
de Nóra Dobre
