Agile și Anti-Agile

Simona Bonghez
Managing Partner @ Colors in Projects

Reddit este o sursă inepuizabilă de onestitate contondentă. Comentariile despre muncă și proceduri nu sunt doar brutal de sincere, sunt și exprimate într-un limbaj colorat (ca să folosesc un eufemism). Nu face excepție nici subiectul Agile, sau Anti-Agile, așa că l-am folosit ca sursă de inspirație (ei, nu vă așteptați acum să fi preluat tot textul, l-am cenzurat, păstrând totuși esența). Cum Reddit nu dezamăgește niciodată când vine vorba de expresivitate, vă las să vă folosiți imaginația pentru părțile "bip-bip".

"M-am săturat să am calendarul plin de mizerii: sprint planning, sprint retro, sprint demo, sprint bip-bip. Înteleg că vreți să frecați menta, dar nu mă chemați și pe mine în meeting-urile voastre de bip. Efectiv acele meeting-uri pot fi înlocuite de câteva mesaje pe slack, dar frecătorii de mentă din corporații trebuie să mănânce și ei o pâine, nu?"

E greu să nu empatizezi cu asta. După ani de lucru în Agile, chiar și cei mai entuziaști dintre noi au avut momente în care ne-am uitat la calendar și am zis: "Serios? Iar retro?" Doar că eu acum v-am direcționat greșit: mesajul nu are nimic de a face cu Agile! E o confuzie foarte des întâlnită: mulți spun "Agile" când, de fapt, se referă la întâlniri Scrum (de cele mai multe ori ținute prost). Agile este un mindset, nu o serie de întâlniri. Scrum este doar unul dintre framework-urile Agile (pe lângă Kanban, Crystal, FDD, DMDS, Disciplined Agile, și nu le-am enumerat pe toate), iar faptul că unele echipe nu aplică Scrum corect (adică unul singur dintre framework-uri) duce la această frustrare generalizată și spre blamarea întregii mentalități Agile.

Dar să revenim acum la ceremoniile Scrum: nu e nimic mai frustrant decât o întâlnire care se întinde la nesfârșit fără să ajungi la vreo concluzie. Și, când ai câte o "ceremonie" în fiecare zi, poate începe să pară că singura ta "livrare" e prezența la meeting-uri. Dar nu e nici Agile de vină aici și nici măcar Scrum. Dacă ne aflăm în situația în care sprint planning-ul durează cât un film de Tarantino sau demo-ul pare făcut doar ca să "bifăm caseta", atunci avem o problemă de execuție, nu de metodologie.

Despre ce e vorba de fapt?

Problema nu este neapărat numărul de întâlniri, ci felul în care acestea sunt organizate și conduse. În loc să devină momente de clarificare și îmbunătățire, ceremoniile Scrum se transformă adesea în ritualuri plictisitoare și ineficiente.

De exemplu, Sprint Planning-ul ar trebui să fie scurt și eficient: ne stabilim ce vrem să realizăm în următoarele două săptămâni și ne asigurăm că toată lumea știe ce are de făcut. Dacă se transformă într-o negociere interminabilă, am pierdut scopul. În mod similar, Sprint Review-ul ar trebui să fie ocazia de a valida că ceea ce am construit aduce valoare, nu doar un alt "bifat pe listă." Dacă feedback-ul este ignorat sau superficial, atunci întâlnirea devine inutilă. Retro-ul, când este bine pregătit și facilitat, e o șansă să îmbunătățim lucrurile și să evităm repetarea greșelilor. Dacă se reduce doar la lamentări fără acțiuni concrete, întâlnirea nu face decât să irosească timpul echipei.

Frustrarea (nu foarte) ascunsă

Înțeleg complet frustrarea cu "aceste întâlniri pot fi înlocuite de câteva mesaje pe Slack." Și, sincer, e adevărat în multe cazuri. Dacă stăm împreună două ore și nici măcar n-am stabilit cine ce face, atunci Slack-ul sau orice alt tool de comunicare poate fi mult mai eficient.

Problema apare atunci când întâlnirile devin doar "ritualuri goale", fără nicio valoare. Dacă te simți prins într-un șir nesfârșit de meeting-uri fără scop clar, nu e de mirare că începi să le vezi ca "frecatul corporatist al mentei."

Și totuși, cum să ieșim din asta?

Răspunsul nu e să aruncăm Agile pe geam și să ne întoarcem la vechiul stil de lucru, căci tocmai am stabilit că nu Agile e problema. Soluția este să facem întâlnirile mai eficiente. Nu evenimente traumatizante, nu ședințe de terapie, nu show-uri de stand-up.

Cum facem asta? Simplu: claritate și concizie. Bine, nu e chiar așa simplu, necesită atenție, abilități de facilitare și mai ales înțelegerea faptului că nu copiem, ci adaptăm. Întâlnirile la obiect și care au sens nu par nimănui pierdere de timp. Ne întrebăm: "Cum ne ajută întâlnirea asta să facem mai bine?" iar dacă doar ne face să ne simțim ocupați, verificăm dacă problema este de înțelegere, de punere în aplicare sau pur și simplu, în contextul nostru, întâlnirea nu e necesară.

În concluzie: Agile sau nu, cheia este valoarea pe care o creăm

Dacă toate aceste meeting-uri par doar un motiv de a sta în fața ecranului, atunci da, frustrările cresc. Dar Agile, când e înțeles și aplicat corect, nu e despre "mai multe întâlniri", ci despre mai multă claritate, mai multe rezultate, despre obținerea de feedback rapid, implementat fără întârziere, este despre a livra ceva apreciat de client. Dacă acestea lipsesc, atunci avem o problemă de înțelegere și implementare, nu de metodologie.

Să continuăm și cu alte afirmații anti-agile :)

"M-am săturat să văd manageri și product managers care se dau importanți prin prisma faptului că "respectă metodologia agile" (sau vor asta) la sânge. Dar ghiciți ce, nu o respectă deloc, e doar un paravan ca să poată pune presiune și să întrebe din oră în oră "cum e cu feature-ul?", "mai ai mult?", "hai mai repede" etc."

Da, clasicul "Agile by-the-book" folosit ca un scut de manageri care, în realitate, doar adaugă presiune în plus. "Pentru că așa spune metodologia Agile". Un bun prieten spune că a insistat de atâtea ori pe faptul că Agile este un mindset, nu o metodologie, încât de fiecare dată când aude pe cineva spunând că "Agile e o metodologie," are o reacție instantanee de respingere.

Din nou, problema nu este vreuna din metodologiile (sau, mai corect, framework-urile) Agile, ci modul în care sunt puse în aplicare. Când un manager spune "hai mai repede" sau întreabă din oră în oră "cum e cu feature-ul?", asta nu mai are nicio treabă cu Agile. E doar micro-management deghizat într-o terminologie cool.

De ce apare frustrarea asta?

În esență, Agile oferă un cadru care pune accent pe autonomie, colaborare și livrarea continuă de valoare. Atunci însă când managerii folosesc Agile ca un paravan pentru a continua cu vechile practici de control și presiune constantă, lucrurile se alterează rapid. E ca și cum ți-ai lua un super bolid, dar în portbagaj ai butelia cu GPL că e "ajustat" motorul. Pare fain din afară, dar înăuntru...

Știu că mulți manageri se simt nesiguri dacă nu au acea "vizibilitate totală" pe care o aveau înainte, când trimiteau câte un raport detaliat pe săptămână (știu o companie unde se făcea asta zilnic!). Dar Agile nu e despre a monitoriza fiecare pas al echipei, ci despre a avea încredere că echipa își va îndeplini obiectivele fără a fi întrebată din minut în minut "cum e cu feature-ul?"

Cauza reală: "Managerii nu renunță la control."

Problema apare când unii lideri nu înțeleg că Agile înseamnă să dai drumul frâielor și să te concentrezi pe outcome-uri (pe rezultatul final), nu pe fiecare task în parte. Știu, sună riscant pentru cei obișnuiți cu controlul permanent, dar asta e frumusețea în Agile. Dacă există o problemă sau un blocaj, echipa ar trebui să o comunice singură, nu să fie constant presată. Și da, presiunea constantă face exact opusul a ceea ce Agile promite: în loc să crească eficiența, o scade. Echipa devine stresată și dezorganizată; exact ca în cazul super bolid-ului pe GPL: în loc de super performanțe obținem doar uzura prematură a componentelor.

Și nu cumva pierdem din vedere esența?

Problema mai profundă este că, în toată această agitație legată de "respectarea metodologiei," nu mai ajungem să ne punem întrebările reale: testăm idei rapid, obținem feedback constant de la client, învățăm rapid din ceea ce facem și ajustăm pe parcurs, dăm valoare clientului cu efort minim? Sau ne-am pierdut pe drum, livrând doar feature-uri sparte în sprinturi de două săptămâni, pline de ceremonii ineficiente și micro-management la greu?

Agile nu e despre cât de bine poți pune presiune pe echipă cu întrebări constante, ci despre cum poți să creezi un mediu în care echipa să livreze eficient fără să fie supravegheată din minut în minut, un mediu în care s-a clădit, cărămidă cu cărămidă, încrederea că fiecare vrea și reușește să contribuie la succesul proiectului. Într-un astfel de mediu, oamenii sunt încurajați să își asume inițiativa, au autonomia de a lua decizii rapide și bine informate, învață continuu și se adaptează. Din păcate însă e mult mai simplu să faci micro-management decât să pui umărul la construirea unui astfel de mediu.

În loc de încheiere, preiau unul dintre comment-urile la postarea care mi-a făcut ziua mai bună (recunosc că mai recitesc postarea și comment-urile din când în când): "Ce faci la serviciu, tati? Fac totul scrum, dar într-un mod agil".

Mulțumiri comunității Reddit pentru inspirație. Comentariile originale care au stat la baza articolului pot fi găsite în discuțiile de pe subreddit-ul r/programare.