Marile sperante ale unei implementari de agile software development

Reading Time: 5 minutes

trial-and-error
Va propun o analiza rapida a beneficiilor principale, atat pentru business cat si pentru echipa, a transformarilor aduse de implementarea metodelor de lucru agile in organizatii care dezvolta produse software.

Consider ca lista de mai jos nu este exhaustiva, iar drumul pana la obtinerea acestor beneficii este un process de incercare-eroare, “trial and error”. Obiectivele mai specifice, ce pot deriva din aceste beneficii, trebuie evaluate la ceva timp dupa implementare, si nu imediat sau in timpul invatarii sau momentelor de debut.

Vom vedea mai jos, beneficiile pe care dorim sa le obtinem prin trecerea la dezvoltarea agila a produselor noastre software, si cum vom putea masura atingerea lor, odata ce tranzitia e realizata.

Analiza are ca baza experienta catorva implementari, in organizatii care nu practicasera anterior o metoda/metodologie definita ca agila si care in mod constient si autonom au decis la un moment dat sa o faca.

Trebuie spus de la bun inceput ca in cele mai multe cazuri, sau mai bine zis, in cele mai de succes cazuri, tranzitia la un mod de lucru agil se face datorita deciziei manageriale, luata de oamenii din varful organizatiei. Paradoxal, ati putea spune, daca luam in calcul ca in mod obisnuit, vedem ca promotori interni ai modului de lucru agil pe cei ce sunt de obicei oamenii din echipa, pe cei care lucreaza efectiv zi de zi la realizarea produsului, cei care si practica “agilitatea”.

Ne asteptam deci sa vedem in enumerarea de mai jos beneficii pentru ambele categoii – business si echipa.

Iata-le, intr-o ordine aleatoare:

1. Livrari mai rapide, clienti mai fericiti

Livrarile in medii de lucru agile sunt caracterizate ca “iterative” si “incrementale” si se bucura in primul rand de faptul ca ofera “ceva” clientului in mod frecvent, si ca acel “ceva” poate fi deja validat de client si chiar folosit in business, exploatat, cu mult inaintea momentului cand intregul produs va fi finalizat.

OK, livrabilul intermediar, obtinut in mod incremental, nu reprezinta solutia finala, cu intregul set de cerinte sau cu intregul “scope” implementat, nici nu are toata valoarea de business asteptata de la un produs finit, dar in mod evident clientul primeste acel “ceva” mult mai repede, il valideaza, il corecteaza daca e necesar, reducand durata buclei de feedback de la jumatati de an sau ani la cateva saptamani.

Si daca acel “ceva” a fost si suficient de bine prioritizat, incat sa aiba importanta maxima la momentul livrarii, clientul poate avea, sa zicem, un feature critic, livrat intr-o fractiune de timp din cel necesar dezvoltarii intregului produs.

Masurare: cel mai usor prin “lead time”, adica timpul pe care un client il are de asteptat intre formularea unei cerinte si primirea implementarii corespunzatoare ei. Considerati pentru masuratoare cerinte relevante, cu importanta crescuta pentru client.

2. Deschidere, transparenta, vizibilitate

Cele mai multe piedici puse in calea rezolvarii problemelor din proiectele tehnice o reprezinta lipsa informatiilor relevante, care ar trebui sa fie expuse cat mai bine, publicate atat intern cat si catre decidentii de business, catre client.

Acest lucru este adresat de catre   metodele agile, prin modelul lor “empiric” de control al procesului de dezvoltare, pe care il folosesc – expun informatiile din timp, pe parcurs, catre toti cei implicati.

Astfel, daca o parte a informatiilor se dovedeste falsa, neverificata sau inutila, se pot lua actiunile corective cat mai devreme.

Expunerea informatiilor relevante se face in dublu sens: dinspre business catre echipa prin publicarea cerintelor de dezvoltare (roadmap, backlog de produs, conditii de business) intr-un mod deschis si complet si invers, dinspre echipa catre business si client a artefactelor de lucru (task boards, information radiators, liste de defecte, masuratori de performanta sau de acoperire a gradului de testare, etc.)

Masurarea atingerii acestui beneficiu se poate face periodic, analizand gradul de disponibilitate a informatiilor enumerate mai sus, catre toate categoriile de stakeholderi ai proiectului.

3. Autonomia echipei

Un castig major dupa o implementare agile de succes il reprezinta crearea unei echipe autonome, auto-organizate, care nu asteapta initiative externe pentru rezolvarea problemelor, ci intervine proactiv pentru a inlatura propriile blocaje si gaseste solutii inovatoare care duc la progres.

Putem masura autonomia astfel: Cate din lucrurile sesizate de echipa ca necesitand schimbari sunt abordate, modificate, imbunatatite, cu adevarat? Si cate sunt doar discutate si trecute in revista, fara ca echipa sa actionize pentru imbunatatirea lor?

Pe termen lung, o echipa autonoma isi mareste capacitatea si viteza de a rezolva nu numai probleme ale produsului dezvoltat, ci si probleme de organizare, de lipsa sau optimizarea uneltelor tehnice, probleme de process sau chiar legate de proprii membri care pot avea cerinte sau nevoi individuale speciale.

4. Motivarea

Beneficiul legat de motivare nu se refera doar la echipa, asa cum ar putea fi usor de presupus. El se refera si la client, sau la reprezentantii lui din zona de business a organizatiei.

In ceeea ce priveste motivarea echipei, ca rezultat al abordarii de lucru agile, lucrurile sunt intr-adevar mai evidente, pentru ca putem puncta foarte usor factorii din care ea decurge: implicarea membrilor echipei in “de ce?”-ul de business al fiecarei dezvoltari, practica de a da, individual, propriile estimari pentru fiecare dezvoltare, propunerea propriilor solutii de implementare pentru rezolvarea unei cerinte, si practica de a ajusta cu colegii de echipa propriul process de lucru in mod continuu, vizand imbunatatirea continua a procesului intern.

Celalalt aspect care intervine este motivarea clientului si a partii responsabile de business-ul organizatiei, care apare ca rezultat al interactiunii frecvente a acestora cu echipa. Faptul ca ei justifica echipei nevoia de business, le explica problemele si valideaza solutiile prezentate ii aduce mult mai aproape de asumarea responsabilitatii de decizie a “CE” se va implementa in produs. Daca constiinta responsabilitatii este sau nu un factor motivator, va las pe voi sa judecati.

Masurarea motivarii echipei, desi tipic implementata de catre departamentele de HR ca masurare periodica a angajamentului angajatilor, sub forma unor survey-uri, poate fi facuta si altfel, la cald, in intalnirile echipei, formale si non-formale, sau ca rezultanta a intalnirilor periodice de retrospectiva.

Motivarea clientul in a colabora cu organizatia care dezvolta produsul se poate masura intr-o sesiune de feedback despre produs si despre colaborarea cu echipa, sau printr-un classic survey Net Promoter Score, colectat impreuna cu comentariile pe care clientul le lasa, pe langa punctarea anumitor criterii.

5. Cresterea potentialului uman prin multi-discplinaritate

Stim bine ca echipele de lucru agile sunt multi-disciplinare, adica au in componenta toate acele skilluri din arii diferite (programare, testare, analiza de business, design, etc.), care puse cap la cap dau posibilitatea echipei sa realizeze o solutie completa.

Beneficiul multi-disciplinaritatii se rasfrange insa si la nivel personal, nu doar la cel al echipei. Din interactiunea frecventa cu expertii pe fiecare domeniu in parte, fiecare membru al echipei devine un “multi-skilled worker”. Si de aici deriva si alte beneficii secundare.

Masurarea se face periodic prin colectarea informatiilor despre performantele individuale, pe care oricum un process obisnuit de HR le presupune, cu accent pe zonele in care membrul de echipa a capatat competente noi si pe care in viitor vrea sa le aprofundeze. Detectate la timp, aceste skilluri cross-disciplinare dobandite, pot inscrie membrul de echipa pe o alta directie de dezvoltare a carierei sau spre oportunitati noi (proiecte si zone din organizatie care au nevoie de o asemenea expertiza).

 

In concluzie, acestea sunt doar 5 beneficii, privite din perspectiva organizatiei dar si a membrilor de echipa, pe care implementarea modului de lucru agile le aduce, recomandate si pentru evaluare a succesului, odata ce implementarea a prins contur. Lansez si o intrebare si o invitatie la un schimb de idei: Care e experienta voastra practica cu masurarea lor?

Rating: 5.0/5. From 8 votes.
Please wait...

Leave a Reply

Your email address will not be published. Required fields are marked *