Studii de caz - Agile pus în practică

Adina Chiriliuc
Scrum Master @ Centrul de Inginerie Bosch



Valeria Guțu
Configuration Manager @ Centrul de Inginerie Bosch



Daiana-Emanuela Mureșan
Machine Learning Engineer @ Centrul de Inginerie Bosch

În mediul tehnologic aflat în permanentă schimbare, a sta pe loc nu mai este de mult timp o opțiune. Domeniul software se dezvoltă cu viteze amețitoare, aducând provocări și oportunități în permanență. Atenția oamenilor este atrasă în direcții multiple, spre instrumente de lucru de ultimă generație, spre inovații, spre experimente.

Dacă viteza și calitatea sunt două ingrediente de bază din orice produs software, cum putem găsi compromisul, rețeta secretă care să le permită oamenilor să se adapteze cu ușurință și să livreze soluții de calitate în cel mai scurt timp posibil, reușind, în același timp, să învețe și să se preocupe de dezvoltarea personală? Așa cum a spus Jeff Sutherland: "Agile nu este un simplu set de practici, ci o călătorie." ("Agile is not just a set of practices, it's a journey"). Nu vorbim de o rețetă secretă ce funcționează pentru toată lumea, ci de un mod de gândire care ne conduce spre succes.

Analizând poveștile celor ce au adoptat Agile, atât raportat la victorii, cât și la provocări, putem descoperi ce înseamnă cu adevărat să fii Agile în ziua de azi.

Studiu de caz 1: Cum să gestionezi o implementare Agile

Libertatea de a dezvolta, transparența, munca în echipă, încrederea - toate sună bine, nu-i așa? Dar ce se întâmplă când Agile este prost înțeles, iar puterea de atracție a vechilor obiceiuri disfuncționale este mai puternică decât noile principii implementate? Cum pot fi rezolvate problemele ce apar și cum putem gestiona o cultură organizațională benefică atât pentru programatori, cât și pentru factorii decizionali?

În calitate de factor decizional, dl. Green decide să implementeze Agile, dornic să crească productivitatea. S-a bucurat de fiecare ședință stand-up, solicitând insistent membrilor echipei ultimele noutăți și transformând ședințele scurte în întâlniri chinuitoare, de durată. Obsedat de instrumentele de lucru folosite, dl. Green a dorit să primească date meticuloase despre evoluția progresului, toate înregistrate într-un sistem nou de management de proiect, această activitate devenind esențială și obligatorie pentru fiecare membru al echipei. Frustrarea a crescut, deoarece programatorii petreceau mai mult timp în ședințe și în sisteme de management decât muncind efectiv.

Sursă: https://mooncamp.com/blog/agile-mindset/

Într-o zi, Jane, Scrum Master senior, și-a expus îngrijorările: "Domnule Green, se pune mult prea mult accent pe partea de management de detalii și simțim că nu aveți încredere în noi. Acesta nu este Agile." Contrar fricii multora din echipă, Jane nu a fost concediată a doua zi.

Dl. Green, luat prin surprindere de mărturia angajatei, a conștientizat realitatea. Și-a reevaluat abordarea, înțelegând că Agile presupune încredere și autonomie. Au avut loc schimbări, iar echipa a început din nou să aibă succes și siguranță.

Este nevoie de mult curaj pentru a avea încredere în cineva. La un moment dat în carieră, Jane a fost avertizată că are o relație mult prea prietenoasă cu echipa ei. "Ești mai mult un prieten decât un Scrum Master, Jane! Trebuie să îi determini să facă lucruri; trebuie să te respecte!" Totuși, toate studiile au arătat că este esențial să construim relații puternice și să manifestăm respect. Doar așa pot indivizii să crească, iar rezultatul muncii lor să devină evident și să inspire încredere în proiecte viitoare.

Povestea dlui. Green și a lui Jane ilustrează echilibrul delicat ce trebuie menținut când implementăm Agile. Trebuie să mergem dincolo de implementarea unei proceduri - e nevoie de o schimbare culturală cu accent pe încredere, încurajare și respect. Factorii decizionali și liderii trebuie să învețe să se retragă puțin și să ofere echipelor libertatea de a inova și de a rezolva probleme.

Lecțiile sunt clare: managementul detaliilor (micromanagementul) omoară creativitatea și productivitatea, în timp ce practicile Agile adevărate duc la o echipă cu adevărat performantă, eficientă și motivată. Confruntate cu complexitățile Agile, companiile trebuie să pună accentul pe creșterea unui mediu de lucru unde atât programatorii, cât și factorii decizionali se simt apreciați și demni de încredere. Doar așa putem beneficia de potențialul Agile și să obținem succes sustenabil și inovație.

Studiu de caz 2: Lecții de la CodingMonkeys Inc.

CodingMonkeys Inc., o companie software recent înființată, a inițiat un proiect ambițios care ar fi trebuit finalizat în 6 luni. Aflată la debut în industrie, obiectivul principal al acestei companii a fost să livreze valoare cât de repede posibil. Inițial, acest mediu aflat sub presiune a avut succes. Totuși, pe parcursul unui an, compania s-a confruntat cu provocări majore care au dus la decăderea acesteia. La început, accentul pus pe livrarea rapidă părea a fi eficient. Programatorii au repectat termenele stricte de livrare pentru primul proiect, iar compania a menținut această abordare pe parcursul întregului an. Totuși, cu trecerea timpului, au apărut fisuri. Presiunea continuă a afectat echipa, ducând la burnout și la scăderea calității.

În ciuda faptului că s-a aderat la majoritatea ceremoniilor Agile, CodingMonkeys Inc. a neglijat importanța ședințelor retrospective. Această ședință din urmă, deși foarte importantă, a fost considerată o formalitate fără efect. Lipsa unui mediu sigur pentru comunicare deschisă a însemnat că programatorii nu puteau să își expună îngrijorările și nu puteau să își implementeze ideile. Feedbackul de la membrii echipei a primit prioritate redusă, ceea ce a dus la un moral scăzut. Planurile ambițioase ale Product Ownerului, combinate cu presiunea constantă de a livra a dus la termene limită ratate. Lipsa comunicării eficiente și a ascultării active au condus la o echipă deconectată. Colaborarea și inovația au fost sufocate, exacerbând și mai mult problemele companiei.

Experiența CodingMonkeys Inc. subliniază rolul principal al siguranței psihologice și al unui mediu ghidat de feedback. Prioritizarea oamenilor și a comunicării deschise sunt esențiale pentru succesul pe termen lung. Decăderea CodingMonkeys Inc. reprezintă un avertisment referitor la nevoia de a crea un spațiu sigur în care programatorii să își exprime ideile și să le transpună în practică, indiferent cât de minuțios sunt respectate procesele Agile.

Pentru ca Agile să fie cu adevărat eficient, trebuie să mergem dincolo de proceduri. E nevoie de o cultură care valorifică și implementează feedbackul, care oferă siguranță psihologică și care privilegiază bunăstarea echipei. Doar așa poate o echipă să obțină succes sustenabil și să evite capcanele în care au căzut cei de la CodingMonkeys Inc.

Studiu de caz 3: Aderarea la ceremoniile Agile

Echipa unei companii de dezvoltare software a înțeles greșit importanța ceremoniilor Agile, considerând etapa backlog refinement ca fiind una evidentă ce nu are nevoie de mult timp de lucru, mai mult o sarcină de lucru individuală decât un efort colaborativ. Ședința era văzută drept o pierdere de timp, ceea ce a dus la un backlog învechit cu priorități prost definite și cu multe informații lipsă. Similar, ședințele de planificare erau grăbite, cu taskuri asignate la întâmplare și fără obiective clar definite pentru fiecare sprint. Tot acest context a dus la confuzie, deoarece echipa s-a confruntat cu probleme în înțelegerea clară a specificațiilor, ceea ce a dus la termene de livrare ratate și la mult prea multe ședințe de clarificare a situației.

Această abordare haotică a dus la eficiență scăzută, frustrare și eșec în prioritizarea taskurilor. Factorii decizionali s-au confruntat cu calitate imprevizibilă și livrare întârziată. Pentru a rezolva aceste probleme, membrii Scrum Master și Product Owner au introdus gradual modul de gândire Agile, subliniind importanța etapei backlog refinement și a ședințelor de planificare. Au asigurat îmbunătățiri incrementale prin retrospective frecvente și prin reacții constructive la feedback. Această abordare structurată a ajutat echipa să se alinieze, să devină mai eficientă și să livreze predictibil.

Anterior, colegii din Germania, implicați în proiect de la început au constatat că multe schimbări aveau nevoie de input din partea lor, ducând la întârzieri de prioritizare și la lipsă de transparență în privința efortului lor de a prioritiza taskurile. Introducerea metodologiei Agile a adus claritate în prioritizare și a permis marcarea anumitor taskuri ca fiind blocante sau fiind rezervă de lucru dacă apăreau provocări spontane.

Acum organizăm ședințe de planificare PI pentru a pregăti cele mai importante taskuri pentru următoarele 3 sprinturi și pentru a defini taskuri "blocante" pentru activități neplanificate. Estimarea punctelor a devenit mai eficientă utilizând șabloane, ceea ce ne permite să comparăm și să prezicem durata unui task cu precizie. Analiza sprinturilor anterioare ne-a permis să ne ajustăm capacitatea de lucru și să alocăm resursele acolo sunt cu adevărat necesare. Per total, Agile a făcut fluxul nostru de lucru mai transparent, mai eficient, mai adaptabil.

Acum, a devenit clar cât de mult poate Agile să îmbunătățească munca noastră. Dar cum am putea face tranziția de la Waterfall? Nu există o rețetă secretă general valabilă; este vorba de un nou mod de gândire care ne duce la succes. A face schimbarea de la o metodologie Waterfall la una Agile presupune adoptarea de noi practici, dar și susținere pentru o schimbare la nivel de cultură organizațională. Tranziția presupune flexibilitate, colaborare și deschidere spre procese iterative.

La Bosch, tranziția spre stilul de lucru Agile exemplifică atât beneficiile, cât și obstacolele acestei schimbări semnificative. Managementul a avut un rol cheie, oferind training, susținere și un cadru general de tranziție. Astfel, au fost create contexte specifice la nivel de proiect pentru a implementa noua metodologie de lucru în vederea unei tranziții cât mai naturale. Punând accent pe comunicarea clară, educarea continuă și adaptarea pe bază de feedback, Bosch a făcut față cu succes complexității ce vine cu o astfel de transformare, ceea ce a dus la un flux de lucru mai eficient și mai adaptabil la schimbare.

Una dintre cele mai benefice schimbări a fost introducerea retrospectivelor după fiecare sprint. Aceste ședințe au adus claritate cu privire la situația curentă a proiectului, scoțând la iveală probleme și oferind multe soluții. Retrospectivele ne-au permis să identificăm și să eliminăm activitățile și comportamente care nu erau necesare, fluidizând procesele.

A devenit clar că membrii echipei doreau să ofere feedback, să aducă inovații și să propună soluții. Deschiderea lor la schimbare și adaptabilitatea au îmbunătățit performanța generală a echipei. O altă schimbare pozitivă a fost mutarea accentului de pe metrici individuale pe metrici de echipă. Acest lucru a încurajat colaborarea și suportul reciproc. S-a înțeles că rezultatele individuale contează mai puțin dacă echipa nu performează în ansamblu. Retrospectivele regulate au dus la eliminarea activităților nedorite în beneficiul celor eficiente.

Provocările aderării la paradigma Agile

Aderarea la paradigma Agile a adus îmbunătățiri semnificative, aducând însă și provocări multiple. Tranziția spre Agile nu a fost lipsită de întrebări. O problemă semnificativă a fost durata mare a procesului de implementare, ceea ce a presupus multe ședințe și mult timp petrecut în contorizarea timpului de lucru, dar și a estimărilor. Pentru a depăși această situație, ne-am axat pe înțelegerea scopului fiecărei activități din metodologia Agile. Dacă o activitate nu se potrivea echipei noastre, o eliminam. Am învățat că nu putem aplica Agile pur în mod universal, tuturor echipelor și tuturor situațiilor. A reprezentat o provocare să lucrăm pe proiecte și cu echipe aflate pe mai multe continente. Alinierea practicilor și schimbarea modului global de operare a necesitat efort considerabil, o schimbare a modului de gândire, dar și ieșirea din zona de confort. Diverse culturi au adus abordări diferite de rezolvare a lucrurilor, ceea ce s-a tradus și în rezistență la schimbare. Pentru a face față acestei provocări, am decis să implementăm Agile gradual, începând cu echipele ce lucrează la Centrul de Inginerie Bosch din Cluj. După ce am demonstrat că abordarea a avut succes la nivel local, am expus rezultatele și experiențele noastre altor echipe, ceea ce a facilitat aderarea la Agile în rândul acestora din urmă.

O altă provocare majoră a fost să lucrăm cu clienți nefamiliarizați cu Agile. În ciuda eforturilor noastre de a lucra cu obiective la nivel de sprint, clienții au introdus, frecvent, modificări și o resetare a priorităților la mijlocul sprinturilor. Pentru a gestiona această situație, le-am explicat clienților principiile Agile, am organizat ședințe recurente înainte de planificarea din sprint pentru a afla prioritățile, iar apoi le-am prezentat sprintul planificat. După ce a început sprintul, am negociat orice alte solicitări, încercând să le integrăm în sprintul imediat următor. La modul general, drumul nostru către Agile a atras atenția asupra nevoii de a avea susținerea managementului, de a comunica clar și de a ne adapta. Abordând provocările intențional și gradual, am îmbunătățit eficiența echipei și rezultatele proiectului.

În concluzie, Agile nu este doar o metodologie; ci un mod de gândire, un stil de abordare a problemelor și un stil de lucru care se bazează pe adaptabilitate, colaborare și îmbunătățire continuă.

Analizând experiențele celor ce au adoptat Agile, putem înțelege mai bine cât de transformatoare este această schimbare. Pe măsură ce organizațiile se confruntă cu complexitatea aderării la Agile, accentul trebuie să rămână pe încurajarea mediilor în care indivizii și echipele se pot dezvolta, cu scopul obținerii unui succes continuu, sustenabil și a unui nivel înalt de inovație în contextul unei lumi tehnologizate aflate în schimbare permanentă.