Ce este Agile? O filozofie care se dezvoltă prin practică

Conceput inițial pentru echipele de dezvoltare de software, Agile este acum cea mai importantă abordare de management de proiect pentru industrii și companii din întreaga lume. Atractia constă în simplitatea și flexibilitatea sa: lipsa practicilor prescriptive Agile îl face extrem de adoptabil. Și totuși, atunci când ghidez transformările Agile în mai multe companii, am descoperit că această flexibilitate duce și la concepții greșite despre ce înseamnă să fii Agil. Multe companii acordă prioritate aderării la cadrele derivate din Agile față de înțelegerea filozofiei în sine.

În schimb, managerii de proiect și antrenorii care adună și ghidează echipele Agile ar trebui să înceapă prin a le antrena în adoptarea unei mentalități Agile, internalizând în esență valorile și principiile de bază ale filozofiei. Numai atunci ar trebui să combine, să personalizeze sau să omite practicile din cadrele Agile pe baza a ceea ce servește cel mai bine cerințelor proiectului.

Urmărind dezvoltarea istorică a Agile și legând principiile sale fondatoare de nevoile specifice ale companiilor și echipelor, acest articol îi poate ajuta pe managerii de proiect să creeze un viitor optim pentru transformările Agile. După cum demonstrează următoarele cazuri, Agile nu ar trebui privit strict ca o abordare de management de proiect, ci mai degrabă ca o filozofie de dezvoltare a produsului care evoluează continuu în practică.

Antecedente Agile

Compilat pentru prima dată în 2001, „Manifestul pentru dezvoltarea agilă a software-ului”, o colecție succintă de patru valori de bază și 12 principii, a fost un răspuns radical la abordări liniare, grele de proces, încărcate cu reguli și o mulțime de documente. Dar istoria Agile a apărut cu decenii înainte cu o metodă de eficientizare a producției industriale.

Un antecedent al filozofiei pentru concentrarea sa pe îmbunătățirea iterativă, modelul Plan-Do-Study-Act a fost dezvoltat în anii 1930 de către fizicianul și statisticianul Bell Labs Walter Shewhart. După al Doilea Război Mondial, protejatul său, W. Edwards Deming, l-a aplicat managerilor de trenuri de la Toyota. Metoda a fost parte integrantă a dezvoltării sistemului de producție Toyota, sursa principală a gândirii Lean, cu bucla eficientă de construcție-măsurare-învățare.

În anii 1970, conceptul a fost dezvoltat în continuare când Barry Boehm a propus tehnica Wideband Delphi, folosind un proces iterativ pentru a estima precis și obiectiv munca și timpul necesar dezvoltării software-ului.

Odată cu proliferarea computerelor personale la mijlocul anilor 1980, a devenit clar că software-ul ca produs și serviciu va deveni piatra de temelie a modului în care oamenii fac afaceri. Pe măsură ce profesioniștii au început să acorde o atenție deosebită abordărilor incrementale și iterative ale ingineriei software, Agile a depășit procesele Waterfall ca abordare superioară de dezvoltare și management.

Cercetătorii au descoperit că producătorii care inoveau mai repede decât concurenții lor foloseau o metodă multidisciplinară, orientată spre echipă, pentru a muta un produs prin ciclul său de viață. Aceasta este considerată inspirația lui Jeff Sutherland pentru inventarea cadrului Scrum în 1993, care i-a permis să finalizeze proiecte aparent imposibile la termen și sub buget, cu erori minime.

Valorile Agile în teorie – care decurg din aceste antecedente – au fost confirmate în utilizarea Agile în practică, cu accent pe dezvoltarea iterativă, lucrul în echipă colaborativ și estimarea precisă.

Ce este Agile în teorie?

Pe măsură ce companiile continuă să adopte moduri de lucru Agile, riscă să le facă mai prescriptive decât au vrut vreodată autorii filozofiei. Din experiența mea, liderii care doresc să adopte Agile se concentrează prea mult pe cadre – sau seturi de practici specifice și nomenclatura asociată acestora – și nu suficient pe valori și principii.

După cum știu bine practicienii care sunt avansați în transmiterea principiilor Agile, fiecare organizație care încearcă să treacă printr-o transformare Agile trebuie să găsească și să adapteze abordările care li se potrivesc. Facilitez acest proces de învățare arătând echipelor cum să urmeze valorile și principiile manifestului și apoi inspirându-mă din cadre, cum ar fi Scrum, Kanban și Extreme Programming (XP), pentru a le implementa în practică.

Principiile manifestului sunt de acum a doua natură pentru managerii de proiect Agile:

1. Indivizi și interacțiuni peste procese și instrumente
2. Produse de lucru peste documentație cuprinzătoare
3. Colaborarea clientului peste negocierea contractului
4. Răspunsul la schimbare în urma unui plan

Cu toate acestea, avertismentul care urmează aceste principii din manifest este adesea trecut cu vederea: „Adică, deși există valoare în articolele din dreapta, prețuim mai mult elementele din stânga”. Mulți practicanți Agile ajung să ignore valorile din dreapta și să se concentreze doar pe ceea ce este în stânga. Rezultatul? Opusul urmăririi orbește cadre grele de proces: niciun proces, ceea ce este la fel de problematic.

Găsirea echilibrului adecvat între elementele din dreapta și din stânga a devenit cheia modului în care ghidez transformările Agile. De asemenea, este exemplificat de abordările de management de la Apple, Google, Amazon, Facebook și Netflix, niciuna dintre acestea nu s-a abonat la un cadru Agile singular. Ei au întruchipat principiile manifestului în primul rând, în timp ce urmăresc sau schimbă părți ale diferitelor cadre în funcție de ceea ce a funcționat cel mai bine pentru ei; ca urmare, s-au adaptat la schimbările pieței și sunt capabili să livreze rapid produse noi.

Ce este Agile în practică?

În următoarea prezentare generală, am modificat formularea originală a valorilor manifestului. Modificările aduse semanticii ajută la clarificarea modului în care aplic valorile Agile în practică.

În prima valoare, înlocuiesc termenul „indivizi” cu „oameni” pentru că a fi agil înseamnă a fi orientat spre echipă. În ceea ce privește al doilea, este evident că software-ul trebuie să „funcționeze”, așa că acum se pune accent pe „livrarea” de succes și în timp util. A treia valoare este pur și simplu „colaborarea”, deoarece se aplică în mod egal colegilor care lucrează împreună și echipelor care lucrează cu clienții. În cele din urmă, „cadrele” înlocuiește „urmarea unui plan”, deoarece aceasta previne înțelegerea greșită conform căreia planificarea ar trebui abandonată cu totul.

Oameni peste procese

Transformările agile sunt dificile, în primul rând pentru că majoritatea companiilor sunt atât de obișnuite să urmeze procesele cu strictețe. Finalizarea unui anumit număr de pași cu un anumit set de instrumente, în loc să dezvolte un produs inovator, devine scopul final.

Am fost consternat să văd că această mentalitate dă naștere unei „industrie agile” profitabile. După cum explică fondatorii Agile Ward Cunningham și Jon Kern, multe companii vând software despre care susțin că vor ajuta companiile să „devină Agile”. Dar a deveni Agile înseamnă a adopta o filozofie, a nu folosi software și a urma programul pe care îl prescrie.

Atingerea echilibrului corect nu înseamnă eliminarea procedurilor, ci mai degrabă găsirea celor care susțin cel mai bine obiectivele de dezvoltare ale fiecărei echipe. Pentru unul dintre clienții mei, o mare organizație tehnologică, am implementat Disciplined Agile, o abordare dezvoltată la IBM. Combină multe practici din mai multe cadre, inclusiv Scrum și Kanban. Utilizează dezvoltarea iterativă, dar este puțin mai greu de proces decât Agile tradițional, mai ales în faza de început, deoarece este destinat să umple golurile lăsate de Scrum. Disciplined Agile a lucrat pentru acest client deoarece organizația era foarte orientată spre proces. Mi-a permis să cunosc echipele la jumătatea drumului, să obțin acceptul lor și să le conving să adopte un flux de lucru Scrum.

Am încorporat întâlniri de rafinare a restanțelor, întâlniri de revizuire și scrum-uri zilnice pentru a facilita colaborarea intra și interechipă. Rafinarea backlog-ului face parte din Ghidul Scrum, dar întâlnirile de rafinare nu fac parte. Le-am adăugat pentru a permite o conversație sănătoasă despre motivul pentru care am plănuit să implementăm caracteristici specifice în viitoarele sprinturi, ceea ce este util pentru începătorii Agile. Am ales, de asemenea, nomenclatura „jale de referință” – un termen folosit în managementul proiectelor Waterfall – pentru că îi era mai familiar clientului. Recenziile și interacțiunile zilnice cu scrum sunt elemente convenționale din Scrum Guide, dar le-am făcut mai structurate în ceea ce privește programul, durata și fluxul.

În plus, în timp ce o aderare strictă la Scrum ar face ca fiecare persoană să fie pe deplin dedicată unuia dintre rolurile enumerate în Ghidul Scrum, au existat oameni în echipele clientului meu ale căror seturi de abilități nu se potriveau perfect într-un singur rol. Folosirea metodei Disciplined Agile mi-a permis să împart responsabilitățile acestor poziții între mai mulți membri ai echipei și să creez un proces care a jucat cu punctele forte ale oamenilor implicați.

Livrarea software-ului prin documentație

Un alt motiv pentru care prefer fluxurile de lucru Scrum sau Kanban personalizate față de respectarea strictă a oricărui cadru este că îmi oferă posibilitatea de a adăuga produsul minim viabil (MVP) în plan ca obiectiv. Derivat din Lean, practica creării unui MVP este în concordanță cu dezvoltarea iterativă și a devenit o tehnică populară în rândul practicienilor Agile. Permite unei echipe să livreze utilizatorilor software de înaltă calitate și alte bunuri în mod eficient și apoi să le rafineze pe baza feedback-ului. Aplicarea acestuia ca parte a unei abordări hibride bazată în mare parte pe Scrum sau Kanban a îmbunătățit abilitățile echipelor mele de a crea produse care să răspundă nevoilor clienților.

În prezent, lucrez cu un startup din SUA și folosesc această metodă în construirea unei piețe de criptomonede pentru NFT. Ne concentrăm pe crearea MVP-ului, așa că scriem doar documentația minimă necesară pentru moment. Deși această abordare este eficientă pentru o gamă largă de produse, este utilă în special pentru criptomonede și NFT, care se află într-o categorie nouă, experimentală, care se schimbă rapid. În loc să elaborăm specificații și caracteristici complete și să trebuiască să le schimbăm în mod repetat înainte de lansare, putem dedica acest timp încorporării feedback-ului utilizatorilor pentru a îmbunătăți dezvoltarea pieței noastre.

Colaborare peste contracte

Organizația tehnologică a întreprinderilor mari menționate mai sus s-a bazat în mare măsură pe contracte pentru o mulțime de proiecte cu costuri fixe. Contractele au subliniat metodele pe care le vor folosi pentru a finaliza lucrarea, precum și persoanele specifice care ar fi responsabile pentru fiecare sarcină. Odată semnate, contractele nu puteau fi modificate fără un proces de solicitare îndelungat.

O parte a transformării pe care am condus-o a prioritizat colaborarea față de aceste acorduri rigide. Planul pe care l-am implementat a înlocuit contractele cu documente de o pagină. Fiecare a declarat că am fost de acord să folosim Agile pentru a lucra în colaborare – cu clienții noștri, precum și cu colegii noștri de echipă și colegii din diferite echipe – între datele de început și de sfârșit desemnate. Orice a ieșit din colaborare ar fi rezultatul. Nu am inclus detalii despre care ar putea fi produsele finite. Deoarece cerem feedback-ul clienților și îl încorporam în dezvoltarea produsului nostru, eliminarea specificațiilor din documentul nostru de plan ne-a făcut mai receptivi la răspunsurile lor și i-a motivat să lucreze cu noi mai activ.

Pentru a integra conducerea, le-am rugat să mă lase să conduc o demonstrație de concept cu o echipă mică care lucrează cu un client mic, care și-a exprimat îngrijorarea că timpul de dezvoltare este prea lung, chiar înainte ca orice modificare necesară să agraveze problema. Prin faptul că acest client colaborează direct cu proprietarul produsului nostru, am reușit să facem schimbări la mijlocul dezvoltării și să reducem semnificativ timpul de livrare.

Aceste rezultate au convins conducerea să mă lase să lansez planul la mai multe echipe. În general, contractul simplificat și fluxul nostru de lucru Agile au redus timpul necesar dezvoltării și introducerii pe piață a caracteristicilor produsului.

Adaptabilitate peste cadre

Un alt client de-al meu, o companie de tehnologie a sănătății, nu a reușit să atingă un echilibru în ceea ce privește recunoașterea importanței ambelor părți ale unei valori Agile, și anume răspunsul la schimbarea în urma unui plan. În acest caz, totuși, a făcut opusul greșelii pe care a avut-o clientul meu de tehnologie de întreprindere: în loc să urmeze un proces prea rigid, a supraindexat flexibilitatea, neglijând în mare măsură procesul. Inginerii știau rareori la ce ar trebui să lucreze, deoarece nu exista prioritizare sau program. Au pierdut timp și productivitate încercând să-și dea seama în fiecare zi și au îndeplinit sarcini mai puțin importante înaintea celor mai importante.

Am propus implementarea Scrum CEO-ului și CTO, explicând că sprinturile i-ar forța pe ingineri să fie disciplinați și să planifice în trepte de două săptămâni, spre deosebire de a decide la ce să lucreze în fiecare zi. De asemenea, i-am sfătuit să angajeze un proprietar de produs, ceea ce ar remedia lipsa de responsabilitate a echipei a produsului. Le-am cerut directorilor să-mi acorde trei sau patru luni să lucrez cu echipele lor înainte ca ei să se aștepte să vadă rezultate.

După ce am obținut aprobarea lor, am introdus mai întâi valorile și principiile Agile, apoi am instruit echipa cu privire la stocul de produse și la diferitele tehnici de aranjare a acestuia, inclusiv crearea de epopee și povești ale utilizatorilor și crearea de subsarcini. Tehnicile și întâlnirile pe care le-am inclus în fluxul nostru de lucru sunt abateri de la Scrum tradițional, deoarece nu apar în Ghidul Scrum. Le-am integrat în plan pentru că epopeele, poveștile și sarcinile secundare au rezonat cu echipele în timpul antrenamentului, iar întâlnirile au promovat discuții productive.

Am inclus și conceptul de viteză, o adăugare târzie la XP care măsoară estimările efortului total pentru toate poveștile utilizatorilor în fiecare iterație de produs. Cu toate acestea, am folosit termenul „capacitate”, pe care îl prefer pentru că subliniază cât de mult pot prelua membrii echipei de lucru, mai degrabă decât cât de repede pot îndeplini sarcinile.

Pentru estimare, am început cu mărirea tricourilor, o tehnică care măsoară proiecte și sarcini ca mici, medii și mari; pe măsură ce echipa a progresat, am trecut la story points, o tehnică de estimare mai tradițională. Punctele de poveste sunt adesea folosite greșit de echipele neinițiate în Agile, care încearcă să le transforme în ore sau zile de lucru, concentrându-se excesiv pe intervale de timp și judecând oamenii pe baza capacității lor de a respecta termenele limită.

Dimensiunea tricourilor este mai abstractă, ceea ce face mai ușor pentru echipe să evite această capcană. Cu toate acestea, este și mai puțin precis. Așa că, odată ce echipa a înțeles cum să estimeze în termeni relativi, i-am trecut la tehnica mai sofisticată.

Până când echipa a finalizat două sprinturi, managementul superior a putut să-și vadă angajații lucrând mai productiv și comunicând mai eficient. Dezvoltatorii s-au implicat pentru prima dată cu părțile interesate și cu managementul executiv. Au cunoscut echipa de asistență pentru clienți și au înțeles modul în care funcțiile pe care le implementaseră îmbunătățesc viața utilizatorilor.

Această abordare a condus în curând la o creștere a calității software-ului companiei și la o reducere a timpului de livrare pentru noile funcții de la luni la săptămâni.

Care este viitorul Agile?

Pandemia de COVID-19 a creat o nouă realitate în care echipele nu mai puteau fi colocate, care era modalitatea preferată de a lucra în cadrul Agile atunci când a fost conceput. Cu toate acestea, ideea că trebuie să rămână așa este un mit: pe măsură ce munca de la distanță a devenit obișnuită, a devenit clar că comunicarea strânsă este în întregime posibilă cu software-ul de videoconferință. Echipele cu care lucrez acum sunt complet distribuite și ofer training de la distanță. Unele echipe optează chiar să lucreze asincron, folosind instrumente precum Notion și Loom, precum și pluginuri Slack precum Standuply.

Modelul distribuit de colaborare este noua lume a muncii, cu agilitatea în centru. Echilibrul dintre viața profesională și viața privată oferit echipelor de la distanță are un impact pozitiv asupra moralului și bunăstării mentale, ceea ce crește productivitatea și calitatea; pune oamenii peste procese și este flexibil și adaptabil, făcându-l prin excelență Agil.

Antrenorii agili, maeștrii Scrum și managerii de proiect ar trebui să se întoarcă la rădăcinile filozofiei și să o prezinte așa cum au făcut-o formulatorii manifestului: un set flexibil și dinamic de linii directoare de dezvoltare și livrare. Ar trebui să-i învețe pe directori și pe liderii de echipă că, deși se pot inspira din managementul de proiect, ei nu gestionează cu adevărat nimic în Agile – ei ghidează echipele și îi eliberează să facă cea mai bună muncă.