Călătorie către agilitate: cum Braze și-a reimaginat procesul de management al proiectelor software

Efectuarea unui plan

După câteva reflecții, am decis să trecem către o metodologie încercată și adevărată pentru echipele de ingineri – am decis că vrem să devenim mai Agile.

Pentru a aborda această nouă provocare, am vrut să înființăm un grup care să reprezinte și să valorifice cunoștințele întregii noastre organizații de produse și inginerie – așa că am creat un comitet cu opt membri reprezentând managementul produsului, proiectarea și inginerie. Am inclus atât manageri, cât și colaboratori individuali, precum și oameni cu diferite niveluri de pregătire, vechime și experiență Agile.

Acest Comitet Agil, așa cum l-am numit noi, a abordat situația având în vedere câteva principii cheie:

• Am vrut să folosim soluții dovedite acolo unde este posibil, atât prin metodologii, cât și prin software. Este nevoie de mult efort pentru a fi unici și ne-am dorit să fim unici doar în zonele necesare și strategice. Ne-am dorit, de asemenea, ca oamenii să fie capabili să folosească cele mai bune practici Google în ceea ce privește gestionarea muncii lor sau, mai bine spus, ca oamenii să se alăture Braze știind deja cum să facă acest lucru.
• Ne-am dorit ca echipele de inginerie de produs din Braze să fie în mare măsură consecvente în ceea ce privește modul în care funcționează, deoarece capacitatea de a vorbi aceeași limbă este valoroasă.
• Nu am vrut să facem nimic dogmatic sau fără să ne gândim bine. Doar alegerea unei metode și apoi trecerea la carte nu a fost suficient de bună; a fost important pentru noi că bunul simț și iterația atentă au condus ziua.

Înarmați cu aceste linii directoare, am decis să folosim Scrum, care este un cadru Agile care sa dovedit eficient pentru multe organizații. Este cunoscut pe scară largă, este scalabil și este alegerea sigură, implicită, atunci când căutați să implementați un proces Agile.

În continuare, ne-am confruntat cu două decizii principale: (1) ce instrumente ar trebui să folosim pentru a susține noul nostru proces și (2) cum ar trebui să implementăm modificările în procesul nostru. Am vorbit, am evaluat și am făcut demonstrații despre mai multe componente de software și, în cele din urmă, Jira lui Atlassian s-a dovedit a fi alegerea potrivită pentru noi. Este o soluție bine dovedită, mai mulți oameni din echipa noastră aveau deja experiență în utilizarea acesteia, iar alte echipe din Braze o foloseau deja, deschizând o oportunitate pentru o mai bună colaborare între echipe, deoarece toți am lucra într-un singur sistem.

Când a fost vorba de selectarea unui plan de lansare pentru Agile, am avut de luat câteva decizii cheie. În primul rând, cum antrenăm/activăm echipa? Am putea angaja un antrenor Agile, am putea să punem oameni cu experiență în echipă să facă munca de formare a celorlalți sau să obținem consultanți care să ne ajute. În al doilea rând, ar trebui să facem ca echipele din inginerie care au avut ceva experiență cu Agile să aștepte formarea înainte de a o implementa?

În cele din urmă, am decis să lăsăm echipelor care erau familiarizate cu Jira și Scrum să înceapă în măsura în care s-au simțit capabili și am angajat un consultant pentru a ajuta la tranziția la nivel de organizație. Nu ne-a interesat ca oamenii din echipa noastră sau un jucător independent să fie în primul rând responsabil pentru antrenarea membrilor echipei prin tranziție, deoarece:

• Nu am vrut ca nicio echipă individuală să dețină modul în care facem Agile și am simțit că instruirea va fi mai bine primită și sugestiile ar fi mai incluzive dacă ar veni de la o terță parte
• Ne-am gândit că o afacere de consultanță ar fi mai stabilă și mai de încredere decât un coach Agile individual
• Ne-am dorit să avem o pregătire de bază pentru întreaga organizație de inginerie și să începem fără a face presupuneri despre cunoștințele pe care indivizii membri ai organizației le aveau în jurul Agile.
• În cele din urmă, am vrut ca antrenorii să plece la un moment dat, pentru a clarifica faptul că toată lumea din organizația noastră este responsabilă pentru menținerea procesului de mai departe.

Executarea Planului

După câteva luni de planificare, am avut un document mare care detalia tot ceea ce intenționam să facem – și l-am împărtășit cu organizația în general pentru feedback. Apoi, după evaluarea mai multor furnizori, l-am selectat pe Eliassen pentru a colabora cu noi în călătoria către Agile. Călătoria a început cu un antrenament Agile de două zile condus de Eliassen, urmat de trei luni de coaching Agile de la un expert cu care Eliassen ne-a conectat.

De la început, am fost destul de precauți când ne mutăm la Jira și Scrum. Atât internetul, cât și experiențele personale ale echipei noastre au fost pline de povești de avertizare despre pericolele abordărilor excesiv de dogmatice, despre modul în care Jira poate ajunge să funcționeze ca un „anti-model” și despre toate modurile în care Scrum poate merge prost în organizații. Am fost foarte atenționați de oamenii pe care i-am consultat că aceste modificări ar dura probabil timp și că ar putea exista probleme de creștere înainte de a vedea beneficii reale de la Agile.

Din fericire, am găsit instantaneu valoare în noul proces. Unul dintre lucrurile frumoase despre această tranziție este că nu am simțit niciodată nicio presiune să urmăm orbește vreun aspect anume al Scrum; pentru a face lucrurile să funcționeze mai bine, am face o retrospectivă despre cum mergeau lucrurile la fiecare două săptămâni, apoi am modifica ceea ce trebuia modificat. Și pe parcursul celor trei luni de coaching, am implementat schimbări radicale în întreaga organizație de inginerie:

• Toată lumea a învățat cum să scrie, să îngrijească, să îndrepte, să descompună și să preia poveștile utilizatorilor
• Standup-urile și-au găsit o concentrare reînnoită atunci când a fost vorba de finalizarea lucrării la îndemână
• Produsul, Designul și Ingineria au învățat toate să vorbească aceleași limbi, iar interfețele au fost din ce în ce mai bine proiectate

Rezultatele

Acum că suntem de cealaltă parte a acestui efort de aproximativ șase luni, schimbările sunt clare și dramatice. Am observat o reducere semnificativă a problemelor care au condus la acest efort. Cu Agile, avem acum mecanisme clare și ușor de înțeles pentru aprobarea, colaborarea, crearea de backlog și îngrijirea, și desfășurăm în mod regulat retrospective despre ceea ce trebuie îmbunătățit.

Avem, de asemenea, locații semnificativ mai consistente pentru artefactele de design, precum și așteptări mai bine aliniate cu privire la ceea ce este cu adevărat „realizat” pentru un anumit proiect. Să vezi la ce lucrează alte echipe a devenit ușor și este mai simplu ca niciodată pentru oamenii să înțeleagă cum să lucreze bine împreună.

Ceea ce am observat la sfârșitul acestei tranziții este că numărul total de solicitări de tragere deschise din organizație la un moment dat a scăzut, chiar dacă făceam mai mult și creșteam dimensiunea echipei noastre. Lucrând în trepte mai mici și concentrându-se pe finisarea lucrurilor, numărul de articole aflate în zbor a scăzut semnificativ.

Succesul pe care l-am avut în organizația noastră i-a inspirat și pe alții. Începem să vedem echipe din alte departamente de la Braze care își încep propriile transformări Agile, așa că în curând mai mulți oameni vor vorbi aceeași limbă și vor avea instrumentele de care au nevoie pentru a defini și îmbunătăți colaborarea.

Concluzii

Două elemente principale ale efortului nostru au asigurat succesul acestuia.

În primul rând, faptul că a fost condus de un comitet reprezentativ a fost esențial pentru a obține contribuții din partea organizației de inginerie și dintr-o varietate de perspective diferite. La nivelul întregii companii, oamenii s-au simțit auziți și reprezentați într-o problemă care le-ar avea impact asupra activității lor de zi cu zi. Crearea ulterioară a unui document amănunțit care prezintă motivațiile și planurile pentru o tranziție Agile care ar putea fi împărtășită cu echipa a fost, de asemenea, destul de utilă. Credem în arătarea modului în care sunt luate deciziile și în introducerea unor căi clare pentru feedback - pentru că oferă context și stabilește un artefact pentru a oferi feedback.

În al doilea rând, decizia de a obține o terță parte care să ne ajute să antreneze echipa noastră a fost esențială. Având un partener obiectiv, cu experiență, ne-a oferit posibilitatea de a face rapid numeroase îmbunătățiri procesului nostru. Antrenorul nostru știa cum arată bine și a fost capabil să facă recomandări fără părtinire, de multe ori am putut să întrebăm: „Cum ar face echipele în mod normal X?” și obțineți o soluție imediată, viabilă. Dacă, pe de altă parte, am fi folosit resursele interne, am fi riscat ca feedback-ul pe care l-am primit să vină de la o parte părtinitoare și să crească conflictul de resurse cu responsabilitățile existente.

Altceva?

Dacă doriți să aflați mai multe despre modul în care gândim produsul nostru și munca care implică realizarea acestuia, consultați Building Braze. Sunteți interesat să vă alăturați echipei noastre? Consultați postările noastre actuale de locuri de muncă.