Consegna Agile 1x1: Panoramica, migliori pratiche ed esempi

Tutti parlano di “Agile Delivery” e per questo desiderate una rapida panoramica, alcuni esempi e best practice? In questo articolo troverete quello che cercate.

L’Agile Delivery è un metodo per fornire valore ai clienti e agli stakeholder utilizzando principi e pratiche agili.

L’Agile Delivery si basa sull’idea di una consegna iterativa, ovvero la presentazione precoce e frequente di fasi del prodotto o del servizio e l’apprendimento dal feedback e dai dati del cliente per migliorare e adattare.

Agile Delivery non è la stessa cosa di “Waterfall Delivery”, un modo tradizionale di creare valore in cui la pianificazione, la progettazione, lo sviluppo, i test, ecc. vengono pianificati in anticipo e poi eseguiti uno dopo l’altro.

Si sente spesso dire che un team agile ha un enorme “backlog”, ovvero un arretrato di compiti, che dominerà i prossimi mesi. E questo viene spesso definito “Agile Waterfall Delivery”. Vorrei però chiarire che non esiste una cosa come “Agile Waterfall Delivery”. E se qualcuno afferma di usarla, allora sta mettendo insieme ciò che non va messo insieme.

Basi della consegna agile

Ci sono tre principi principali dell’Agile Delivery che devi comprendere e applicare:

• Consegnare incrementi di lavoro in anticipo e spesso: Assicuratevi che tutti capiscano che il valore viene creato solo quando il cliente ha qualcosa di utile in mano. Tutto ciò che accade prima causa costi e non crea valore. Non importa a cosa si sta lavorando, è “finito” solo quando un cliente può effettivamente utilizzarlo. Di conseguenza, i team non dovrebbero iniziare nuovi lavori finché il loro lavoro precedente non viene utilizzato dai clienti.
• Ottieni un feedback rapido e diretto dai clienti: Se i team forniscono incrementi di lavoro in modo tempestivo e frequente, possono ottenere feedback da clienti reali e agire in base a tale feedback. Questo funziona solo se avete una struttura che permetta a voi e al vostro team di ottenere un feedback tempestivo da utenti reali. Insidia frequente: non permettete ai manager di agire per conto del feedback degli utenti. Chiarite ai manager che forse possiedono la definizione di “valore aziendale”, ma non la definizione di “valore del cliente”: questa appartiene ai clienti e dovrebbe essere esplorata direttamente dal Product Owner e dai team.
• Team interfunzionali: Se il tuo team deve parlare con altri 10 team per consegnare qualcosa a un cliente, lo sviluppo agile non funziona per te (ancora). Assicurati di avere team in grado di assumersi la responsabilità dell’intero processo, di prendere decisioni in modo indipendente e di parlare con i clienti.

Esistono diversi modelli organizzativi agili che possono aiutarti a implementare l’agilità nel tuo contesto. Ecco due esempi di modelli popolari da cui puoi imparare:

• Scrum: Si tratta di un framework agile che aiuta i team a creare valore in modo iterativo e incrementale.

  • Scrum definisce tre ruoli: Scrum Master, Product Owner e Team di sviluppo.
  • Definisce inoltre quattro eventi: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospectives.
  • E definisce tre artefatti: Product Backlog, Sprint Backlog e Increment.

Scrum è adatto a team o progetti di piccole e medie dimensioni che hanno requisiti e risultati chiari e stabili.

• Modello Spotify: Il modello Spotify è un modello organizzativo agile sviluppato da Spotify, un’azienda di streaming musicale.
  Il modello di Spotify divide le squadre in Squadre, Capitoli, Tribù e Gilde.

  • Una squadra è un piccolo team interfunzionale che fornisce una funzione o un prodotto specifico.
  • Un capitolo è un gruppo di persone che hanno competenze o compiti simili, come sviluppatori, tester, designer, ecc.
  • Una tribù è un gruppo di squadre che lavorano su un’area o un dominio correlato.
  • Una gilda è una comunità di interessi che si estende a tutta l’organizzazione.

Il modello Spotify è adatto a grandi organizzazioni o programmi con requisiti e risultati complessi e dinamici.

Vorrei poi sottolineare un metodo di gestione classico che svolge un ruolo importante anche in un contesto agile: Gli incontri one-to-one.

Come si evince dal grafico seguente, sono considerati molto importanti dai dipendenti.

Best practice: incontri one-to-one con gli sviluppatori

Guidare gli sviluppatori di software in incontri regolari one-to-one è assolutamente fondamentale per i Delivery Leader Agile. Sono forse i tuoi incontri più importanti. Li prendi sul serio

Vorrei cogliere l’occasione per attirare la tua attenzione sul nostro software gratuito per le riunioni one-to-one, sviluppato appositamente per i team agili. Rendi le tue riunioni 1:1 entusiasmanti, misura le tendenze e, soprattutto, fai progressi nello sviluppo dei tuoi dipendenti! 

Provate pure uno dei nostri modelli, vedi sotto. Il seguente modello è un modello standard per, ad esempio, riunioni individuali bisettimanali. Include anche un “controllo dell’umore” misurabile alla fine, che ovviamente potete adattare:

Per avere successo nel deployment agile, devi seguire alcune best practice che ti aiuteranno a ottimizzare il processo di deployment e i risultati. Eccone alcune:

• Guidare team auto-organizzati e indipendenti: In qualità di leader o manager Agile, devi dare ai tuoi team la possibilità di prendere decisioni, assumersi responsabilità e difendere il proprio lavoro. Devi confidare che facciano del loro meglio, senza condiscendere o imporre regole o restrizioni non necessarie. Devi anche sostenerli fornendo loro le risorse, gli strumenti, il feedback e il riconoscimento di cui hanno bisogno.
• Avere un contatto diretto con i clienti: Come membro di un team agile o come proprietario di un prodotto, devi interagire direttamente e frequentemente con i tuoi clienti. Devi capire le loro esigenze, aspettative e preferenze e fornire un valore che le soddisfi o le superi. Devi anche raccogliere il loro feedback sul tuo prodotto o servizio e usarlo per migliorare e adattare la tua offerta.
• Considera ogni nuova funzione come un esperimento da cui imparare: Come membro di un team agile o come proprietario di un prodotto, devi trattare ogni nuova funzionalità o requisito come un esperimento per testare le tue supposizioni e le tue ipotesi su ciò che i tuoi clienti vogliono o di cui hanno bisogno. Devi pianificare gli esperimenti con attenzione, misurare i risultati in modo oggettivo e imparare dai dati e dai feedback. Devi anche essere pronto a ripensare o a cambiare idea in base ai risultati ottenuti.

Questo è tutto ciò che ti serve per avere una panoramica. Spero che questo articolo ti aiuti a capire meglio il delivery agile, le sue basi, gli esempi e le best practice. Se hai domande o commenti, fammelo sapere 😊.