Studii de caz SAFe: Note de transformare din teren

Acest articol este partea a treia a seriei de scalare Agile Toptal, concepută pentru a ghida managerii de proiect în eforturile lor de extindere a echipei. Asigurați-vă că citiți prima parte, „Comparați 5 cadre de scalare agilă: pe care ar trebui să utilizați?” și partea a doua, „Scalarea agilă: Cele mai bune practici SAFe pentru Scrum Masters”.

Agilitatea este practicată într-o anumită manieră de 94% dintre companii, conform celui de-al 15-lea Raport anual privind starea Agile . Dar cercetările sugerează, de asemenea, că 90% dintre organizații se luptă cu implementarea Agile la nivel de întreprindere. De obicei, este munca antrenorilor Agile, a maeștrilor Scrum și a altor profesioniști în managementul proiectelor să conducă și să organizeze aceste eforturi. Adesea, lucrează cu echipe sau departamente rezistente la schimbare, într-o cultură a companiei greu de înțeles.

În această masă rotundă, trei manageri de proiect Toptal discută despre provocările conducerii transformărilor Agile. Deoarece soluțiile lor sunt compatibile cu Scaled Agile Framework (SAFe), am vorbit și cu Dean Leffingwell, creatorul SAFe. Perspectivele lor colective ilustrează necesitatea ca practicienii SAFe să pregătească o viziune clară despre ce este agilitatea și un plan de conducere care poate aduce echipe recalcitrante la bord.

Vorbește în siguranță cu creatorul cadrului

SAFe, un cadru oficializat de Scaled Agile, datează din 2014. Dar pentru Leffingwell, munca a început când a întâlnit pentru prima dată echipe Agile la începutul anilor 2000. În calitate de metodolog de dezvoltare software, a fost impresionat de rezultatele practicilor Agile din echipele de dezvoltare și a început imediat să exploreze modul în care mentalitatea poate fi aplicată într-o întreagă companie. Dacă o echipă Agile ar putea produce rezultate, ce ar putea produce o echipă de echipe Agile aliniate? Cum ar putea fi utilizate practicile Agile pentru proiecte de transformare la scară largă la companii naționale sau internaționale? După cum spune Leffingwell, „Îmi place dezvoltarea de software. Iubesc Agile. Vreau doar mare .”

În anii de după, companiile au recunoscut beneficiile SAFe, inclusiv livrări mai scurte, calitate mai bună a produselor, eficiență mai mare și angajați mai implicați. Începând cu 2021, mai mult de o treime dintre organizațiile din întreaga lume au folosit SAFe, iar printre cele mai importante aspecte ale sale se numără procesele partajate și limbajul unificat pe care le oferă. De exemplu, dacă o echipă crede că un sprint durează două săptămâni și o altă echipă crede că este de 30 de zile, se creează ceea ce Leffingwell descrie drept o „problema Turnului Babel”. Este greu pentru echipe să discute ce caracteristici să adauge dacă nici măcar nu pot fi de acord cu ce înseamnă „funcție”. „Aveți nevoie de oameni care lucrează într-un mod comun dacă doriți să construiți soluții mari”, spune el. „Nu există un termen în industria noastră care să nu fie supraîncărcat, cum ar fi „iterație” sau „sprint” sau „întârziere”. Acest lucru nu este util dacă încercați să lucrați peste granițele de echipă și regionale.”

Povești de succes Agile

A face pe toți membrii unei companii să adopte un mod unificat de a vorbi despre și de a lucra este o sarcină descurajantă, chiar și atunci când există o urgență extraordinară pentru schimbare. În corporațiile înființate, poate fi mai greu. Leffingwell detaliază: „Vă uitați la cele mai mari companii din lume care câștigă mulți bani și se descurcă incredibil de bine și concurează – și trebuie să se schimbe. Ei bine, întrebarea pentru ei este de ce ar trebui?” Managerii de proiect Toptal prezentați aici fiecare a întâlnit întrebări ca aceasta în timpul propriilor activități de scalare și fiecare și-a găsit propriul mod de a lucra prin transformările Agile folosind SAFe.

Demonstrarea valorii

Alvaro Villena, un manager de proiect Toptal din Santiago, Chile, a finalizat recent o tranziție SAFe pentru un portofoliu care dezvoltă o platformă inter-business. „Prima piatră de hotar în tranziția mea a fost desfășurarea unui atelier privind fluxul de valoare”, spune el. În termeni simpli, un atelier despre fluxul de valoare este o întâlnire de lansare pentru a identifica întregul proces de afaceri, de la concept până la livrare și toți pașii, utilizatorii, sistemele și punctele dure dintre ele.

Aducerea reprezentanților întregii întreprinderi în atelier a ajutat-o ​​pe Villena să înțeleagă cultura companiei și care ar fi obstacolele sale. „Înainte de a implementa atelierul, exista o structură în care o afacere avea echipa sa, o altă afacere avea echipa lor, iar următoarea afacere avea echipa lor — cei trei nu vorbeau între ei.”

Villena a constatat că, deși toate echipele împărtășeau puncte de durere similare, nu a existat nicio colaborare pentru soluții. De exemplu, deși fiecare afacere din portofoliu a livrat produse, doar una a dezvoltat un sistem de urmărire. Nu exista niciun motiv pentru care să nu-l poată folosi cu toții, cu excepția faptului că nimeni nu împărtășise cunoștințele. Odată ce atelierul i-a făcut să vorbească, cunoștințele au început să circule printre echipe, companii și proprietarii de produse. „Acest tip de conversație a fost foarte, foarte puternică pentru program. A fost un punct de plecare frumos”, spune Villena. Când DevOps, designul și produsul știu toate ce fac alte echipe, ei văd că există soluții în companie pe care le pot folosi. „Încep să întrebe: „Cum pot să am asta?” Și aici intervin și spui: „Urmează acest proces”.

„Nimeni nu vrea schimbare până nu știe de ce. Așa că începi cu un motiv și le oferi un viitor mai bun.” Dean Leffingwell, creatorul SAFe

Leffingwell știe că echipele sunt uneori rezistente. „Nimeni nu vrea schimbare până nu știe de ce”, îi spune el lui Toptal. „Așa că începi cu un motiv și le oferi un viitor mai bun.” A oferi echipelor o privire asupra cât de mai eficiente pot fi ele este un instrument puternic pentru conducerea schimbării.

Chiar și atunci când toată lumea este entuziasmată la bord, ar trebui să vă așteptați totuși la începuturi stâncoase. Echipele care sunt obișnuite cu dezvoltarea tradițională Waterfall și versiunile mari, de exemplu, pot avea probleme în trecerea la un proces de dezvoltare mai iterativ și mai agil, chiar dacă văd valoarea în acesta. „Primul program pe care l-am făcut a fost un fel de dezastru cu echipele”, spune Villena. „Și știam că va fi; i-am spus clientului să se aștepte ca primele trei luni să fie dificile.” Pentru a compensa acest lucru, el a construit o iterație de o săptămână, la sfârșitul primului increment de program (PI), în care echipele și-au putut evalua progresul. El a organizat un sprint dedicat exclusiv îmbunătățirii proceselor și evaluărilor care ar depăși inspectarea și adaptarea obișnuită. El a considerat util să aplice o mentalitate Agile nu doar produsului, ci și tranziției afacerii, făcându-și timp să dai înapoi, să vadă ce a funcționat și ce nu și să se adapteze în consecință.

Crearea de mici victorii

Este important să fii pregătit pentru obstacole neașteptate în adoptarea ta SAFe. În urmă cu câțiva ani, managerul de proiect Toptal, Miroslav Anicin, din Belgrad, Serbia, făcea tranziția unei companii de telecomunicații la SAFe. Compania și-a externalizat toată dezvoltarea software-ului. Încorporarea unei echipe în afara amplasamentului nu a fost o sarcină deosebit de oneroasă – problemele implicate erau în principal de ordin logistic. Dar efortul a creat provocări neprevăzute în tranziția companiei în sine. „Am căutat competențele de care avem nevoie în trenul de eliberare”, spune el. „Și toți oamenii dintre care a trebuit să aleg erau din marketing, din domeniul juridic, din produse, din finanțe – lipsind complet mentalitatea Agile sau chiar orice experiență în Agile.”

A devenit evident că managementul nu avea experiență în manipularea echipelor Agile. Luarea deciziilor distribuite necesită ca managerii să renunțe la un anumit control, un fapt că liderul poate refuza dacă nu au experiență cu cadrele Agile. Pentru a rezolva acest lucru, Anicin a trebuit să se antreneze de jos în sus și de sus în jos, antrenând lideri împreună cu echipele lor.

O astfel de trecere la luarea deciziilor mai descentralizate necesită „schimbarea modului de lucru de la comandă și control, prin conducere-servitor, la această cultură a învățării și a culturii Agile – și capacitatea de a tolera greșelile”, spune Leffingwell.

Anicin a început procesul de scalare progresivă - cu proiecte Agile mici realizate în cadrul unor echipe individuale, nu într-un cadru SAFe - astfel încât echipele individuale să poată dezvolta o experiență practică. Aceste proiecte trebuiau să fie neesențiale și suficient de mici încât compania să nu fie prejudiciată dacă ceva nu mergea bine la prima încercare, dar suficient de utile pentru a arăta echipei ce s-ar putea realiza cu abordarea. De exemplu, echipa de marketing a creat o campanie de marketing intern, în timpul căreia Anicin i-a învățat noțiunile de bază ale Scrum. Similar cu atelierul lui Villena, aceste proiecte mai mici demonstrează valoarea Agile în termeni reali, astfel încât membrii echipei și conducerea pot vedea beneficiile lansărilor scurte și îmbunătățirea continuă înainte de tranziția la scară completă.

Satisfacerea nevoilor echipelor dvs

Când Imane Marouane, un manager de proiect Toptal cu sediul la Paris, a condus o transformare pentru o mare instituție financiară multinațională, ea a pășit într-un mediu haotic în care echipele individuale au produs o muncă solidă, dar nu aveau o viziune la nivel de companie. „Fiecare echipă a avut propria sa prioritate. Fiecare manager de produs a dorit ca produsul său să fie livrat primul.”

Soluția SAFe la această problemă poate fi găsită în modelul ponderat cel mai scurt job first (WSJF). WSJF oferă un standard pentru prioritizarea muncii, astfel încât atunci când este timpul să decideți care ar trebui să fie următoarea sarcină, primul pas nu implică dispute cu privire la modul de clasificare a importanței. Într-un sistem Agile bazat pe flux, nu trebuie să vă faceți griji că livrați totul odată, deoarece, după cum spune Leffingwell, „cel mai important lucru este ce lucrare să faceți în continuare. Și aceasta este o întrebare mult mai ușor de răspuns decât care este cea mai valoroasă slujbă.” SAFe oferă o modalitate de a rezolva dependențele dintre echipe - ordonarea sarcinilor este esențială pentru acest rezultat.

Calea lui Marouane către soluționarea dependenței a devenit incertă: „După două sprinturi, înainte de prima inspecție și adaptare, am observat că unele echipe nu ne urmăreau planul PI.” Dependențele care au fost definite în planul PI nu au fost respectate, așa că munca unei echipe nu a putut începe deoarece contribuția altei echipe nu era pregătită.

„Din moment ce a fost prima iterație, iar echipele nu erau obișnuite cu acest tip de muncă, am decis să organizăm o ceremonie suplimentară – o întâlnire săptămânală pentru a discuta progresele legate de dependențe”, spune Marouane. „O persoană din fiecare echipă a venit să-și actualizeze progresul cu privire la contribuțiile lor.” În acest fel, dacă echipa A spunea că nu poate livra, echipa B ar putea să știe din timp și să planifice în consecință, în loc să aștepte contribuții care nu aveau să se materializeze la începutul sprintului.

Leffingwell predică prudență atunci când face aceste tipuri de ajustări la SAFe: „SAFe este un sistem de responsabilități. … Îl poți adapta, dar trebuie să fii foarte atent.” Deși cadrul este intenționat să fie adaptabil, schimbările tind să fie incluse dacă nu sunt reevaluate. Configurația Essential SAFe există pentru a se asigura că orice modificări îndeplinesc criteriile de bază.

Ceremonia suplimentară a lui Marouane a fost inclusă din nou în al doilea PI, iar până la al treilea a fost eliminată treptat. Echipele nu aveau nimic de raportat despre care să nu fi fost deja comunicate. O mică flexibilitate i-a permis lui Marouane să readucă echipele pe un proces mai tradițional. Ea a descoperit că tranziția în sine a necesitat o mentalitate Agile pentru a profita la maximum de echipele instituției financiare. Și, mai important, schimbarea pe care a făcut-o, prin angajamentul său față de îmbunătățirea continuă, a servit în cele din urmă principiilor Lean-Agile, care stau la baza Essential SAFe. Soluția ei a oferit companiei viziunea unificată care îi lipsea și a permis echipelor să lucreze împreună pentru aceleași priorități.

Adaptați-vă pentru viitor

Orice cadru care funcționează la scară va veni cu provocări. Numărul de piese în mișcare și de interese concurente este imens. Dar profiturile sunt la fel de mari, iar o tranziție bine executată va oferi echipelor instrumentele de care au nevoie pentru a lucra spre obiective comune. Obstacolele cu care vă confruntați într-o implementare la scară atât de mare vor fi imprevizibile, iar o mentalitate Agile i-a ajutat pe Villena, Anicin și Marouane să se adapteze la provocări neașteptate. La urma urmei, pentru asta este livrarea continuă: împuternicirea procesului cu instrumentele de adaptare la neprevăzut.

Scaled Agile se adaptează, de asemenea, la noile tehnologii și la standardele industriei în evoluție, introducând noi instrumente și capabilități, după cum este necesar. Toată lumea trebuie să rămână agile și să se pregătească pentru neașteptat. „Nu avem nicio bilă de cristal”, spune Leffingwell. „Alergăm repede, conducem din greu și urmăm din greu – și scriem cât de repede putem.”