agilità Archivi - Coaching Narrativo

Come lavora il Team Agile

L’approccio Agile mette in campo un team cross-funzionale (che ha rappresentate tutte le competenze), il quale rilascia output finiti più piccoli del risultato finale, in cicli più brevi. Questo Team lavora insieme per completare questi output circoscritti entro periodi di tempo finiti e coerenti, chiamati time-box (finestre temporali).

Il modo stesso di lavorare del Team Agile richiede infatti che il lavoro sia scomposto in una lista di piccoli e concreti “deliverable” (rilasci) e che si crei un backlog delle cose da fare (elenco), ordinato in base alla priorità dettata dalle esigenze di Business del momento. Poi viene stimato lo sforzo rispetto a ciascun item del backlog e si definiscono le iterazioni di lavoro del Team, con un tempo stabilito e cadenzato.

Al termine di ogni iterazione, per rispondere al cambiamento ed essere Agili, il programma di lavoro può essere rivisitato sulla base delle nuove esigenze espresse dal Business o sulla base di una migliore comprensione del Prodotto che sarà oggetto della delivery, ovvero si tratta di dare valore ad ogni iterazione. Poiché la metodologia Agile si caratterizza per essere una metodologia empirica e non prescrittiva, i risultati ottenuti serviranno da base per pianificare la prossima iterazione. L’Agilità inizia come il processo di cambiamento, servono assetti organizzativi alternativi ma anche un cambiamento nel modo di approcciare al lavoro stesso. Ecco alcuni driver per incorporare l’Agilità nel Team Agile.

T-shaped people

Nei Team interfunzionali le skill sono più importanti dei ruoli. I membri del Team Agile che hanno un profilo di competenze T-shaped migliorano la collaborazione ed il flusso di consegna del lavoro e riducono la dipendenza da specifici individui. Il concetto di competenze a T (T-shaped skills), o di persone a T (T-shaped persons), è una metafora usata in ambito HR per descrivere le abilità delle persone.

La linea verticale della T rappresenta la profondità delle competenze e delle esperienze in uno specifico settore, mentre la linea orizzontale della T rappresenta l’abilità di collaborare con esperti di altre aree, e di usare in modo appropriato concetti propri degli altri settori.

Un Referente del Business che definisce il Valore da creare

Il Business guida lo sviluppo dei Prodotti e dei Processi, definendo le esigenze, la strategia, il valore da creare e le priorità. Il Referente del Business per il Valore da creare (RBV) ha come missione di ruolo la massimizzazione del valore generato dal prodotto\processo. Questa figura si interfaccia con il cliente interno/esterno, ed eventualmente con gli Stakeholder, rappresentandoli. Recepisce infatti le loro esigenze per poi trasmetterle al Team Agile. Il Referente del Business (RBV) ha sempre chiaro il focus di far emergere il prodotto/processo con il più alto valore possibile entro la data desiderata.

Detto in altri termini, ha il compito di assicurarsi che il Prodotto/Processo sviluppato fornisca valore e sia sempre orientato alla soddisfazione delle esigenze espresse dal Business. Per poter guidare efficacemente lo sviluppo del Team Agile, il Referente del Business deve avere un’ampia conoscenza dei bisogni dei clienti e comprendere come il prodotto/processo possa rispondere a queste necessità: rappresenta la voce del cliente interno/esterno nell’azienda.

Rendere visibile il processo di lavoro

Il processo di lavoro di un Team Agile è visibile a tutta l’organizzazione ed è trasparente. È visibile a tutta l’organizzazione in quanto sono definite e condivise la Product Vision e la Product Roadmap. Il Business esprime la Vision di un Prodotto da realizzare che porta valore all’impresa, traducendola nella Product Canvas, ovvero nel documento di input che avvia l’iter di sviluppo prodotto/processo. In questo modo si cattura la voce del Cliente (interno/esterno), trasformandola in requisiti (cosa) e tecnologie/processi (come). È impostata dal Referente del Business interagendo con il Team Agile ed è resa disponibile a tutta l’organizzazione interna.

La Roadmap descrive come il Prodotto si evolverà per realizzare la Visione e ottenere il Business Value per l’azienda e per i clienti (interni ed esterni). Per questo motivo la Roadmap del prodotto è strategica. Infine, la lista delle cose da fare (Backlog di Lavoro) è trasparente e visibile a tutti gli Stakeholder e contiene elementi (item del Backlog) a breve ed a medio termine che possono essere consegnati per raggiungere i risultati definiti nella Roadmap.

Frequenti cicli di feedback e apprendimento.

Lo sviluppo Agile richiede una certa disciplina nella applicazione dei principi. Il focus è sui i risultati e sul valore ottenuto e porta il Team Agile a lavorare per iterazioni, ovvero cicli di lavoro cadenzati della stessa durata (generalmente da 1 a 4 settimane). L’adozione dei principi dell’Agile semplifica l’ispezione del lavoro e l’adattamento. Si realizza il prodotto/processo per incrementi di valore, si verificano ed ispezionano i rilasci alla fine di ogni iterazione ed il lavoro da fare nei daily meeting e si hanno subito dei feedback. Si può essere in grado di imparare più rapidamente e di adattarsi dove necessario. L’organizzazione diventerà più forte e più veloce lavorando con le basi della collaborazione, della trasparenza e dell’adattamento.

Il lavoro di un Team Agile rimane un vantaggio competitivo fondamentale, essendo ancora abbastanza raro e molto efficace. Infine, con il Team Agile la qualità è integrata in ogni fase. Agile è l’unico modo per raggiungere la qualità come qualcosa di più rispetto ad una serie di requisiti stabiliti a priori, grazie al modo di lavorare flessibile ma regolato e all’approccio empirico e pratico.

Esperienza, riflessione e adattamento. Tutto in trasparenza.

Agile è una filosofia di lavoro e un approccio metodologico che comporta una routine di piccoli miglioramenti incrementali che avvengono in degli slot temporali cadenzati. Inoltre, prevede una riflessione ricorrente sul lavoro svolto e quindi un apprendimento continuo.

In Agile, il lavoro viene scomposto in una lista di piccoli e concreti deliverable e l’elenco viene ordinato in base alla priorità dettata dalle esigenze di business di quel momento, ovvero dare valore da subito. È un approccio basato sulla fiducia che apprendiamo dall’esperienza e quindi possiamo trovare ed applicare modalità per identificare e integrare questo apprendimento nel modo di lavorare.

Agile riguarda molto più le persone che i processi. Il valore principale risiede nel cambiamento culturale che sviluppa l’individuo accrescendo le competenze chiave per essere adattivi, trasparenti, collaborativi e reattivi. Per creare un modo di pensare agile, dobbiamo affrontare i problemi consapevoli che potrebbe essere necessario più di un tentativo per risolverli e che più sappiamo del problema, più siamo attrezzati per trovare un efficace e soluzione duratura.

Agile ci propone un nuovo atteggiamento di apprendimento, per utilizzare la nostra capacità di navigare verso il successo attraverso la riflessione e l’adattamento. La Guida SCRUM (2017) dice che: “Agile … is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.”

La definizione di processo dell’American Heritage Dictionary è “Una serie di azioni, modifiche o funzioni che producono un risultato”. Si può intendere come degli input che passano attraverso il flusso di lavoro e si creano in uscita degli output.

Approccio predittivo tradizionale

Quando si avvia un nuovo progetto o si crea un nuovo prodotto, viene creato un set di requisiti e seguito di una attenta analisi il project manager presumerà che essi siano approvati come un insieme fisso da cui partire per la pianificazione. Il project manager stimerà quanto tempo ci vorrà per completare i requisiti e viene così creato il piano di progetto. Il piano prevede che il progetto sarà terminato entro una certa data e tale data viene comunicata al cliente.

Questo comporta quelli che sono definiti come “Defined Processes”: le informazioni e gli assunti iniziali sono validi lungo tutto l’orizzonte della pianificazione. Ovvero si predice il futuro una volta per tutte all’inizio del lavoro.

Ogni pezzo di lavoro è completamente compreso
È possibile avviare un processo definito e consentire l’esecuzione con gli stessi risultati ogni volta
Ci si basa essenzialmente sui criteri della ripetibilità e prevedibilità

La criticità fondamentale di questo approccio è che il piano, che guida tutto, si basa sul presupposto che i requisiti siano fissi e non cambieranno. L’esperienza ci ha mostrato che non è mai così, ovvero i requisiti in un progetto (oppure nello sviluppo di prodotto) possono non essere fissi, ci sono sempre cambiamenti. Quando i requisiti cambiano, il piano ne risente e di conseguenza, anche la data di completamento deve cambiare. Sfortunatamente, in molti casi, ciò è impossibile e si deve consegnare entro la data per cui il Team di progetto si è impegnato. Questo comporta una grave crisi e il progetto stesso inizia ad andare fuori controllo.

L’approccio tradizionale basato sul piano non è fallace in sé e per sé, semplicemente non è adatto per i business con alto tasso di incertezza come quelli odierni. L’approccio basato sul piano era originariamente basato sui concetti tradizionali di gestione del progetto, che provenivano dal settore delle costruzioni. Nel settore delle costruzioni, ad esempio, l’approccio predittivo è indicato: i progetti, hanno requisiti fissi che probabilmente non cambieranno durante la costruzione dello stabile. Si può stimare quanto tempo ci vorrà per costruire i pilastri ed i telai di acciaio, versare il cemento e così via.

È possibile prima completare le specifiche e poi costruire.
Quasi all’inizio si può stimare in modo affidabile l’impegno e il costo.
È possibile identificare, definire, programmare e ordinare tutte le attività dettagliate all’inizio del progetto.
L’adattamento a cambiamenti imprevedibili non è la norma e i tassi di cambiamento sono relativamente bassi

Approccio empirico

L’approccio agile orientato alla creazione di valore si basa sull’empirismo e questo cambia l’intera mentalità, il mindset. Si presume dall’inizio che qualsiasi requisito esistente in anticipo non sia fisso e che cambierà.

L’approccio agile presuppone anche che il Team debba consegnare entro una certa data. Questo approccio fissa il tempo e le risorse e lascia indeterminati i requisiti. Questo ci ricorda molto da vicino la realtà della creazione di software. Il criterio di essere “value-driven”, guidati dal valore, ci mette su un piano di apprendimento diverso.

Avremo frequenti ispezioni (al lavoro) e adattamento piuttosto che una pianificazione predittiva. Ci si adatta al futuro piuttosto che predirlo come uno scenario pieno di certezze. Quando abbiamo un periodo di tempo fisso e stabilito in cui non si è sicuri di poter fornire tutti i requisiti (perché cambieranno e quindi il tempo necessario per completarli cambierà), la reazione naturale è dare la priorità ai requisiti che sono stati messi a fuoco e finire per primi quelli che aggiungono il massimo valore al cliente.

La domanda sorge spontanea: “Ed i requisiti che non sono stati completati entro la data di consegna?” Questo è il motivo per cui ha successo l’approccio basato sul valore. Viene riconosciuto il fatto che non tutti i requisiti saranno completati entro la data di consegna. La domanda importante da porsi è se hai fornito abbastanza funzionalità per supportare un sistema che fornisce valore al cliente. Ed i progetti Agili risultano vincenti proprio per questo modo nuovo di pensare.

Si aspetta l’inaspettato
Poiché i processi sono definiti in modo imperfetto, generano output imprevedibili e irripetibili
Il controllo viene esercitato attraverso l’ispezione e l’adattamento
Le fasi di lavoro / processo potrebbero non essere comprese
Il lavoro è influenzato da fattori quali le performance passate e le differenze di know-how
Il miglioramento e la conduzione del lavoro sono guidati da esperimenti ed esperienza

Gestire l’incertezza ovvero sperimentarsi e adattarsi

I processi empirici (“Empirical Process”) sono usati per domini ad alto cambiamento e instabili, piuttosto che prevedere molte attività in sequenza, ci si basa su misurazioni frequenti e risposte dinamiche a eventi variabili. Quando siamo coinvolti nello sviluppo di nuovi prodotti e l’incertezza del business aumenta, allora pensiamo e apprendiamo con il processo empirico, che caratterizza l’approccio ed il modo di pensare Agile.

Raramente è possibile creare subito un piano immutabile, con specifiche dettagliate.
All’inizio non è possibile effettuare una stima affidabile di sforzo e costo.
Man mano che emergono dati empirici nel corso del progetto diventa sempre più possibile pianificare e stimare.
All’inizio non è possibile identificare, definire, programmare e ordinare tutte le attività.
Abbiamo bisogno di passaggi adattivi guidati alla fine di ogni ciclo di lavoro.
L’adattamento creativo a cambiamenti imprevedibili è la norma. I tassi di cambiamento sono alti.

Per concludere l’approccio Agile ci aiuta a pensare e ed apprendere una volta che rispondiamo alla domanda seguente. Il tuo progetto o prodotto è definibile prima di iniziare a lavorare oppure hai bisogno di dati empirici per aiutarti a costruire la soluzione? L’empirismo afferma che la conoscenza proviene dall’esperienza e dal prendere decisioni in cammino, basate su ciò che è noto.

Articoli

Team Agile: un nuovo modo di lavorare insieme