Journey to Agile: come Braze ha reinventato il suo processo di gestione dei progetti software

Fare un piano

Dopo alcune riflessioni, abbiamo deciso di passare a una metodologia collaudata per i team di ingegneri: abbiamo deciso che volevamo diventare più Agile.

Per affrontare questa nuova sfida, volevamo mettere insieme un gruppo che rappresentasse e sfruttasse la conoscenza dell'intera nostra organizzazione di prodotto e ingegneria, quindi abbiamo creato un comitato con otto membri che rappresentano la gestione del prodotto, la progettazione e l'ingegneria. Abbiamo incluso sia manager che singoli contributori, nonché persone con diversi livelli di background, anzianità ed esperienza Agile.

Questo Comitato Agile, come lo abbiamo soprannominato, ha affrontato la situazione tenendo ben presenti alcuni principi chiave:

• Volevamo utilizzare soluzioni collaudate ove possibile, sia per metodologie che per software. Ci vuole un grande sforzo per essere unici e volevamo essere unici solo nelle aree necessarie e strategiche. Volevamo anche che le persone fossero in grado di seguire le best practice di Google sulla gestione del proprio lavoro o, meglio ancora, che le persone si unissero a Braze già sapendo principalmente come farlo.
• Volevamo che i team di ingegneria dei prodotti di Braze fossero ampiamente coerenti nel modo in cui operano, perché essere in grado di parlare la stessa lingua è prezioso.
• Non volevamo fare nulla in modo dogmatico, o senza pensarci. Scegliere un metodo e poi seguire il libro non era abbastanza buono; per noi era importante che il buon senso e l'iterazione ponderata governassero la giornata.

Forti di queste linee guida, abbiamo deciso di utilizzare Scrum, un framework Agile che si è dimostrato efficace per molte organizzazioni. È ampiamente noto, è scalabile ed è la scelta predefinita sicura quando stai cercando di implementare un processo Agile.

Successivamente, abbiamo dovuto affrontare due decisioni principali: (1) quali strumenti dovremmo utilizzare per supportare il nostro nuovo processo e (2) come implementare le modifiche al nostro processo. Abbiamo parlato, valutato e demo di diversi software e, alla fine, Jira di Atlassian si è rivelata la scelta giusta per noi. È una soluzione ben collaudata, diverse persone del nostro team avevano già esperienza nell'utilizzo e altri team all'interno di Braze la stavano già utilizzando, aprendo un'opportunità per una migliore collaborazione tra i team perché lavoreremo tutti all'interno di un sistema.

Quando si è trattato di selezionare un piano di implementazione per Agile, abbiamo dovuto prendere alcune decisioni chiave. Innanzitutto, come alleniamo/abilitiamo la squadra? Potremmo assumere un allenatore Agile, avere persone con esperienza nella squadra che si occupano di addestrare gli altri o chiedere aiuto a consulenti. In secondo luogo, dovremmo fare in modo che i team all'interno dell'ingegneria che abbiano avuto una certa esperienza con Agile attendano la formazione prima di implementarla?

Alla fine, abbiamo deciso di consentire ai team che avevano familiarità con Jira e Scrum di iniziare nella misura in cui si sentivano in grado e abbiamo assunto un consulente per aiutare con la transizione a livello di organizzazione. Non ci interessava che le persone della nostra squadra o un giocatore indipendente fossero i principali responsabili dell'allenamento dei membri del team durante la transizione perché:

• Non volevamo che nessun singolo team possedesse il modo in cui facciamo Agile e sentivamo che la formazione sarebbe stata accolta meglio e i suggerimenti sarebbero stati più inclusivi se provenissero da una terza parte
• Abbiamo pensato che un'attività di consulenza sarebbe stata più stabile e più affidabile di un coach Agile individuale
• Volevamo avere una formazione di base per l'intera organizzazione ingegneristica e iniziare senza fare supposizioni sulle conoscenze che i singoli membri dell'organizzazione avevano su Agile
• Infine, volevamo che gli allenatori se ne andassero ad un certo punto, per chiarire che tutti nella nostra organizzazione erano responsabili del mantenimento del processo in corso

Esecuzione del piano

Dopo un paio di mesi di pianificazione, avevamo un grande documento che descriveva in dettaglio tutto ciò che intendevamo fare e lo abbiamo condiviso con l'organizzazione in generale per un feedback. Quindi, dopo aver valutato diversi fornitori, abbiamo scelto Eliassen per collaborare con noi nel viaggio verso Agile. Quel viaggio è iniziato con una formazione Agile di due giorni gestita da Eliassen, seguita da tre mesi di coaching Agile da parte di un esperto con cui Eliassen ci ha messo in contatto.

Fin dall'inizio, siamo stati abbastanza cauti nel trasferirci a Jira e Scrum. Sia Internet che le esperienze personali del nostro team erano piene di racconti ammonitori sui pericoli di approcci eccessivamente dogmatici, su come Jira può diventare un "anti-modello" e su tutti i modi in cui Scrum può andare storto nelle organizzazioni. Siamo stati fortemente avvertiti dalle persone che abbiamo consultato sul fatto che questi cambiamenti avrebbero probabilmente richiesto tempo e che potrebbero esserci difficoltà crescenti prima di vedere i reali benefici di Agile.

Per fortuna, abbiamo trovato immediatamente valore nel nuovo processo. Una delle cose belle di questa transizione è che non abbiamo mai sentito alcuna pressione a seguire ciecamente un aspetto particolare di Scrum; per far funzionare meglio le cose, avremmo fatto una retrospettiva su come stavano andando le cose ogni due settimane e poi avremmo modificato ciò che doveva essere modificato. E durante i tre mesi di coaching, abbiamo implementato cambiamenti radicali in tutta l'organizzazione ingegneristica:

• Tutti hanno imparato a scrivere, pulire, indicare, scomporre e raccogliere le storie degli utenti
• Standups ha trovato una rinnovata attenzione quando si è trattato di finire il lavoro a portata di mano
• Product, Design e Engineering hanno tutti imparato a parlare le stesse lingue e le interfacce sono state progettate sempre più bene

I risultati

Ora che siamo dall'altra parte di questo sforzo di circa sei mesi, i cambiamenti sono chiari e drammatici. Abbiamo assistito a una significativa riduzione dei problemi che hanno portato a questo sforzo. Con Agile, ora disponiamo di meccanismi chiari e di facile comprensione per l'approvazione, la collaborazione, la creazione di backlog e la pulizia, ed eseguiamo regolarmente retrospettive su cosa migliorare.

Abbiamo anche posizioni significativamente più coerenti per gli artefatti di progettazione, nonché aspettative più allineate su ciò che è veramente "fatto" per un determinato progetto. Vedere su cosa stanno lavorando gli altri team è diventato facile ed è più semplice che mai per le persone capire come lavorare bene insieme.

Qualcosa che ho notato alla fine di questa transizione è che il numero totale di richieste pull aperte nell'organizzazione in un dato momento era diminuito, anche se stavamo facendo di più e aumentando le dimensioni del nostro team. Lavorando con incrementi più piccoli e concentrandosi sulla finitura delle cose, il numero di articoli in fuga si è ridotto in modo significativo.

Il successo che abbiamo avuto nella nostra organizzazione ha ispirato anche altri. Stiamo iniziando a vedere i team di altri reparti di Braze che iniziano le proprie trasformazioni Agile, quindi presto più persone parleranno la stessa lingua e avranno gli strumenti necessari per definire e migliorare la collaborazione.

Asporto

Due elementi principali del nostro sforzo ne hanno assicurato il successo.

In primo luogo, il fatto che fosse guidato da un comitato rappresentativo era essenziale per ottenere input da tutta l'organizzazione ingegneristica e da una varietà di prospettive diverse. In tutta l'azienda, le persone si sono sentite ascoltate e rappresentate su una questione che avrebbe avuto un impatto sul loro lavoro quotidiano. Molto utile è stata anche la successiva creazione di un documento approfondito con le motivazioni e i piani per una transizione Agile da condividere con il team. Crediamo nel mostrare come vengono prese le decisioni e nell'introdurre percorsi chiari per il feedback, perché fornisce un contesto e stabilisce un artefatto su cui fornire feedback.

In secondo luogo, la decisione di affidare a una terza parte l'assistenza alla nostra squadra è stata essenziale. Avere un partner obiettivo ed esperto ci ha dato la possibilità di apportare rapidamente numerosi miglioramenti al nostro processo. Il nostro allenatore sapeva che aspetto aveva ed è stato in grado di dare consigli senza pregiudizi, un certo numero di volte siamo stati in grado di chiedere: "Come farebbero le squadre normalmente a fare X?" e ottenere una soluzione immediata e praticabile. Se, d'altra parte, avessimo utilizzato risorse interne, avremmo corso il rischio che il feedback che abbiamo ricevuto provenisse da una parte di parte e una maggiore contesa di risorse con le responsabilità esistenti.

Qualunque altra cosa?

Se vuoi saperne di più su come pensiamo al nostro prodotto e sul lavoro che serve per realizzarlo, dai un'occhiata a Building Braze. Interessato a far parte del nostro team? Dai un'occhiata ai nostri annunci di lavoro attuali.