Am avut parte de o discuție plină de observații interesante și clarificări despre Agile Leadership. Alături de noi au fost:
Dan Suciu - Partner @ Colors in Projects,
Bogdan Mureșan - VP of Technology @ Connatix,
Ioana Barboș - Founder & Data Scientist @ Giraffa Analytics,
Ciprian Sorlea - CTO @ Nordlogic,
Bogdan Mureșan: Sunt VP of Technology la Connatix de trei ani jumătate și activez în industrie de aproape 20 de ani.
Ioana Barboș: Sunt Data Scientist de aproximativ zece ani, iar de doi ani jumătate lucrez pentru mine însămi.
Ciprian Sorlea: Sunt CTO la Nordlogic, sunt pasioant de tehnologie, iar motivul pentru care mă aflu la acest panel este pentru că îmi place să fiu partener de discuție cu Bogdan și Dan.
Dan Suciu: Sunt lector la Facultatea de Matematică și Informatică la Universitatea Babeș-Bolyai, dar sunt și partener la compania Colors in Projects, o companie specializată în training de management de proiecte.
Ovidiu Mățan: Avem Agile în zona de leadership?
Dan Suciu: Cele două aspecte se pot combina foarte bine. Vom avea lideri formali și informali în orice grup, indiferent dacă grupul lucrează pe format Agile sau Waterfall. Probabil că este mai interesant să ne întrebăm ce tip de leadership funcționează mai bine în context Agile. Ce funcționează mai bine într-un mediu adaptiv? Ce funcționează mai bine într-un mediu predictiv? Când nu există un lider care să întrețină toată această poveste, o echipă nu rămâne din inerție în zona de performanță ridicată. Vreau să mă refer la un serial, New Amsterdam, de pe Netflix. Scenariștii acelui serial s-au chinuit să creioneze cum arată un servant leader care se potrivește foarte bine în context Agile. Personajul principal este directorul executiv al spitalului. Nu este genul de om îmbrăcat la cravată care se plimbă prin secție și dă directive sau asignează taskuri. Nu face micromanagement și nu controlează. Se plimbă îmbrăcat într-un halat, cu stetoscop la gât. Este un om care întreabă obsesiv "How can I help?". Este genul de om care știe că lucrează cu profesioniști și care dorește să ajute fără a-i controla. Am auzit o vorbă. Dacă echipei îi este foame, Scrum Masterul este cel care comandă pizza, deoarece există un blocaj în performanța echipei. Este cea mai bună definiție pentru Servant Leader. Este cel care elimină impedimentele și blocajele într-o echipă.
Ciprian Sorlea: La noi, echipa este formată din echipa executivă și middle management care include un Project Manager. Echipa poate fi Agile și dacă are un Project Manager în interiorul ei, fără a avea o persoană cu titlul de lider. Contează nu rolul deținut de persoană pe verticală sau orizontală, ci contribuția persoanei în echipa respectivă. Dacă este să privim o echipă la nivel de leadership, fie că este o echipă executivă sau middle, orice companie are o serie de grupuri de interese, de clienți, de entități care cer ceva de la echipa respectivă. Pot fi probleme, solicitări, nevoi în cadrul proiectelor. Pot fi probleme ce vin de la ANAF sau Guvern. Poți face un plan la începutul anului, dar rolul lui este de a-ți da o direcție de mers, deoarece planul în sine îl poți arunca pe ușă în clipa în care l-ai făcut. O echipă Agile adevărată nu moare cu planul acela în brațe, ci reacționează la schimbare. Echipele de management și companiile care supraviețuiesc sunt cele care pivotează, sunt cele cu leadership de tip Agile.
Bogdan Mureșan: Tot vorbim de echipe, dar în Agile nu este vorba doar de echipă. Punem tot felul de întrebări. Pe cine ne bazăm să rezolve problema aceasta? Pe cine ne bazăm să găsească soluția? Pe cine ne bazăm să ia o decizie privind produsul? Pe cine ne bazăm să ia o decizie de schimbare de business sau de vânzări? Fiecare individ ia o decizie în zona lui. Există Team Agility (implementarea unei decizii), dar și Business Agility (luarea unei decizii). Întreba cineva cum este afectată industria IT de modelul de monetizare, adică pe bază de subscripție, SaaS, sau alt model. Ei bine, pentru a schimba modelul de monetizare este posibil să trebuiască să schimbi toată expertiza echipei de vânzări. Trebuie ca acei care se află cel mai sus să îi lase pe cei de jos să ia cele mai bune decizii în zona unde sunt experți. Trebuie să lăsăm echipei cât mai multă autonomie.
Există o referință pentru best practices în Agile? A devenit Agile un fel de religie?
Bogdan Mureșan: Lucrez în industrie de șaptesprezece ani și, la un moment dat, am ajuns un mare fan Agile. Lumea a început să mă confunde cu omul Agile, deși eu sunt un om care formează și organizează echipe, care rezolvă problemele cu echipele, practic un om care știe să scaleze și să livreze. Agile este doar o metodă, o modalitate de a gândi care îți permite să rezolvi anumite probleme în contextul schimbător de azi. Lumea uită că Agile este un instrument care te ajută să rezolvi ceva. Referința este Manifestul Agile.
Ciprian Sorlea: Bogdan are dreptate. Sunt mult mai importante principiile acestea decât alte lucruri. Putem reduce lucrurile și mai simplu, dincolo de manifeste și porunci. Un principiu foarte bun este "Getting Shit Done", adică GeShiDo. Ai de rezolvat o problemă? Cum o poți rezolva într-un mod cât se poate de eficient, în contextul continuei schimbări la care ești supus? Frica de eșec din cultura românească vine din faptul că ne îndrăgostim foarte mult sau prea mult de soluția noastră, adică de ceea ce am creat. Cum spunea și Dan în prezentarea lui, trebuie să ne îndrăgostim de problemă, nu de soluție.
Cum stau lucrurile în Data Science?
Ioana Barboș: În Data Science, primul lucru pe care trebuie să îl învățăm este că este posibil ca, după ce ai lucrat 2-3 luni la ceva, să afli că nu există soluție la ceea ce vrei să faci. În domeniul nostru, se construiește reziliență la frustrare de pe băncile școlii. Când ești într-o companie unde trebuie să livrezi soluții promise clientului, iar tu ajungi să observi că nu se poate face, cum soluționezi așa ceva? Într-un astfel de context este normal să îți fie puțin frică de eșec.
Cum se adaptează metodologia Agile în zona de Data Science?
Ioana Barboș: Data Science este un domeniu cu o componentă foarte mare de explorare care merge foarte mult în direcția de cercetare. Acest lucru vine ca o completare la Manifestul Agile unde ni se spune că îmbrățișarea schimbării este esențială. În echipele unde am lucrat până acum, mereu ne împiedicam când trebuia să livrăm soluții. Cu Kanban niciodată nu livram la timp. Cu Scrum apărea frustrarea că unele taskuri nu puteau fi terminate într-o săptămână, deoarece era muncă de explorare. Am o echipă de trei persoane și am participat toți la un curs care să ne explice cum să aplicăm Agile. Momentan, încep și eu să mă bucur de beneficiile Agile, primul lucru fiind îmbrățișarea schimbării. În loc să ne gândim la obiectiv ca la un lucru fix ce poate fi terminat în X zile, folosim mărimile de la tricouri (S/M/L). Lucrăm cu iterații și folosim metrici care măsoară dacă produsul nou este mai bun decât cel anterior iterației. Am învățat să împărțim un task mare precum Train the Model în bucăți mai mici. Pe lângă Agile, am folosit principiile Data-Driven Scrum.
Dan Suciu: Studenții mereu mă întreabă dacă lucrurile se întâmplă chiar așa, dacă nu cumva lucrurile nu sunt sigure. De exemplu, o operație pe creier sau pe cord deschis este una complexă. Dacă întrebi chirurgul cât durează operația, înainte ca acesta să intre în sală, îți va spune că durează între 2 și 12 ore. Evident, chirurgul nu e la prima operație, dar problema este că, deși are RMN/CT/analize, tot nu cunoaște ce îl așteaptă în sala de operație. Multe lucruri le va afla în timpul operației și nu poate să își facă un plan de pe acum. Operația constă într-o serie de experimente cu feedback, sprint-feedback, situație-eroare. Nu avem manualul chirurgului pe creier sau cord care să poată fi urmărit pas cu pas.
Am moderat o discuție pe AI la o conferință la Sibiu. În public, era și un dentist foarte pasionat și l-am întrebat dacă oamenii trebuie să se mai spele pe dinți dacă își pun implanturi. Evident, răspunsul lui a fost DA. Ce minunat ar fi să existe cu adevărat o soluție la toate?
Ciprian Sorlea: Noi râdem, dar, la o operație pe creier, pacientul nu doarme și este rugat să vorbească sau să facă ceva pentru a nu se leza nervi. Asta înseamnă că și în medii extrem de sensibile, cum este operația pe creier, este foarte important să mergi din aproape în aproape și să ai feedback. Pe de altă parte, pentru orice facem trebuie să avem un experiment, deoarece acesta ne pregătește pentru lucrurile necunoscute. Experimentele reduc costul și frica de eșec. Multă lume compară ceea ce se întâmplă în IT cu primul zbor pe Lună. Oamenii nu au zburat pe Lună pentru că așa a spus Kennedy sau pentru că a dat un ordin, iar după șase ani a văzut rezultatele. Au fost foarte multe experimente și foarte multe eșecuri.
Dan Suciu: Cel mai bun exemplu este ceea ce a reușit să facă recent Elon Musk. În presă s-a scris că a fost un eșec de proporții, dar, de fapt, echipele testau dacă racheta se poate ridica de la sol. El se aștepta ca racheta să explodeze după ridicarea de la sol. Era o pierdere calculată, deoarece nu dorea să testeze ridicarea de la sol cu astronauți înăuntru. E un mod de lucru Agile.
Este toată lumea egală într-o echipă Agile?
Dan Suciu: Nu. Într-o echipă de fotbal este atacantul egal cu portarul? Fiecare parte a echipei (front end, back end, date, testare) are propria expertiză. Pe de altă parte, fiecare are cunoștințe pe orizontală despre ceea ce fac ceilalți. Când echipa de fotbal este atacată nu ne așteptăm ca atacantul să nu intervină. Nu ne așteptăm ca atacantul să stea deoparte și să zică "Eu sunt plătit doar să dau goluri".
Dar dacă ai o echipă de core unde toți fac același lucru? Uneori, este atât de multă democrație, încât un junior care poate că nu știe să facă un task, dar ia taskul considerând că este problema echipei să îl ajute să termine.
Bogdan Mureșan: Mie îmi place exemplul cu echipa de fotbal. Noi punem accentul pe echipe care pot să livreze cât mai ușor și independent un rezultat direct (un outcome direct). Care este outcome-ul unei echipe de fotbal? Să joace și să câștige. Pentru asta, trebuie să construiască, să se apere, să dea goluri. Tu când te referi la o echipă de core, te referi doar la o echipă de fundași. Noi nu construim echipele așa în IT, ci încercăm să acoperim toată zona de expertiză pentru ca meciul să fie câștigat. Dan a zis foarte bine. Pot exista situații când atacantul să apere sau portarul să dea gol în ultimul minut când miza este cea mai mare. Vor fi situații când va fi eliminat portarul, iar un jucător de câmp fără expertiza specifică, dar care lucrează în industrie să ia tricoul de portar și să apere. Putem induce spiritul de echipă când vedem că avem multe lucruri terminate, dar vedem că nu există suficiente resurse de testare și delegăm pe cineva să ajute acolo, chiar dacă nu e specialist. Dev-ul ia tricoul de testare și scrie niște teste automate ca să câștigăm meciul.
Ioana Barboș: Obiectivul la final de sprint/iterație este să ai în continuare un produs funcțional. Prin urmare, ai nevoie de mai multe abilități pentru a atinge acest obiectiv. În echipele de Data Science nu există doar persoane care fac modelare sau curățare de date, ci includ ML engineers, persoane care fac deployment, persoane care monitorizează modelele continuu. Tendința oricum este să creezi cross-functional teams.
Agile încurajează pe toată lumea să lucreze în echipă și le dă tuturor dreptul de a-și lua ce task doresc. Democrația aceasta nu omoară specializarea? Poate este bine să îți faci de cap în tot proiectul, dar omori unicitatea cuiva.
Dan Suciu: Faptul că poți nu înseamnă că ești obligat. Nu estimăm taskuri. Estimăm felii verticale ce funcționează cap-coadă. Un story presupune și front end, și back end, și testare. Dacă o echipă lucrează doar pe front end, atunci vorbim de silozuri care lucrează Waterfall.
Bogdan Mureșan: Nu se exclude că uneori nu poți să formezi nucleele sau echipele exact așa cum îți dorești. DevOps-ul este una din cele mai frecvente situații în care nu ar avea sens să existe un DevOps în fiecare echipă, deoarece nu ar avea omul ce să facă non-stop. Are sens să ai o echipă care să fie shared service între altele 8. Nu putem avea mereu doar echipe specializate sau doar cross-functional. Trebuie să ne adaptăm. Nu trebuie să ne uităm la cum este construită echipa, ci la cum putem livra o unitate de business cât mai rapid și cât mai ușor.
Cine are ownership la cod dacă toți au lucrat pe el?
Bogdan Mureșan: Depinde de structura organizației. În mod normal, ce livrează o echipă are ownership comun. Invariabil, în cadrul unei echipe, va exista un ownership involuntar pe servicii. Unii vor ști mai bine anumite bucăți, dar, dacă nu lași oamenii să intre la tine în bucătărie când este nevoie de fire power, greșești. Tai din time to market.
Agile nivelează sau taie din ownershipul omului?
Bogdan Mureșan: Eu văd lucrurile chiar invers. Face empowerment la fiecare om în parte.
Ciprian Sorlea: Agile este un spațiu de joacă. Îți creează un anume context și un anume nivel de siguranță. Dacă noi suntem o gașcă de huligani care face scandal sau un grup care dansează și joacă cărți, atunci importanți sunt oamenii din echipă, nu spațiul de joacă. Agile nu are legătură cu modul în care se comportă oamenii.
Ai lăsa un junior două zile pe un task ca să învețe, știind că poate fi făcut de un alt om într-o jumătate de oră?
Dan Suciu: Ai investit vreodată în ceva? Timp? Bani? Efort? Ai fost pus în situația de a conștientiza că acum îți este mai greu pentru a-ți fi mai bine sau mai ușor mai încolo? E posibil ca acum lucrurile să dureze puțin mai mult lăsând juniorul să lucreze, dar va fi mai bine pe viitor.
Ciprian Sorlea: Am citit recent un articol pe Medium care se numește "Choose Your Heart". Ca lider, indiferent cât de Agile este sau nu organizația ta, la un moment dat va trebuie să iei o decizie. Mergem pe varianta aceasta sau nu? Investesc în junior. Echipa poate este frustrată, dar iei decizia asta, deoarece nu vrei să îl lași să facă taskuri de rutină sau care îl fac să se simtă confortabil. O altă decizie ține de ce te faci cu un modul pe care a lucrat un super senior care le știa pe toate și care a plecat. Ce se întâmplă dacă mă lasă cu juniorul pe care l-am ținut departe de acel cod? Dacă timp de X ani, până când a plecat acel senior, juniorul a crescut sub aripa lui și a învățat, atunci ești într-un loc mult mai bun. Poți produce și în timp ce înveți.
(întrebare din public): Ce se întâmplă când ai un client care se răzgândește mereu? Cum îi spui că ar fi bine să își facă un plan?
Bogdan Mureșan: Am avut multe situații de acest gen. Clientul nu avea nicio treabă cu Agile-ul. Aveam și un deadline. Era un produs universitar. Soluția cea mai simplă a fost să îi arătăm după fiecare iterație un delta. Uite ce ai vrut data trecută, uite cum vrei să schimbi, uite cum îți afectează produsul. Uite cum se schimbă produsul dacă adaugi aceste detalii. După 6-7 iterații a înțeles. Pentru acest client, limbajul comun a fost vizualizarea impactului sub formă de delta. Pentru alții, e mai util să exprimi totul în termeni de costuri.
Ciprian Sorlea: Poate exista un Product Owner, un Business Analyst care să preia din dialogul cu clientul, care să îmbunătățească relația cu clientul. Se poate apela inclusiv la experiență din exteriorul echipei. Pe mine m-a ajutat Impact Estimation Table.
Ovidiu Mățan: De ce nu avem un produs bazat pe AI care să colecteze datele tuturor echipelor Agile din lume, iar apoi când facem ceva să fim atenționați, dacă nu lucrăm în conformitate cu principiile Agile? Lăsăm această întrebare deschisă.