Am discutat cu invitații noștri despre Agile și principalele provocări aduse de pandemie și nu numai:
Simona Bonghez - CEO @ Colors In Projects ,
Dan Suciu - Lector @ Universitatea Babeș-Bolyai ,
Ovidiu Mățan: Credeți că procesele Agile vor rămâne tot aceleași sau se vor schimba? Lumea se plictisește adesea de ele. Voi cum procedați? Încercați să le adaptați sau să le schimbați?
Dan Suciu: Cu siguranță procesele se schimbă și s-au schimbat foarte, foarte mult. Din 2001, de la publicarea manifestului Agile, singurul lucru care nu s-a schimbat este conținutul manifestului, adică principiile și valorile. În rest, procesele, practicile, instrumentele s-au schimbat foarte mult, cu precădere în ultimii doi ani. Unul din lucrurile care era încurajat era ca membrii echipei Agile să fie în aceeași încăpere când lucrează. S-au modificat tehnicile care permit colaborarea în cadrul unei echipe distribuite virtuale.
Simona Bonghez: Faptul că ieșim cu Agile din zona de IT și intrăm în alte industrii declanșează schimbări. Dar ele nu se manifestă la nivelul principiilor pentru că , așa cum a zis și Dan, acestea rămân ancora. De exemplu, când aplicăm Agile în zona de manufacturing, de servicii în energie, lucrurile se schimbă, deoarece nu putem vorbi de un Scrum 100%, din cauză că acesta nu va funcționa. Vorbim, astfel, de abordări hibride în care poți lua din mai multe frameworkuri Agile diverse elemente și să le combini, astfel încât rezultatul să aducă valoare echipelor respective. Granularitatea activităților nu mai permite întâlnirile daily standup. De exemplu, aveam o organizație care face daily standup în fiecare miercuri și, deși este în contradicție cu conceptul daily, pentru acea organizație, întâlnirea de miercuri de 20 de minute era suficientă.
Dan Suciu: La facultate, am un curs pe această temă la masterat. Unul din lucrurile pe care le fac este să îi întreb pe studenți cum dezvoltă proiecte la companiile de unde vin, indiferent de companie. În proporție de 95%, răspunsul este că implementează Scrum sau Kanban sau altă metodologie, dar că nu este metodologia by the book. Fiecare masterand are regretul că nu se respectă varianta pură, că se fac compromisuri. Este normal să existe adaptări în funcție de cultura organizațională, de tipul de proiecte, de clienți.
Simona Bonghez: La începutul acestei ediții a fost o întrebare legată de Agile în automotive. Aș dori să dau exemplul Wikispeed, o mașină construită în 2008, păstrând principiile Agile. A existat un concurs de construire de mașini prototip, dar funcționale, Progressive Insurance Automotive XPRIZE, cu un premiu de milioane de dolari. Se cerea construirea unei mașini cu cerințe foarte clare. Trebuia să se limiteze consumul la 100 miles/gallon, adică vreo 2.5l/100km. Mai mult, trebuia să fie o mașină cu patru locuri care să satisfacă reglementările legale și standardele de siguranță pentru mers pe drumurile publice. Nu a avut pe nimeni în echipă, nu a avut niciun ban, iar în trei luni a ajuns la o echipă de voluntari cu care a livrat mașina care nu doar că avea consumul dorit, ci atingea 100 km în 5 secunde, iar viteza maximă era la 240 sau 250 km/h. Dezvoltarea s-a făcut aplicând principiile Agile. E un studiu de caz în implementarea Agile despre cum poți contrui o mașină plecând de la zero. Nu au câștigat premiul cel mare. Au fost pe locul 10 surclasând companii gen Toyota sau Chrisler care au bugete imense pentru dezvoltare. Succesul a fost asigurat de o dezvoltare iterativă și incrementală.
Bogdan Mureșan: Scrum evoluează foarte mult momentan în frameworkuri de scalare. Noi, de exemplu, avem nu două sau trei echipe mici, ci 50 - 60 - 100 de echipe care să lucreze pe proiecte mamut. Scrum și Agile au evoluat foarte mult în această direcție, solicitând foarte mult modul acesta de gândire unde înveți, testezi, apoi retestezi. Am încercat modelul Spotify, fiind unul dintre cele mai permisive. DADU explică cel mai bine influența celorlalți parametri care influențează masiv tot ce înseamnă produs (marketing, sales). SAFe îmi place în mare măsură la nivel de concept și în mai mică măsură la nivel de constrângeri, în ciuda confortului pe care îl aduce în companiile mari.
Care este mitul vostru preferat legat de implementarea Agile?
Dan Suciu: Miturile nu ne plac, pentru că bagă bețe în roate. Auzim de multe ori afirmații de genul "Asta nu o să meargă la noi". Cineva mi-a atras atenția asupra unei alte reacții frecvente "Aaaa, păi noi făceam Agile, dar nu știam că îi zice așa". Din păcate, de cele mai multe ori, e vorba de o confuzie la nivel de formă. Este parșiv acest mit, adică să consideri că tu oricum făceai aceste lucruri și că nu are sens să mergi mai departe ca să aprofundezi.
Bogdan Mureșan: Un mit "preferat" este că firmele care oferă servicii de tip software outsourcing înțeleg că aceste servicii merg mână în mână cu contractele cu preț fix. Asta înseamnă că ai niște bani ficși pentru un obiectiv fix, pe când în Agile totul se învârte în jurul schimbării și adaptării la ceea ce merge. Sunt foarte multe contracte în care clientul contractează încă de la început ce vrea să primească, dar, în același timp, vrea să și beneficieze de avantajele Agile și, la nevoie, să schimbe tot. Sunt niște antiteze absolut grozave, practicate la scară largă, demonstrând imaturitate în înțelegerea conceptelor Agile.
Simona Bonghez: Nu am un mit, am mai degrabă niște sechele. Noi, când ne-am gândit la implementarea Agile, am considerat că și facem ceea ce îi învățăm pe ceilalți. Cei care se ocupau de cursurile Agile au zis că firma Colors in Projects trebuie să treacă, de asemenea, la Agile. Un coach era mai flexibil, iar celălalt era by the book. Nici acum nu știu cui să îi mulțumesc mai multe. Amândoi ne-au ajutat să implementăm Agile. Unul ne enerva peste măsură când ne obliga să facem lucrurile într-un anumit fel, după care, la retrospectivă, venea celălalt coach și noi veneam cu tot felul de idei legate de cum ar merge mai bine procesul. Al doilea coach era de acord, deși primul coach ne obliga să respectăm regulile rigid. La un moment dat le-am zis că ori unul e prea strict, ori celălalt e prea flexibil, ori nici unul nu știe Agile. A fost modul nostru de a învăța cât de important este să îmbunătățești continuu ceea ce faci. Nu pleci de la ceva care ți se pare ție că ar merge bine, ci este de preferat să încerci cu ceva ce s-a dovedit că funcționează, iar apoi, doar în măsura în care experimentezi, să vii cu idei de îmbunătățire.
Cât de important este ca acel coach Agile să înțeleagă și businessul?
Simona Bonghez: Nu cred că trebuie să fie expert în domeniu, dar trebuie să aibă un limbaj comun cu cei cu care lucrează. Trebuie să înțeleagă constrângerile din industria respectivă, astfel încât să poată să demonteze situațiile în care membrii echipei ar putea spune că ceva nu se poate aplica. Uneori ajută autoritatea expertului în domeniu, iar alteori ajută autoritatea celui recunoscut ca Agile coach în domeniu.
Bogdan Mureșan: Este bine ca un coach să înțeleagă businessul, dar rolul lui este de a-i ține concentrați pe valori și procese pe acei care sunt deja atenți la produs și business. Constrânși de business, se va încerca mereu găsirea unui scurtcircuit, iar coachul e acolo să le reamintească procesele și valorile Agile.
Cum putem ajuta echipele ce fac cercetare să facă estimări realiste?
Bogdan Mureșan: Cercetarea implică lucruri de care nu ești sigur, testarea unor idei al căror rezultat nu îl cunoști. Este foarte greu să estimezi când vei ajunge la rezultat. De aceea avem story points, pentru a avea o măsură care nu se leagă de timp, ci de ceva obiectiv care să indice ritmul de muncă. E mai important ritmul decât rezultatul, deoarece nu pot cunoaște rezultatul în cercetare. Putem avea niște milestones pe care ni le propunem și pe care le folosim pentru a identifica dacă ne apropiem sau nu de rezultatul dorit. Mai investim timp sau resurse? Schimbăm macazul? Ne propunem ținte mici pe care le evaluăm continuu.
Dan Suciu: Țin minte o istorie în care un manager de proiect era pe un proiect nou. Tocmai se câștigase clientul respectiv de compania unde activa. Exuberant, la prima ședință, reprezentantul clientului a întrebat când se poate finaliza proiectul. Colegul nostru, foarte liniștit și senin, a răspuns că singurul lucru pe care îl poate spune este că proiectul va fi gata în viitor. Clientului i-a picat fața și s-a enervat. Din punctul de vedere al mangerului de proiect, aceasta era o estimare realistă. Tradus în ceea ce se întâmplă în Agile, trebuie să facem distincția între o estimare de acuratețe mare și o estimare precisă, prin urmare, între o estimare exactă și o estimare corectă. De cele mai multe ori, se recomandă tehnici de estimare care să ducă la estimări de acuratețe mare. De aceea, acestea sunt adesea date sub formă de interval (de exemplu, vom termina între 10 și 12 luni). Cu cât suntem presați să venim cu o estimare cât mai precisă, cu atât greșim mai mult.
În echipe, avem viteze diferite. Îi favorizează Agile pe cei ce au viteză mai mică, astfel încât aceștia să se integreze? Îi defavorizează pe ceilalți?
Simona Bonghez: Depinde de ego. Aș da drept exemplu sindromul eroului. Am lucrat cu o organizație unde am avut acest sindrom. Acest erou era tipul programatorului ce avea cunoștințe foarte bune, foarte avansate pe o anumită tehnologie și ce lăsa echipa să se chinuie până ce ajungeau aproape de release. Evident, oamenii dădeau de o problemă, la care venea eroul nostru ce muncea două zile și două nopți, rezolva situația și devenea eroul organizației. Echipa nu era foarte fericită cu el. De cele mai multe ori, rezolvarea era una de moment care necesita ulterior multă muncă pentru identificarea cauzelor și a unei soluții sustenabile. Eroul trăia din momentele acestea de glorie. Când am ajutat organizația să treacă la Agile, aceștia au trebuit să înțeleagă că nu mai este vorba de indivizi și rezultate individuale, ci despre echipă și rezultatele echipei. Acești eroi nu au rezistat pur și simplu. Ego-urile puternice nu își găsesc locul în Agile. Unii dintre ei au devenit experți care ajutau echipa să rezolve problemele tehnice la nivel de organizație. Alții au părăsit organizația, pentru că nu au reușit să își găsească locul.
Care sunt constrângerile SAFe care nu vă plac?
Bogdan Mureșan: Cea mai deranjantă pentru mine este planificarea pe trei luni cu toate echipele. De obicei, aici se planifică următorul release mare. Faptul că tu îți planifici la sânge următoarele trei luni, chiar lăsând un buffer, contravine principiului schimbării din mers. În schimb, îmi place că se dă libertate echipelor să adopte Scrum, Kanban sau orice altceva, să combine ce funcționează, să adapteze procesele. SAFe oferă control stakeholderilor care au nevoie de o viziune de ansamblu.
Când este bine ca o echipă să se răzgândească și când nu?
Dan Suciu: Cred că momentul oportun este la retrospective. Adam Grant dă exemplul testelor grilă și al candidaților ce dădeau acest test. Unii dădeau răspunsurile din prima și ulterior predau testul. Alții reveneau asupra întrebărilor, iar la unele întrebări schimbau răspunsurile. Punctajul celor din a doua categorie a fost mai mare decât al celor din prima categorie. Ne putem da frâu liber intuiției, dar este bine să revenim asupra ideilor. Este esențial să te împaci cu faptul că ai greșit. Nu ascunde greșeala. Bucură-te că ai mai învățat ceva. Am văzut că, de foarte multe ori, intram în ședințe cu idei preconcepute, iar când cineva venea cu idei contrare eu le desființam imediat. Asta blochează munca în echipă.
Ce impact au avut pandemia și statul acasă asupra Agile?
Simona Bonghez: Cred că a primit un nou avânt, așa cum digitalizarea a primit un nou avânt. Companiile au simțit cu mai multă acuitate, cu mai multă durere, că trebuie să facă ceva pentru a-și îmbunătăți procesele de muncă. Din perspectiva noastră, a furnizorilor de training și consultanță, este foarte bine că putem livra cursurile online. Lucrurile merg foarte bine. Este chiar mult mai simplu, deoarece nu trebuie să aștepți să vină oamenii din zece părți ale țării. Mă aștept la acea oboseală mentală care vine din incertitudine, nu din procesele de muncă. Procesele se pot îmbunătăți, oamenii sunt dispuși să încerce lucruri noi în continuare, dar mă aștept ca incertitudinea generată de faptul că reglementările se schimbă de la o zi la alta să se acumuleze și să existe o oboseală mentală.
Care va fi următoarea reinterpretare a Agile?
Bogdan Mureșan: Mă gândesc la un lucru care este extrem de încurajat și important în lumea Agile. Lucrurile se mișcă pe baza echipelor self-sufficient care știu să facă drive. Oamenii care au tendința să controleze tot trebuie acum să se bazeze pe echipele acestea pe care nu le pot controla. Faptul că aceste echipe dau rezultate de mai bine de un an și jumătate vine cu efectul negativ că se pierde conexiunea între oameni. Agile ar trebui să găsească modalități de a lega oamenii în ciuda distanței, deoarece, altfel, membrii echipei își vor pierde din atracția unii față de alții.
Dan Suciu: Îmi amintesc de un interviu al lui Yuval Noah Harari, autorul cărților Sapiens. Meseriile de azi nu vor avea viitor, iar întrebarea era ce soluție găsim. Harari spunea să ne cultivăm inteligența emoțională. Problema nu va fi una de calificare sau recalificare, ci una emoțională când îți vei da brusc seama că acel lucru pe care îl faci nu mai este relevant sau dorit. Sper ca asta să se întâmple și în echipele Agile care sunt bombardate de schimbări, iar codul scris azi nu mai este relevant mâine. Trebuie să faci față ideii că nu mai este relevant.
Simona Bonghez: În activitatea de coaching este nevoie de activități scurte, dar intense de construire a echipei, de menținere a nivelului de încredere la nivelul echipei.
de Ovidiu Mățan
de Victor Popa
