Mă numesc Ovidiu. Uneori, nu pot spune că sunt un Agile Coach clienților mei! În ultimii doi ani a început să se resimtă un vânt al schimbării în discuțiile noastre cu clienții alături de care lucram la P3 în departamentul de Agile. În urmă cu doar câțiva ani, majoritatea conversațiilor inițiale cu noi clienți începeau cu ei exprimând curiozitate față de metodologia Agile și potențialul acesteia de a le crește productivitatea. Mereu au existat dificultăți de a explica și convinge clienții vizavi de modul în care re-organizarea proceselor este benefică, dar opoziția pe care o întâmpinam era, în general, legată de rezistența normală întâlnită la manageri față de schimbarea modului de organizare, a rolurilor din companii și inerția naturală a grupurilor de oameni.
Dar o nouă provocare s-a făcut simțită recent. În multe cazuri am fost nevoit să evit termeni din Scrum Guide sau terminologie LEAN-Agile pentru a explica îmbunătățiri de procese. Citez un CIO de la un furnizor tier 1 din automotive: "I don't want to talk agile, I want to talk about business outcomes."
Dorința exprimată de el, de altfel, a fost foarte sănătoasă. Rezultatele sunt ceea ce contează și mentalitatea Agile și practicile asociate au exact scopul de a le genera. Cu toate acestea, pentru mulți factori de decizie din companii, această mentalitate și frameworkurile asociate nu mai sunt văzute ca unealta potrivită pentru a obține rezultate. Pare a fi percepută ca o destinație în sine, însă una care trebuie evitată. În asemenea momente, dacă nu reușim să evităm terminologia, riscăm să deraiem o conversație complet sau să pierdem încrederea unui manager de departament care este factor de decizie.
Frameworkurile de Agile nu sunt desigur o soluție universală și au fost cazuri în care alte moduri de a organiza echipele și procesele de lucru au fost optime. Dar ideea de a avea echipe stabile care oferă un ritm de livrare predictibil, limitarea riscurilor prin validarea rapidă a ipotezelor business și cicluri de feedback care îți permit să reacționezi repede sunt principii de organizare care aduc plus valoarea în foarte multe contexte de business.
Poate vă întrebați atunci cum este posibil să implementezi o transformare folosind un framework ca SAFe, fără să folosești termenii specifici de acolo. Într-una dintre colaborările recente cu un client din zona de automotive, a trebuit să organizez un eveniment care, în limbajul SAFe, ar fi fost numit PI Planning. În mod ideal, aș fi vorbit despre Agile Release Trains, despre Iteration Planning, despre Business Owners care oferă contextul de business echipelor și despre PI Objectives.
În loc de asta, am mutat discuția pe fundamentele reale ale planificării: "Hai să aducem toate echipele relevante într-un spațiu comun pentru două zile și să ne uităm la ce ne dorim să livrăm în următoarele trei luni." În loc de "ART", am vorbit despre "ecosistemul echipelor care trebuie să colaboreze pentru a livra ceva ce poate fi livrat către clienți". În loc de "PI Objectives", am vorbit de "rezultatele business pe care le putem atinge realist în perioada următoare". Iar în loc de "Iteration Planning", am vorbit despre "cum ne organizăm concret munca pe săptămâni și vizualizăm dependințele dintre echipe".
Deși există improvizații ce pot funcționa, întrebarea este totuși, cum de am ajuns în această situație și ce ne așteaptă în viitor?
Exista două mari tendințe pe care le vedem tot mai pronunțat în special la marile companii alături de care consultanții P3 lucrează:
Personalizarea conceptului de agile și versiuni puternic adaptate de frameworkuri:
Majoritatea firmelor nu mai doresc să aplice principiile și metodologiile Agile fără să le adapteze bazat pe propria lor viziune. La începutul mișcării, personalizarea era mai mult o încercare de a păstra o parte din vechile procese și roluri neatinse. Acum vorbim despre companii care experimentează combinând diferite frameworkuri și abordări. Un mare producător de mobilă din SUA își organizează echipele pe modelul de Agile Release Trains, dar colaborarea între trenuri se face după principiile Scrum\@Scale. Coordonarea proceselor și adaptarea planurilor se face între Release Train Engineers, în cadrul unui Executive Action Team, împreună cu membri din Lean-Agile Center of Excellence. Acest grup are rolul de a rezolva blocajele mari și de a menține ritmul de lucru al organizației. În secțiunea de business, fiecare Product Manager lucrează într-un Executive MetaScrum, un grup în care se stabilesc prioritățile, se discută termenele și se iau decizii strategice împreună cu partenerii business. EAT-ul are grijă de funcționarea zilnică, MetaScrum-ul asigură direcția.
Un alt exemplu ar fi îmbinarea modelului Spotify cu modelul Large Scale Scrum de către o bancă europeană. Echipele sunt organizate în squads și tribes, urmând principiile Spotify pentru autonomie și identitate de echipă. În același timp, coordonarea între echipe se face prin shared sprint planning și shared retrospectives, inspirate din LeSS, pentru a menține alinierea și sincronizarea la nivel de produs. Deciziile tehnice majore sunt luate în grupuri de feature team representatives, nu prin roluri ierarhice, păstrând astfel spiritul de colaborare al ambelor modele.
Respingerea terminologiei: Cuvântul agile a devenit caustic. Este un cuvânt care încheie conversații în loc să le deschidă. Videoclipuri și postări online avertizează că "Agile este un termen de marketing, nu ceva ceea ce inginerii reali folosesc" . Consultantul britanic James Birnie, într-o postare devenită virală în comunitățile Agile, afirmă: "Agile is a dirty word." Potrivit lui, termenul și-a pierdut puterea pentru că a fost folosit în exces și adesea aplicat fără înțelegere. La rândul său, Dave Snowden, creatorul modelului Cynefin, a criticat în repetate rânduri "industrializarea agile-ului" și transformarea lui într-un produs de masă, ușor de vândut, dar rar înțeles în profunzime. Iar în 2023 Forbes, publica articolul: "Is Agile Dead?"
Prin urmare, merită să ne punem întrebarea: "De ce am ajuns în această situație?"
Motivul este simplu și uman: multe implementări Agile au dat greș răsunător. Au tocat sume suficient de uriașe fără să livreze rezultate încât au ajuns să fie publicate în reviste. La baza acestor eșecuri se află trei cauze principale:
Unul dintre cele mai frecvente motive pentru care transformările Agile nu funcționează este neînțelegerea profundă a conceptului de către top management. Prea des, liderii își deleagă responsabilitatea către echipele operaționale fără să-și asume rolul de parteneri activi în schimbare. Craig Larman, co-creatorul frameworkului LeSS, refuză să înceapă o transformare dacă membrii din conducerea executivă nu participă alături de el la un retreat de 2-3 zile, unde trebuie să demonstreze că au înțeles principiile. Este un filtru de integritate. Marile firme de consultanță rareori aplică o astfel de rigoare. În schimb, se mulțumesc cu buy-in formal și rapoarte de progres fără impact real. Din dorința de a nu periclita contractele, mulți consultanții care au condus transformările au evitat conversațiile dificile și au avut dificultăți să spună nu clienților.
Odată cu popularizarea termenului Agile, a apărut o cerere masivă de persoane care să ocupe aceste noi roluri și traineri care să îi pregătească. Nevoia a fost atât de bruscă și intensă încât multe organizații au recurs la soluții rapide: conversia angajaților existenți, în special din middle management, după doar câteva zile de training. În multe cazuri, acești oameni bine intenționați nu au avut timp să digere conceptele sau să exerseze practic rolurile. Iar trainerii erau, la rândul lor, consultanți fără experiență de durată în teren, cu o pregătire sumară.
Urmărind trendul actual, e legitim să ne întrebăm: vom mai vorbi despre Agile peste cinci ani? Și dacă da, în ce fel? Deși viitorul e întotdeauna greu de anticipat, sunt din ce în ce mai multe semne că termenul în sine și rolurile clasice asociate, ca Scrum Master, Product Owner, Agile Coach ar putea deveni irelevante sau complet reinventate.
Pe de altă parte, nevoia de echipe care colaborează eficient, care livrează într-un ritm sustenabil, care pot adapta rapid produsul în funcție de feedback nu va dispărea. Dimpotrivă. Asta înseamnă că spiritul Agile are toate șansele să supraviețuiască, chiar dacă nu va mai fi numit așa.
Această posibilă tranziție ne forțează să punem o întrebare inconfortabilă: Cine mai suntem noi dacă nu mai putem spune că suntem Porduct Owners și Scrum Masters? Dacă job title-ul nostru dispare, dar competențele noastre rămân, cum le reîmpachetăm? Cum ne regăsim în afara vocabularului.
Personal, am început deja să mă prezint uneori ca specialist în echipe și procese în loc de "Agile Coach". Nu pentru că mi-este rușine de cuvântul "agile", ci pentru că în unele contexte, vechiul titlu creează mai multă confuzie decât claritate.
Dincolo de titulaturi și frameworkuri, activitatea de zi cu zi a unui Agile Coach se concentrează pe câteva direcții esențiale:
Topologia echipelor. Ajutăm la definirea structurii echipelor astfel încât acestea să fie autonome și adaptate tipului de muncă.
Fluxul de informații intern. Ne asigurăm că echipele, liderii și stakeholderii comunică eficient și constant, evitând pierderile de context.
Metrici de livrare. Măsurăm ce contează: timpi de livrare, ritm, capacitate. Nu doar pentru raportare, ci pentru învățare și adaptare.
Motivație și implicare. Observăm dinamica echipelor și susținem un mediu în care oamenii sunt conectați la munca lor și simt că aparțin.
Vestea bună este că tehnicile și practicile pe care le asociem azi cu Agile sunt departe de a fi o invenție a anilor 2000.
Sociologul german Stefan Kühl, profesor la Universitatea din Bielefeld și consultant la Metaplan, arată în lucrările sale că majoritatea principiilor de organizare pe care le numim astăzi "agile" sunt, de fapt, iterații moderne ale unor concepte dezvoltate în secolul XX. Modele precum team autonomy, decentralized decision-making, cross-functional collaboration sau feedback loops existau deja sub diverse forme în anii '20 și '30. De exemplu, ideea de "echipă cross-funcțional" avea un corespondent conceptual în "autonomous working teams", termen folosit în literatura de management interbelică.
Stefan Kühl susține că modelele organizaționale evoluează ciclic, nu liniar. De fapt, principiile sănătoase de lucru nu s-au schimbat prea mult în ultimele decenii, tocmai pentru că ele reflectă constrângerile reale ale tipului de muncă predominant în epoca noastră. Începând cu perioada interbelică, a început să prindă contur ceea ce astăzi numim era knowledge workerului, oameni care nu execută sarcini repetitive, ci rezolvă probleme, iau decizii și învață continuu. Acest tip de muncă presupune autonomie, colaborare, feedback și adaptabilitate.
Prin urmare, nu este o coincidență că aceleași principii apar din nou și din nou, indiferent de eticheta sub care sunt promovate. Ele nu sunt o modă, sunt un răspuns structural la realitatea muncii complexe. Nu frameworkul este esențial, ci capacitatea de a crea condiții pentru ca oamenii inteligenți să poată lucra împreună eficient într-un context schimbător. Și atâta timp cât acea realitate rămâne neschimbată, aceste principii vor rămâne valabile, cu sau fără cuvântul Agile.
Problemele și disfuncțiile organizațiilor creează presiune pentru soluții. În acel moment, apare teren fertil pentru o nouă "metodologie salvatoare". O reîmpachetare a bunelor practici existente, cu un limbaj proaspăt și un accent pus exact pe durerile organizaționale ale momentului.
Doar că, în goana după implementare, aceste cadre sunt adesea aplicate brusc, incomplet sau superficial. Ceea ce generează un nou set de probleme, ușor diferite. Iar aceste noi simptome vor crea, în timp, presiunea pentru următorul "mare model organizațional". Astfel, ciclul se reia, iar istoria se repetă, dar cu alți termeni și alte slide-uri în PowerPoint.
Iată mai sus lista "foarte scurtă" de autori ca abordează aceste principii în ultimii 50 de ani:
Este foarte posibil ca, în anii următori, să fim nevoiți să ne desprindem treptat de conceptul de Agile. Această tranziție va fi cu atât mai dificilă pentru colegii care și-au început cariera în ultimii 10-15 ani, pentru care Agile a fost contextul implicit de lucru, și care nu au experimentat alte moduri de organizare. Pentru ei, pierderea "etichetelor" poate părea o pierdere de identitate profesională.
Dar dacă lăsăm la o parte limbajul și brandurile, ne dăm seama că esența muncii noastre nu dispare. Nu avem nevoie de ambalajul numit "Agile" ca să înțelegem cum funcționează echipele bune, cum se construiesc sisteme eficiente de livrare sau cum arată o organizație care învață. Avem nevoie de luciditate, discernământ și o capacitate reală de a observa, înțelege și interveni acolo unde echipele și procesele devin disfuncționale.
Adevărata provocare nu este dacă Agile moare, ci dacă noi suntem pregătiți să rămânem relevanți înțelegând principiile sănătoase care stau la baza mindsetului. Iar vestea bună este că, dacă ne uităm atent, tot ce am învățat și aplicat în ultimii ani rămâne valid. Ritmuri de livrare sănătoase, echipe autonome, feedback rapid, concentrare pe valoare- toate acestea sunt atemporale.
Îmi doresc să închei această analiză cu o încurajare la reflecție pentru tine, drag cititor. Cum te va afecta pe tine această schimbare? Ce vei păstra? Ce vei lăsa în urmă? Și cel mai important, vei avea curajul să te redefinești?
de Alex Popescu
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
