Ovidiu Măţan: Vorbim cu Henrik Kniberg din Suedia. Salut, Henrik. Am urmărit prezentarea ta despre Agile. A fost foarte interesantă. Graficul despre valoare vs. Efort mi s-a părut foarte elocvent. În proiectele tradiţionale, ne axăm pe cât de mult muncesc oamenii sau pe cât produc, dar nu pe valoarea a ceea ce produc. Le puteţi spune cititorilor mai multe despre acest lucru?
Henrik Kniberg: Vorbind de această tendinţă, am constat că multe proiecte și organizaţii se axează pe rapoarte ce ţin de gestionarea timpului sau de utilizarea resurselor. Există o preocupare ca oamenii să fie ocupaţi să facă ceva. Nu este un mod productiv de a ne raporta la un anumit produs dacă lucrezi într-un domeniu complex, deoarece, dacă găsiţi o persoană care rezolvă problema în jumătate din timp, este mai bine. Este mai bine ca o persoană să lucreze mai puţin. Când aplicaţi o metodă precum Scrum care este populară, veţi ieși din acest mod de gândire. Scrum se centrează pe viteză/velocity. Măsuraţi cât produceţi într-un sprint, nu câte ore petrec oamenii făcând lucruri. Deci, metodele Scrum și Agile te fac să nu te mai orientezi pe efort, ci pe rezultat. Kanban se axează pe timpul petrecut de la un capăt la altul. În Scrum, Agile și Kanban, te uiţi la activitatea în sine, nu la numărul de ore petrecute, ceea ce este un pas în direcţia cea bună, dar multe companii se opresc aici. Doresc să evidenţiez că cele mai de succes companii pe care le-am văzut, duc totul un pas mai departe și spun: "De ce să îmi pese de viteză? Aici am o echipă cu velocitate mai mică decât cealaltă echipă, dar prima echipă aduce mai multă valoare. A reușit să rezolve problema clientului cu mai puţine feature-uri." Acesta este genul de evoluţie pe care îl constat și pe care vreau să îl promovez.
Ovidiu Măţan: Cum se măsoară valoarea? Cum pot oamenii deveni conștienţi de valoarea unui task? Cum își aleg oamenii taskuri?
Henrik Kniberg: Aceasta este una din provocări. Faptul că este un lucru mai greu de capturat ne face să ne bazăm pe măsurarea orelor sau a vitezei, deoarece este mai ușor. Valoarea este mai dificil de măsurat, dar nu este știinţă atomică. Putem să ne uităm cum o fac celelalte companii. Spotify, o companie cu care petrec mult timp, se axează pe utilizatorii activi per lună (monthly active users sau MAU) și observă în ce măsură, dacă facem un feature așa sau altfel, există vreun efect asupra modului în care se folosește produsul. Trebuie investit în infrastructură pentru acest lucru. Dacă este vorba de un proiect software, nu este atât de greu, deoarece puteţi măsura acest lucru. Dacă este vorba de un produs web, este ușor. Sunt multe tooluri pentru asta, dar acesta este doar un prim aspect. Reversul medaliei este mai personal. Asiguraţi-vă că cei care construiesc produsul iau contactul cu utilizatorii reali. Ar putea să lucreze la suport pentru a vedea care sunt plângerile utilizatorilor. Ar putea vedea niște videouri cu utilizatori noi care încearcă să utilizeze produsul. Astfel, programatorii pot înţelege cine sunt utilizatorii și unde au ei probleme. Acei programatori vor avea în vedere mai mult problemele utilizatorilor.
Ovidiu Măţan: Aţi devenit mai cunoscut odată cu modelul Spotify. Ne spuneţi mai multe despre acesta?
Henrik Kniberg: Nu am creat modelul Spotify, dar am ajutat la definirea acestuia. Fac parte din organizaţie de ceva vreme și sunt fascinat de cultura acesteia. Este prima companie cu o cultură Agile autentică. Nu totul este perfect Agile, dar cultura companiei are la bază Agile. Această abordare s-a răspândit deoarece îi inspiră pe oameni. La Spotify totul este orientat spre autonomie și încredere, dând echipelor abilitatea de a lua decizii. Acest lucru este atractiv pentru oameni. Companiile care activează în domenii complexe, într-o lume în schimbare, își dau seama că metoda comandă-control este un mod decizional de sus în jos care nu este potrivit deoarece este prea lent.
Ovidiu Măţan: În ce proiecte nu se aplică Agile?
Henrik Kniberg: M-aș uita la complexitate. Proiectele simple sau repetitive (creaţi campanii web, vreo 20 pe săptămână) nu au nevoie de Agile deoarece orice ai face, acel lucru probabil funcţionează deja. Dacă lucrezi într-un domeniu complex unde nevoile clientului sunt neclare sau unde tehnologia este neclară sau tinde să se schimbe, chiar ai nevoie de Agile. M-aș uita la complexitate.
Ovidiu Măţan: Ne-aţi dat un exemplu cu copii și voluntari pentru a ne arăta ce înseamnă a avea resurse. Ne-aţi arătat diferenţa dintre o autostradă blocată și una normală.
Henrik Kniberg: Acel demo ne arată ce se întâmplă când ne axăm pe a ţine oamenii ocupaţi. Același lucru se întâmplă pe o autostradă plină de mașini. Am vrut să demonstrez această greșeală mentală. Dacă îngheţaţi imaginea plină de mașini a unei autostrăzi, totul pare eficient. Aţi umplut autostrada cu mașini și funcţionează 100%. Este grozav, dar orice programator știe că a folosi procesorul la 100% este foarte rău. Totul este folosit eficient, dar totul este lent, deci nu ne dorim așa ceva. Principiul "pull" (tragere) rezolvă blocajul într-o anume măsură. De exemplu, în Scrum, la Sprint planning meeting, echipa trage niște stories din backlog. Dacă trag prea multe, nu vor termina munca. Vor învăţa din aceasta, iar data viitoare vor trage mai puţin. Totul devine un sistem care se ajustează pe parcurs, ca să ai suficiente elemente într-un sprint. Trebuie limitat numărul mașinilor de pe autostradă. Nu folosiţi "primul venit, primul servit". Stabiliți prioritățile în funcţie de valoare.
Ovidiu Măţan: Ne-aţi dat exemplul avionului realizat cu metodologia Agile. Acesta nu este un proiect IT, dar este complex. Cum s-a aplicat metodologia în acest caz?
Henrik Kniberg: Nu am lucrat la acel proiect, dar am vizitat echipa timp de o zi. Am citit și un articol despre proiect. Informaţia mea e limitată, dar ce am văzut m-a surprins, deoarece este cel mai de succes proiect de avioane de luptă realizat vreodată ca performanţă și preţ. Toţi membrii echipei au devenit colocatari și toţi au folosit Scrum, chiar și cei de la fuselaj sau achiziţii. Piloţii au conlocuit cu echipele, deci piloţii încercau software-ul scris de echipă în aceeași zi. Echipa a primit feedback foarte repede. Cel mai important factor care a contribuit la succes a fost colocaţia, Scrum cu feedback rapid și piloţi încercând software-ul zilnic. Un avion de luptă conţine mult software.
Ovidiu Măţan: La final, ne-aţi dat un exemplu cu modul în care aţi organizat un barbecue acasă. Aţi făcut o listă cu ce trebuie făcut, iar invitaţii au ales ce doresc să facă. Cum se compară această experienţă cu modul tradiţional de a le spune oamenilor ce este de făcut?
Henrik Kniberg: Am experienţă cu petrecerile barbecue la mine acasă. Am încercat multe modele, inclusiv comandă și control. Am organizat o petrecere barbecue și am avut mai mulţi invitaţi decât m-am așeptat. Mi-am dat seama că planul meu iniţial nu va ţine, deci am făcut un panou Scrum a ceea ce vrem pe masă (carne, fructe, băuturi) după priorităţi. Invitaţii au ajuns. I-am rugat să se grupeze, să pună un carton, să facă acel lucru și să apeleze la mine dacă au nevoie de ceva. Eram precum un Scrum master. Nu le spuneam oamenilor ce să facă. Oamenii s-au organizat. Funcţionează surprinzător de bine. Inivitaţilor li se pare distractiv. Iau taskuri distractive, toţi au același scop, iar eu nu trebuie să controlez oamenii. Eu doar îi ajut, deci este ca un model servant-leadership. De asemenea, mi-a dat mai mult timp de socializare.
Ovidiu Măţan: Voi încerca și eu. În ce a constat hackingul?
Henrik Kniberg: Erau mulţi copii mici la petrecere. Ei se uitau la panou, la adulţi și se întrebau ce se întâmplă. Copiilor li s-a aprins becul: tot ce apare pe panou chiar se întâmplă. Copiii au hăckuit sistemul. Au pus bileţele cu îngheţată. Adulţii au fost nevoiţi să aducă îngheţată. A fost un moment "Aha" pentru mine, deoarece principiile Agile sunt foarte puternice. Chiar și un copil de trei ani a înţeles aceasta fără explicaţii.
Ovidiu Măţan: Mulţumesc foarte mult, Henrik.
Henrik Kniberg: Mulţumesc.
de Ovidiu Mățan
de Dan Sabadis
