Oltre cerimonie e artefatti

Come abbiamo creato un team Agile ad alte prestazioni in Global Technology.

di Hiren Patel, Senior Manager, Project Management

Fino al 2022, il team Restaurant Product and Engineering di Global Technology ha creato dashboard utilizzando la metodologia a cascata. Ciò è accaduto in parte perché McDonald's ha esternalizzato lo sviluppo e si può essere tentati di definire tutti i dettagli dell'ambito e dei risultati finali in anticipo nel contratto.

Non sorprende che il team abbia dovuto affrontare gli stessi problemi che sono spesso associati a progetti a cascata ovunque e, in definitiva, meno efficaci. Inoltre, c'erano grandi lacune di progettazione tra il prodotto che è stato costruito rispetto a ciò che era compatibile all'interno dell'ecosistema McDonald's.

Questo post parla di come le prestazioni, così come la percezione, del nostro team siano migliorate nel 2022, una volta che il team ha cambiato approccio. Il team ha implementato il framework di scrum della metodologia Agile, ma affermare che non dice tutto.

I team di molte aziende in tutto il mondo presumono di essere team Agili una volta che implementano le cerimonie e gli artefatti della mischia. A uno sguardo più attento, diventa chiaro che mentre molti di questi team adottano i meccanismi della mischia, non hanno la giusta mentalità per avere successo. In effetti, spesso hanno un ambito fisso, scadenze fisse e un budget fisso, che scompongono nelle cosiddette user story e raggruppate in sprint. In sostanza, sono team a cascata mascherati da team Agile, anche se non intenzionalmente.

Il nostro team di leadership ci ha supportato nell'adottare la giusta mentalità e di seguito sono riportati alcuni punti salienti di come abbiamo creato un team Agile ad alte prestazioni.

Concentrati sui prodotti piuttosto che sui progetti
Quando le persone pensano ai progetti, presumono che i progetti abbiano una fine definita. In effetti, molte delle principali organizzazioni professionali di project management definiscono esplicitamente un progetto come avente una fine definita. In superficie, l'idea dei progetti sembra molto pratica nel mondo aziendale. I contratti vengono approvati più rapidamente quando i risultati finali e le scadenze fisse sono definiti in anticipo; la pianificazione del budget è più semplice quando l'ambito e la pianificazione sono già fissati; e gestire le aspettative con la leadership sembra più facile quando i tripli vincoli sono fermi.

Tuttavia, la presenza della fine definita del progetto ha alcune conseguenze indesiderate: le scadenze esercitano pressione sul team e guidano le decisioni nel corso del progetto, che non sono sempre produttive a lungo termine. Le decisioni possono essere prese con una propensione verso il programma piuttosto che fare ciò che è necessario per ottenere risultati ottimali; Man mano che la scadenza arbitraria stabilita diversi mesi prima si avvicina, i team di progetto si concentrano maggiormente sul portare a termine le cose piuttosto che sul fare le cose per bene.

D'altra parte, quando le persone pensano ai prodotti, accettano il fatto che i prodotti hanno sempre margini di miglioramento. L'attenzione ai progetti porta le persone a prendere decisioni in base alle scadenze, mentre l'attenzione ai prodotti porta le persone a prendere decisioni in base a ciò che è meglio per le parti interessate.

Quando il nostro team era concentrato sul progetto, abbiamo creato una dashboard che spuntava alcune caselle in una dichiarazione di lavoro, ma il prodotto non sarebbe stato di grande utilità per i nostri stakeholder nel mondo reale. Nei sei mesi successivi al passaggio a una mentalità incentrata sul prodotto, abbiamo lanciato una versione modificata di tale dashboard, che si adatta meglio ai nostri stakeholder.

Una mentalità incentrata sul prodotto non significa necessariamente che ogni iterazione di un prodotto sarà perfetta, ma porta a prodotti migliori nel tempo rispetto alla mentalità incentrata sul progetto. E per essere chiari, l'attenzione incentrata sul prodotto non si esclude a vicenda dalla cura di budget, programmi e velocità di immissione sul mercato.

Fornisci valore frequentemente
Il nostro team ha adottato il concetto di livello di prodotto quando si tratta di dashboard, in modo da poter fornire rapidamente prodotti funzionanti. Una tipica berlina familiare e una supercar di lusso possono essere entrambi prodotti funzionanti di alta qualità, ma sono destinati ad essere di gradi diversi. In un altro esempio, un avvitatore manuale e un avvitatore elettrico a percussione possono entrambi essere prodotti funzionanti di alta qualità, ma anch'essi sono di gradi diversi.

Allo stesso modo, ci siamo concentrati su come fornire rapidamente un dashboard di qualità inferiore ma di alta qualità ai nostri stakeholder e quindi migliorare continuamente il voto durante ogni sprint. Ad esempio, potremmo consegnare un dashboard che contiene una tabella nel primo sprint; quindi, aggiungi capacità di ordinamento e filtraggio nello sprint successivo; quindi, aggiungi una combinazione di colori e funzionalità di drill-down nel terzo sprint. A qualsiasi livello, la dashboard è sempre un prodotto di alta qualità perfettamente funzionante che i nostri stakeholder possono utilizzare.

Questo approccio ci consente di fornire dashboard funzionanti ai nostri stakeholder più velocemente, piuttosto che il percorso alternativo in cui non avremmo consegnato nulla ai nostri stakeholder fino a quando i dashboard non fossero stati di alta qualità e di alto livello, contemporaneamente.

Fidati degli sviluppatori
Come ogni buon team Agile che utilizza scrum, utilizziamo i grafici burndown, ma non penalizziamo gli sviluppatori in base ai grafici. Anche quando un team ha gli sviluppatori più talentuosi, i grafici di burndown normalmente non dovrebbero apparire perfetti. Se i grafici di burndown sembrano costantemente perfetti, è probabile che i tuoi sviluppatori siano più concentrati nel far sembrare il grafico di burndown buono piuttosto che spingersi a fare del loro meglio. Questo perché le stime sono approssimative piuttosto che esatte e le sorprese sono inevitabili in ogni sprint.

Spingere per un grafico di burndown perfetto è un'aspettativa irrealistica e non necessaria, che di solito abbassa il morale e incoraggia gli sviluppatori a giocare con il sistema. I team che si appoggiano troppo ai grafici di burndown come strumento principale per misurare la produttività potrebbero avere successo nel guidare comportamenti che si traducono in grafici di burndown dall'aspetto perfetto, ma ciò non si tradurrà necessariamente in un team ad alte prestazioni. Invece, usiamo i grafici burndown per istruirci su cosa è successo, dove abbiamo deviato dal piano di sprint, perché abbiamo deviato e cosa possiamo fare meglio. In risposta alla fiducia che diamo agli sviluppatori, loro si fidano di noi con il loro feedback sincero piuttosto che dirci cosa suona bene. Riteniamo gli sviluppatori responsabili in base ai dashboard funzionanti che forniscono, piuttosto che ai grafici di burndown.

Sii flessibile al cambiamento
A volte i requisiti, le priorità e le esigenze cambiano. A volte gli sviluppatori ci consigliano modifiche e talvolta chiediamo agli sviluppatori di cambiare le cose. C'è sempre un'attenta considerazione e un buon dialogo quando si verificano cambiamenti in modo che tutti i membri del team capiscano cos'è il cambiamento e perché è necessario. Ma soprattutto, il nostro team si sforza di accogliere i cambiamenti piuttosto che evitarli, anche se si verificano in momenti inopportuni. Evitare i cambiamenti potrebbe sembrare la scelta migliore a breve termine, perché potrebbe aiutare a mantenere buoni i grafici di burndown, potrebbe consentire al team di fornire qualcosa alla fine dello sprint o potrebbe aiutare a evitare un impatto sui costi. Tuttavia, il debito derivante dalla mancata accettazione dei cambiamenti si accumula nel tempo e il costo del rimborso di tale debito potrebbe essere molto più elevato lungo la strada.

Concentrati sulla comunicazione piuttosto che sulla documentazione
La documentazione è utile ma ha rendimenti decrescenti oltre una certa misura. Abbiamo storie utente con criteri di accettazione, documenti di progettazione e altra documentazione che ci aiuta con la comunicazione. Tuttavia, poniamo la massima enfasi sulla comunicazione costante e sulla garanzia che gli sviluppatori comprendano chiaramente i requisiti. Non insistono sul fatto che scriviamo ogni minimo dettaglio nel biglietto e non ci aspettiamo che capiscano tutto semplicemente leggendo i biglietti.

Conclusione
Nel 2022, il team Restaurant Products and Engineering ha fornito più dashboard funzionanti durante i primi tre trimestri, insieme a diversi cicli di miglioramenti per ciascuno. Questo è stato un notevole miglioramento rispetto all'anno precedente. Inoltre, le parti interessate stanno iniziando a riconoscere il team per la sua capacità di trasformare le idee in dashboard funzionanti che sono veramente utili per gli utenti. All'interno del team si è formato un circolo virtuoso che porta a migliorare le prestazioni e migliorare il morale, grazie alla mentalità che abbiamo adottato.