În perioada pe care o trăim în SW development/testing, cuvintele Agile și Scrum au devenit un fel de standard deja subînțeles și asimilat în rutina cotidiană ca și cafeaua de dimineață.
Faptul că ne-am obișnuit cu un anumit comportament/obicei nu înseamnă că ne este de folos. Să ne gândim doar la viciile pe care le perpetuăm zilnic. Să nu mă înțelegeți greșit, nu sunt un om contra Agile. Sub nicio formă! De fapt, sunt un mare pasionat de tot ceea ce ne poate oferi Agile-ul. Mai precis: fac daily-uri, fac planning, fac refinement și Demo. Deci sunt Agile.
Din păcate, trebuie să recunoaștem că în foarte multe echipe s-a ajuns la nivelul în care cuvântul Agile a primit o conotație negativă ca și acele meetinguri de status/reporting pe care le avem cu toții în calendar.
Sper că nu v-am pierdut deja…
În rândurile de mai jos, voi încerca să vă conving că situația privind atitudinea față de Agile poate fi îmbunătățită. Trebuie doar să fim atenți la anumite aspecte. Este de menționat că tot ceea ce propun ca subiect de gândire sunt ideile mele personale. Adică, sunt "alterate" de subiectivism.
Să ne întoarcem un pic în istorie și să vedem de ce au apărut frameworkurile Agile.Conceptul Agile-ul a apărut dintr-o necesitate. A fost răspunsul domeniului IT la cerințele clienților. Cred că este foarte important să înțelegem că, la fel cum apariția Agile-ului a fost dintr-o necesitate dată de contextul de business, evoluția modului de lucru sub "umbrela Agile" este o nevoie la fel de mare. Să ne uităm doar la câte frameworkuri au apărut de-a lungul timpului: Scrum, Kanban, Lean, XP (și nici nu am intrat în cele scaled precum, Scrum of Scrums, LeSS, SAFe).
Faptul că etichetăm o echipă ca echipa de Scrum care aplică Scrum, dar în realitate folosește doar părți din framework este ca și cum mi-aș pune în frunte numele de "George Clooney" și să mă aștept la faimă.
Cred că ar trebui să ne concentrăm mai mult pe accentuarea practicilor care s-au dovedit a fi utile și să scăpăm cât mai rapid de acelea care nu ne ajută, fiind nocive echipei. Cred că este mai important să ai un proces/framework adaptat echipei/contextului tău decât să folosești "ca la carte" un framework care te ajută cu unele practici, dar cu altele te trage în jos. Mai mult de atât, cred ferm în deschiderea către a încerca diferite abordări/practici cu dorința de a îmbunătăți viața de zi cu zi și randamentul echipei. Ai încercat ceva și a mers? Super! keep doing it. Ai încercat ceva și nu a mers? Și mai bine. Aruncă-l în coșul de gunoi și treci mai departe la următorul experiment. Fail fast and fail often.
Și aici nu mă refer doar la feedbackul primit de la client. M-aș concentra mai mult pe feedbackul primit de la echipă. Cu toții ar trebui să ne străduim să creăm un context în care toți să își poată exprima părerea liber și fără prejudecăți. Un element esențial ar fi meetingurile de Retro. Din confort sau din alte circumstanțe putem să picăm în capcana în care să repetăm același tip de Retro de n ori în speranța să dea același rezultat ca și la prima sau a doua încercare. Să nu ne fie frică să încercăm mai multe variații și tipuri de Retro-uri ca să menținem fluxul de informații.
Dar primirea feedbackului este doar primul pas. Fixarea de action itemuri bazate pe feedbackul primit și făcând follow up la aceste action itemuri este de fapt pasul esențial în a menține un flow de idei utile.
Să vedem câteva exemple:
Daily-urile au tendința să se lungească în discuții tehnice. De aceea, încurajați echipa să scoată discuțiile dintre câțiva membri în afara daily-ului.
Refinementul se poate îmbunătăți cu tehnica de 3 Amigos. Dacă vreți să duceți practica la următorul nivel, încercați să schimbați continuu echipele de 3 Amigos și să selectați oameni de diferite seniorități.
De multe ori ceea ce este perfect logic pentru mine, poate fi o "povară" pentru echipă. Trebuie să fim atenți la pulsul echipei și să promovăm un mediu sincer în care oricine să poată să spună "nu îmi place X, pentru că Y și aș dori să propun Z, pentru că W". Aceste elemente trebuie discutate și evaluate împreună.
Deși mediul nostru de lucru este unul foarte dinamic, este bine să setăm niște standarde. Să mergem înapoi la una din rădăcinile unei activități de lucru, mai precis la taskurile pe care lucrăm. Din experiența mea, am remarcat că ceea ce îmbunătățește mult flow-ul de lucru este să ai niște tichete clare, formatate într-un mod similar (cu description, acceptance criteria, notes, linkuri etc.). Aici fiecare dintre voi puteți să stabiliți niște template-uri după care să poată lucra echipa. Desigur, astea s-ar încadra foarte bine într-un DoR (Definition of Ready) clar definit.
Să nu uităm că suntem oameni și lucrăm cu oameni. Nu suntem niște mașinării care să răspundă de fiecare dată la fel la același stimul. Avem zile mai bune, mai rele și trebuie să ținem cont de asta. Să nu uităm că încrederea se construiește încet, cu multă sinceritate și transparență. Doar că aceasta se poate pierde instant.
În cazul echipelor nou formate aflate încă în stadiul de forming poate ajuta un Way of working cu niște reguli de bază. Acestea pot încorpora așteptările pe care le avem unul față de altul, cine este responsabil pentru ce, de câte review-uri ai nevoie la un PR și multe altele. Gândiți-vă ca și la niște reguli de joc. Astea pot ajuta mult atât în ameliorarea conflictelor din zone de Storming, cât și în setarea unui baseline de comportament pentru echipă.
Și nu în ultimul rând, să nu uităm să ne conectăm cu echipa și să creștem relații. Din punctul meu de vedere, aceasta este una din cele mai grele aspecte cu acest nou stil de muncă remote/hibrid. La fel ca toate lucrurile bune din Agile, putem găsi rețeta ideală numai prin trial and error. Câteva opțiuni pot fi calluri de Cofee break, Jocuri online sau pur și simplu un meeting unde să stați la povești.
de Nóra Dobre
