Introduzione

L’obiettivo di questo libro è intraprendere insieme al lettore un percorso di comprensionee consapevolezza delle pratiche e del mindset Agile, scegliendo un approccio pratico chepermetta a chi legge di calare nella propria esperienza i contenuti che sta leggendo in questolibro.

Lo sviluppo del libro segue un approccio iterativo incrementale, cercando di recepire quanto più possibile i feedback dei lettori; all’interno del libro vorremo sperimentare: ne consegue che alcune sezioni potranno nascere e morire. Tenendo fisso questo concetto, così come alcune sezioni possono nasce e morire, possono anche essere modificate in modo sostanziale.Quello che riporteremo all’interno di questo libro è frutto della nostra modesta esperienza e dei nostri studi, niente di tutto ciò intende avere un carattere prescrittivo, né vuole essere una verità assoluta: sappiamo che tutto quello che scriveremo potrà essere soggetto a cambiamenti e intendiamo sottolineare che il nostro obiettivo è far evolvere questo libro in base ai feedback di chiunque voglia leggerlo.

Dateci un feedback, ve ne saremo grati!Trovate il link al nostro canale Slack su www.officinaagile.it.

Aggiornamenti
Per rimanere aggiornati sugli sviluppi del libro, consultate i canali social di Officina Agile che trovate su: www.officinaagile.it.
Il link alle versioni epub e mobi del libro, sempre aggiornate, sono:
EPUB: https://leanpub.com/s/h2i7iwQ21H9Gb56u42q97A.epub
MOBI: https://leanpub.com/s/h2i7iwQ21H9Gb56u42q97A.mobi
Questo il link al libro su Leanpub: https://leanpub.com/sulsentieroagile/read_full

Vision

Questo libro vuole essere un viaggio di agilizzazione che facciamo insieme al lettore; in questo viaggio ci troveremo dover prendere delle decisioni, valuteremo le opzioni, faremo delle scelte. Ci aspettiamo che alcune di queste opzioni nascano dai tuoi feedback.
Vorremmo che questo libro diventi un nostro contributo per aiutarti a sperimentare quando ti troverai a dover prendere delle decisioni più o meno impegnative nel corso della tua esperienza agile.

Mission

Cercheremo di ridurre al minimo il superfluo: vorremmo esporre dei concetti chiave riguardo l’agilità, rimandando gli approfondimenti ad appendici o collegamenti esterni.Costruiremo questo libro insieme, dalle esperienze e dalle nozioni acquisite sul campo e sui libri: partiamo dai concetti base dell’agilità, iniziamo un percorso di agilizzazione e parleremo di pratiche e strumenti.
La struttura del libro sarà semplice e altresì tale da permettere una ricerca rapida e un orientamento veloce. Il libro viene pubblicato da subito in un formato incompleto, ma che porti valore, e verrà aggiornato frequentemente all’interno di un progetto di sviluppo che non ha un termine pianificato.
Cercheremo spesso un confronto con esperti che possano darci consigli e raccontarci storie di successo e di fallimento.

Backlog

Ogni progetto parte da un backlog, una lista (incompleta) di attività da portare a termine, e anche noi inizieremo da un backlog. Parleremo più avanti dei dettagli di cosa è un backlog, delle sue caratteristiche e di come può essere gestito. Per cominciare, ci basti sapere che un backlog è una lista di cose da fare, che devono essere analizzate una per una. Queste ”cose da fare” devono essere costantemente analizzate, arricchite e prioritizzate avendo una visione ad ampio spettro per cercare di portare a coloro che fruiranno di questi item il maggior valore possibile. Partiamo intanto da una lista non ordinata di argomenti, che verranno arricchiti, integrati e modificati dai vostri feedback e dalle vostre proposte; questi argomenti saranno i capitoli e le sezioni del nostro libro:
Perché agilizzarsi
Cos’è Agile
Agilizzazione: come iniziare
Complessità e esperimenti
Change Management: 8-Step Process for Leading Change (Kotter)
Le 14 regole della Qualità Totale
Perché un’organizzazione mezzo-agile non funziona
Organigramma e ruoli in un’organizzazione Agile
Organizational Design: Galbraith Star Model
Management 3.0
Tempi, risorse, costi: il triangolo di ferro e l’agilità
Scrum
Scrum PLOP: pattern di performance
Kanban
Extreme Programming
User Stories e Story Points
Lean Software Development
Le radici: cosa installare con priorità (per non perdersi prima di aver iniziato)
Inception di un team
Wave 0: transition team
Wave 1: il primo team
Wave 2: partono altri team, si parla di scaling
Framework di scaling: le basi di Safe
Framework di scaling: le basi di Less
Framework di scaling: le basi di Scrum at Scale
Backlog management: come gestire e coordinare più backlog
Rilasciare valore frequentemente: tecniche di slicing
L’agilità quando pianificare è un dramma (illegittimus non interruptus)
Bussole: cosa non perdere mai di vista (spoiler: massimizzare il valore -> feedback)
Strumenti per il backlog (User Story Mapping, Impact Mapping, tecniche di brainstorming, Value Poker…)
Scrum pattern di performance
Coltivare le motivazioni che svilupperanno l’agilità (Daniel Pink)
Antifragilità: oltre l’agilità
Modern Agile: uno sguardo a come Agile sta cambiando

Perché agilizzarsi

Come ci insegna Simon Sinek, seguiamo il pattern del Golden Circle: per ottenere successo in un’impresa o un progetto dobbiamo partire dalle sue (solide) fondamenta: il Perché facciamo quello che facciamo; solo successivamente ci concentreremo su Come vogliamo farlo e infine definiremo l’ultimo dettaglio, ovvero Cosa effettivamente intendiamo portare avanti.Serve un obiettivo per giustificare uno sforzo e per agilizzarsi è richiesto uno sforzo notevole.

Non si pensi che sia possibile agilizzare un’organizzazione o una parte di essa senza sacrifici: il processo di agilizzazione può essere lungo e richiedere un notevole impegno: settare adeguatamente delle aspettative realistiche è importante sia per poter pianificare opportunamente il processo stesso, sia per identificare dei traguardi intermedi realmente raggiungibili. Al giorno d’oggi l’agilità è adottata nella maggior parte delle più grandi aziende software (Google, Apple, Amazon, Facebook, Spotify, Netflix…) e, da diversi anni, è pratica comune anche di molte grandi aziende che non producono software (Tesla, Saab, Bosch, SpaceX, JohnDeere…).

Un celebre articolo di Steve Denning su Forbes parla dell’ineluttabilità dell’agilità; ovviamente si possono trovare in rete innumerevoli articoli che inneggiano alla fine dell’Agile: molto spesso basta entrare nel dettaglio dei contenuti per capire che si tratta di titoli provocatori.Tagliamo corto con l’introduzione e arriviamo al punto: per alcune (molte?) organizzazioni agilizzarsi non è una scelta, ma una necessità dovuta, a nostro avviso, a due principali fattori:

• la probabilità di successo con approccio agile rispetto a quello tradizionale, comprovata da innumerevoli dati storici (parliamo di tutela del patrimonio economico).
• l’imprescindibile ruolo che ricopre chi svolge un’attività concettuale che necessiti di forti specializzazioni e, di conseguenza, la necessità per l’azienda di rispettare la fondamentale competenza dei suoi dipendenti (tutela del patrimonio culturale).

Stando al report State of Agile del 2018, le principali ragioni per le quali viene adottato Agile sono:

• accelerare la delivery del prodotto/servizio
• migliorare la capacità di gestire i cambi di priorità
• incrementare la produttività
• migliorare l’allineamento fra il business e la produzione.

Insieme a questi obiettivi, molti altri potrebbero essere citati (migliorare il morale dei team, abbattere i costi dei progetti, etc…) ma focalizziamoci sui primi due punti: possiamo ragionevolmente ritenere che questi due fattori siano fondamentali per una qualsiasi comune organizzazione, ovvero abbiamo da una parte la tutela del patrimonio economico e dall’altra la tutela del patrimonio culturale di un’azienda.

La Harvard Business Review, in un articolo del 2016, cita due fra le maggiori motivazioni per cui un’azienda dovrebbe agilizzarsi: il miglioramento del time to market e della produttività. Intendiamo sottolineare questi due punti di forza più di altri, poiché essi sono fortemente legati alla natura stessa dell’agilità, ovvero alla capacità di sapersi adattare. Ricordiamo, infatti, che un’alternativa al termine ’Agile’, valutata dai firmatari al momento di dare un nome al Manifesto, era proprio il termine ’Adattivo’. Proprio sulla capacità di sapersi adattare efficacemente al contesto in continuo mutamente si gioca tutta l’essenza dell’agilità; rimangono altresì reali e concreti ulteriori vantaggi dell’agilizzazione, come la riduzione dei costi o il miglioramento della qualità, ma essi non possono essere ritenuti la vera essenza dell’agilità bensì la conseguenza; cioè questi risultati possono essere ottenuti, con ovvio sforzo, anche praticando la più classica delle metodologie di sviluppo in cascata; mentre, invece, se i processi che stai mettendo in atto sono volti ad accogliere efficacemente il cambiamento, in tal caso stai comunque portando avanti un processo Agile, sebbene tu possa non esserne cosciente.

Torniamo alle due ragioni fondamentali che motivano la necessità di intraprendere un processo di agilizzazione: la tutela del patrimonio economico e la tutela del patrimonio culturale di una azienda: in una realtà nella quale il mercato risulta sempre più frenetico e competitivo, le organizzazioni che si possono permettere di sopravvivere difendendo semplicemente lo status quo sembrano sempre più rare e riuscire ad evolvere velocemente adeguando il proprio prodotto o servizio alle mutevoli esigenze dei propri clienti sembra più una necessità che una scelta; il valore aggiunto di un lavoro cognitivo altamente specializzato, d’altronde, risulta la vera chiave di volta per l’ottenimento degli elevati standard qualitativi che i clienti ad oggi si attendono, confermando il know how come grande patrimonio per la continuità del business. Dobbiamo tenere in considerazione quali condizioni sono favorevoli affinché l’agilità possa giocare efficacemente il suo ruolo e comprendere se il contesto nel quale ci stiamo muovendo rispetti o meno queste regole; un contesto favorevole prevede: un impiego delle persone volto ad un lavoro cognitivo, condizioni di mercato che cambiano frequentemente, sarà possibile ottenere dei feedback sul proprio prodotto o servizio e l’innovazione giocherà un ruolo strategico. In un contesto favorevole (ovvero quando ci troviamo nel quadrante del Complesso, vedi Cynefin framework) l’agilità può esprimere la sua massima efficacia ed essere veramente determinante; lo stesso Sutherland nel parla in dettaglio in questo articolo.

Di seguito un’interessante sintesi delle condizioni favorevoli e sfavorevoli per l’applicazione delle metodologie Agile, presa dall’articolo di Sutherland citato precedentemente:

Mercato

• Favorevole: le necessità dei clienti cambiano frequentemente.
• Sfavorevole: le condizioni di mercato sono stabili e prevedibili.

Stakeholders

• Favorevole: possibile una collaborazione stretta e un feedback veloce. I clienti sono maggiormente consapevoli di cosa vogliono man mano che lo sviluppo procede.
• Sfavorevole: i requisiti sono chiari all’inizio e rimarranno stabili. I clienti non sono disponibili per una collaborazione costante.

Innovazione

• Favorevole: i problemi sono complessi, le soluzioni sono sconosciute a priori e l’ambito non è chiaramente definito. Le specifiche del prodotto possono cambiare. Le scoperte creative e il time to market sono importanti. La collaborazione cross-funzionale è vitale.
• Sfavorevole: lavoro ripetitivo, senza necessità di innovazione. Specifiche dettagliate e piani di lavoro possono essere previsti con sicurezza e devono essere rispettati. I problemi possono essere risolti in sequenza in silos funzionali.

Attività incrementali

• Favorevole: lo sviluppo incrementale del prodotto/servizio porta un effettivo valore. Il lavoro può essere suddiviso in parti e condotto in cicli rapidi e iterativi. I cambiamenti in corso alle specifiche possono essere gestiti.
• Sfavorevole: i clienti non possono iniziare a testare parti del prodotto fino a quando tutto non è completo. I cambiamenti in corso alle specifiche sono costosi o impossibili.

Impatto degli errori

• Favorevole: possono produrre un apprendimento che porterà valore al continuo dello sviluppo.
• Sfavorevole: possono essere catastrofici.

Vogliamo quindi sottolineare che Agile non è una panacea e non tutti i contesti sono favorevoli per la sua applicazione.

Cos’è Agile

Una breve descrizione di cosa è Agile e alcune sue declinazioni pratiche: saprete bene chein rete è possibile trovare migliaia di articoli su cosa è e cosa non è Agile, non vogliamo allungare questa lista; solo un consiglio: scegliete con cura cosa leggete.

Di seguito vogliamo fissare dei concetti chiave, limitando al minimo le interpretazioni personali.

Agile è definito da una serie di valori (quattro) e principi (dodici) formalizzati inizialmente nel 2001 dagli esponenti dei più importanti processi di sviluppo software (Scrum, XP, DSDM,ASD, FDD…).
Per i dettagli su valori e principi e sulla storia del manifesto, potete riferirvi al sito del manifesto.
Possiamo definire Agile un mindset: non definisce regole perché queste vengono definite dai framework di processo o di pratiche tecniche che si installano su Agile e ad esso appartengono (anche se, storicamente, Agile ne è la sintesi e temporalmente ne consegue).
I valori e i principi agili non servono solo a comprendere profondamente le regole dei framework agili, ma anche e soprattutto a guidarci nelle nostre scelte ogniqualvolta ci troviamo di fronte a un problema da risolvere e a opzioni da valutare; i principi e i valori agili saranno in questi casi la nostra bussola, che ci permette di fare valutazioni strategiche ponderate e mantenere una linea coerente e lungimirante.Va considerato, ciononostante, che il Manifesto ha ad oggi circa 20 anni e, sebbene sia ancora incredibilmente attuale, in taluni casi può risultare efficace la scelta di adeguare i valori e i principi al proprio specifico ambito, estendendoli alle proprie contingenti necessità derivanti dal contesto di adozione. Una azione di questo tipo, chiaramente, richiede un livello di comprensione dei principi agili e una maturità agile elevati, ovvero questa opzione è praticabile quando ci troviamo nella terza fase dello SHU-HA-RI (vedi sezione dedicata).

Focalizziamoci nuovamente sulla definizione di Agile: esso è un approccio sostenuto da innumerevoli pratiche, strumenti, framework e pattern che derivano principalmente da un approccio empirico e si basano sui principi e valori agili: l’ecosistema agile è estremamente vasto e in continua evoluzione; alcuni strumenti sono più maturi e riconosciuti, altri possono essere considerati sperimentali; fra i primi possono senz’altro essere menzionati i framework agili più comuni, quali Scrum e XP: questi framework sono un’implementazione dei principi e dei valori del Manifesto, largamente adottati in una moltitudine di scenari distinti.
Nonostante l’efficacia di questi framework sia ampiamente comprovata, quello che ci preme sottolineare è che applicare ciecamente gli strumenti dell’agilità non rende automaticamente.agili e non assicura alcun risultato: ciò che conta non è fare Agile, ma essere agili; oltre aduna conoscenza approfondita delle pratiche, serve una comprensione del perché esistano certe pratiche e degli obiettivi ai quali questi strumenti tendono.In estrema sintesi, cosa è Agile in cinque parole? Agile è: adattarsi per massimizzare il valore.
Questa breve frase è per noi un mantra che ci è servito e ci è tutt’ora utile sia per chiarire ai nostri interlocutori di cosa stiamo parlando, ma anche per ricordare a noi stessi quale obiettivo primario hanno le pratiche i processi che di volta in volta mettiamo in campo o sponsorizziamo; non vuole essere chiaramente una spiegazione esaustiva, ma ci richiama al fine delle nostre azioni e illumina il percorso che stiamo delineando.

SHU-HA-RI

Il concetto di SHU-HA-RI proviene dalle discipline tradizionali giapponesi, tra le quali le arti marziali, la calligrafia, la cura del bonsai: secondo lo zen il processo di apprendimento attraversa tre fasi:

SHU: fase iniziale, di studio, nella quale si imparano i concetti e le regole sotto l’insegnamento di un maestro. In questa fase la pratica segue esattamente la dottrina, con l’obiettivo di acquisire le competenze.

HA: seconda fase dell’apprendimento, nella quale la dottrina viene interiorizzata e profondamente compresa; si riflette e si comprende lo scopo delle tecniche, dopo averle consolidate nella fase precedente.

RI: terza fase dell’apprendimento: le tecniche sono state apprese e interiorizzate, adesso si trascende dalla dottrina e si modella una propria tecnica. Siamo nella fase della competenza inconscia e della sperimentazione.

Agilizzazione: come iniziare

Iniziare un processo di agilizzazione può prevedere diverse strade: la forma di questo percorsosarà guidata del ’perché’ questo processo ha inizio e da quali obiettivi esso si pone; si puòiniziare per volontà del top management o come esperimento di un team, lo scope temporalepuò essere limitato (in tal caso possiamo parlare di adozione Agile) o meno, si possonoincludere tutti i reparti di un’azienda, oppure un solo reparto o un solo team.In funzione delle necessità e degli obiettivi che ci diamo, possiamo utilizzare processi e strumentidiversi; possiamo considerare come esempio le fasi di un’agilizzazione che riporteremodi seguito, la loro profondità varierà in base al contesto di adozione e all’obiettivo. Va tenuto in considerazione che l’agilizzazione, per definizione, non è un percorso lineare: passando dauna fase all’altra, non è da escludere che sia opportuno tornare indietro e iterare, rivedere lastrategia e, in ogni caso, monitorare e analizzare costantemente gli obiettivi, per verificarnela loro attualità.Consideriamo queste fasi, esse saranno relative all’entità che intende implementare unatransizione Agile (organizzazione, reparto, team…):

Assessment: in questa fase si cerca di fotografare lo stato dell’entità, i suoi attuali processie i suoi obiettivi. L’output di questa fase potrà essere in parte evidente e si tratteràsemplicemente di registrare ciò che si nota o che verrà raccontato; in parte, invece, servirà unlavoro di introspezione da parte dell’entità, per definire ciò che potrebbe non essere chiaro eunivoco: ad esempio la vision, la mission, gli obiettivi strategici. Teniamo ben presente che,all’interno di un sistema complesso, osservare il sistema ne altera il comportamento.

Strategy: a valle dell’assessment e grazie all’output della prima fase, può essere definita unastrategia di transizione Agile assieme agli sponsor principali dell’entità. Questa strategiaprevederà un piano ben delineato a breve termine, e sarà tanto più sfumato quanto piùlontano sulla linea del tempo.

Training: in questa fase si calano le nozioni più importanti sull’entità e si inizia a coltivareil mindset, lavorando sulla consapevolezza, sulle convinzioni autolimitanti e sulla resistenzaal cambiamento.

Coaching: l’output della fase precedente ci potrà dare delle indicazioni preziose per lafase di coaching, nella quale si lavora per rinforzare le pratiche, promuovere il continuousimprovement e, insieme ai leader emergenti dell’entità, si mettono in campo gli esperimentiper fittare il processo.

Cerchiamo di vedere queste fasi come una spirale, un processo circolare che prevede piùround, o meglio chiamiamole ’wave’: al termine di una wave, che potrebbe prevedere illancio di un team pilota ad esempio, sarà fondamentale considerare i feedback raccoltie tenerne conto per la seconda wave; il nuovo Assessment potrà avere delle importantivariazioni rispetto al primo, sia per una maggiore consapevolezza dei coach e dell’entità, siaper una variazione del contesto. La Strategy si adeguerà ai feedback della wave e al nuovoAssessment. Il Training della wave successiva verrà adeguato in base a cosa ha funzionato ecosa non ha funzionato nella wave precedente; stessa cosa dicasi per il coaching, che, inoltre,potrà avere un input diverso dal precedente.

Andiamo più in dettaglio nella definizione delle fasi, senza dimenticarci che quanto segueè solo un possibile esempio per una transizione Agile, ma non intende assolutamente essereun’indicazione prescrittiva:

Assessment: l’output di questa fase potrebbe essere definito in due passi, dapprima ilcoach in autonomia e cercando di evitare influenze esterne dovrebbe raccogliere le seguentiinformazioni e in un secondo momento registrare informazioni tramite delle interviste:

• Vision, Mission e Strategy
• Struttura organizzativa
• Competenze e caratteristiche delle persone dell’entità (per questo punto, potrebbe essere

utile utilizzare una Skill Matrix) (vedi sezione dedicata)

• Prodotti/Servizi forniti
• Processi adottati
• Obiettivi dell’entità
• Cultura dell’entità (per questo punto, potrebbe essere utile mappare l’entità secondo lo schema di Frederic Laloux (vedi sezione dedicata).

Strategy: in base alle sue dimensioni, tutta l’entità o una parte di essa partecipa attivamentea definire la strategia della wave corrente; qualora si trattasse della transizione di un’interaorganizzazione, potrebbe essere definito un transition team: un team temporaneo chesponsorizza, sostiene e si adopera attivamente per il processo di transizione e ne fa advocacy.Una sponsorship forte può essere decisiva per il buon esito di una transizione. All’interno diquesta fase vengono provvisoriamente definiti (sempre in modo iterativo incrementale): lewave, i progetti pilota, i ruoli iniziali, le metriche, i KPI e i criteri di successo e di fallimento.

Training: vengono erogati dei corsi interni, si fanno delle sessioni di one to one quandonecessario, si parte con l’inception dei team, vengono definiti i working agreement e si iniziaa monitorare i KPI fin da subito. In questa fase è importante fissare dei Jump of Point deiKPI, cosicché sia possibile valutare i criteri di successo e fallimento più avanti nel tempo. Una lettura che potrebbe rivelarsi utile in fase di inception è il libro ‘Liftoff’ di Diana Larsen. La prima entità alla quale erogare il training sarà probabilmente lo steering committee, ovvero il team sponsor: qualora esso non riuscisse ad acquisire le competenze e il mindset necessari per guidare la transizione, il progetto sarà fortemente a rischio di fallimento.

Coaching: in questa fase il coach agisce dall’esterno, il protagonista è il team, che deveessere messo in condizione di poter sperimentare; una condizione safe to fail è fondamentaleaffinché il team possa acquisire esperienza e non venga limitato dal timore di sbagliare; ilteam deve essere empowered e in questa fase ha bisogno di tutto l’appoggio degli sponsor.A questo punto si lavora per rinsaldare le pratiche, promuovere la cultura del Kaizen. Vienefatto coaching one to one o di team sui ruoli e sulle tensioni sane, si cerca di evidenziare ledisfunzioni e rinforzare i processi efficaci.

Quando un team sta partendo e sono alti l’entusiasmo e la voglia di sperimentare, è probabileche ci si trovi ad affrontare situazioni nelle quali il team lancia esperimenti arditi, pococonvenzionali e un coach esperto potrebbe prevederne il probabile fallimento; in questeoccasioni non sempre la scelta migliore è quella di bloccare gli esperimenti del team allanascita: talvolta un fallimento può essere formativo, far crescere comunque l’entusiasmo delteam e portarlo ad un maggior livello di consapevolezza dei propri mezzi e di quali strumentie quali scelte sia in grado di intraprendere in quel momento. D’altronde è altrettantoimportante che questi fallimenti siano controllati e che lo step di analisi e miglioramentoche ne conseguirà possa avere a sostegno i dati necessari; è quindi importante aiutare ilteam nella corretta definizione degli esperimenti, ad esempio introducendo il concetto diSMARTness e dando struttura al processo.

Skill Matrix

La skill matrix è uno strumento per la visualizzazione delle competenze di un individuo o un team, utile, ad esempio, per valutare l’autonomia dell’individuo o del team nelconseguimento di un certo obiettivo. Prendiamo ad esempio un set di funzionalità checompongono la testa di un backlog di prodotto e vediamo la skill matrix come una matricecon le competenze (necessarie per sviluppare queste funzionalità) sulle colonne e il livello dicompetenza sulle righe. Sempre come esempio, ipotizziamo che i livelli di competenza siano tre:

• Expert (lo posso insgenare)
• Practitioner (lo posso fare)
• Novice (non lo conosco)

Se individualmente compilassimo la matrice, potremmo verificare se siamo in grado o menodi sviluppare le funzionalità di prodotto in completa autonomia; se, inoltre, tutto un teamcompilasse la matrice, potremmo valutare se questo team sia o meno in grado di sviluppare le funzionalità della testa del backlog in autonomia.Per di più: qualora la skill matrix evidenziasse delle carenze che ci impediscono di portarea casa il risultato, avremmo comunque un potente strumento per la pianificazione dellaformazione dell’individuo o del team.

Possiamo ipotizzare che il primo obiettivo nella composizione di una skill matrix di teamsia quello di avere un matrice complessiva (data dalla sovrapposizione delle matrici deisingoli) nella quale le prime due righe siano completamente coperte: come minimo, ogniteam member dovrà avere una forma a ’T’ (tutte le skill con competenza Novice, tranneuna con competenza ’Practitioner’); dopodiché, la pianificazione della formazione potrebbeprevedere di sviluppare in ogni team member la skill nella quale è più esperto, portandola aExpert (T-shaped skills) e, successivamente, iniziare a sviluppare le altre skill (la forma dellamatrice di ogni team member assumerà quindi una forma a Pi greco e così via, sviluppando ancora la skill matrix verso una forma a pettine (e aumentando la resilienza del team).

I modelli organizzativi di Frederic Laloux

Nel suo lavoro espresso all’interno del libro ‘Reinventig Organizations’, Frederic Lalouxdescrive i modelli organizzativi in uno schema evolutivo: senza entrare nel dettaglio esacrificando il contesto del lavoro di Laloux per giungere subito al dettaglio che di interessa, focalizziamoci sulla categorizzazione che esso da all’evoluzione delle organizzazioni:

• Red (impulsive): il collante dell’organizzazione è la paura, serve un esercizio costante del potere da parte del capo; prolifera negli ambienti caotici (vedi sezione dedicata al Kynefin framework), un esempio sono le organizzazioni criminali.
• Amber (conformiste): gerarchia fortemente piramidale, organizzazione basata sul command and control e sul principio di causa/effetto; un esempio sono le forze armate.
• Orange (ambiziose): gli obiettivi sono strettamente legati al raggiungimento di profitto e crescita, le caratteristiche principali sono: innovazione, accountability e meritocrazia.
• Green (pluralistiche): struttura piramidale, si focalizzano su cultura e autonomia per aumentare la motivazione dei dipendenti; lo stile di leadership è partecipativo e orientato al consenso.
• Teal (evolutive): l’autogestione sostituisce la struttura piramidale, l’organizzazione è vista come un’entità vivente, con un suo scopo evolutivo, la leadership è distribuita.

Nel suo lavoro ’Shifting Consciousness’, Andrea Provaglio prova a mappare i valori del Manifesto Agile con i modelli organizzativi di Laloux; di seguito il risultato:

• Individui e Interazioni: Teal e Green;
• Working Software: Teal e Orange;
• Customer Collaboration: Teal e Green;
• Responding to change: Teal e Orange.

Dalla parte destra dei valori, invece, abbiamo:

• Processes and Tools: Orange e Amber;
• Comprehensive Documentation: Amber;
• Contract Negotiation: Red e Amber;
• Following a Plan: Amber.

Speriamo che questi spunti possano esservi utili nell’analisi della cultura aziendale infase di assessment: il posizionamento culturale dell’organizzazione all’interno del modelloorganizzativo e la distanza rispetto allo schema di Provaglio potrebbero darvi un’idea dellavoro che sarà necessario intraprendere e i fronti sui quali dedicare particolare focus.

SMART

SMART è un acronimo per la corretta definizione degli obiettivi (viene comunemente attribuito a George T. Doran, non intendiamo riportare qui la storia, ma questo può essere un articolo per approfondire). Applicare la SMARTness ad un obiettivoconsente di verificarne la corretta formulazione al fine di massimizzarne la probabilità diraggiungimento, o, quantomeno, un corretto monitoraggio.

Di seguito l’estensione dell’acronimo:

• S: Specifico (Specific), identifica dettagliatamente l’area di miglioramento, l’obiettivo.
• M: Misurabile (Measurable), quantifica l’obiettivo in modo che sia possibile settare delle aspettative intermedie e monitorare il progresso.
• A: Raggiungibile (Achievable), il contesto e le condizioni al contorno, per quanto sia possibile saperne al momento in cui definiamo l’obiettivo, sono realmente raggiungibili, non siamo a conoscenza di impedimenti la cui rimozione è irrealistica.
• R: Rilevante (Relevant), il raggiungimento dell’obiettivo e il relativo sforzo che dovremo mettere in campo per il suo raggiungimento sono giustificati da una rilevanza riconosciuta da chi ne è coinvolto.
• T: Limitato nel tempo (Time bound), il raggiungimento dell’obiettivo ha una deadline temporale, entro la quale ha senso e porta valore raggiungere lo stesso.

Complessità e esperimenti

Cynefin

Nella nostra storia incontriamo spesso gli ‘esperimenti’ e dobbiamo chiarire il perché e il come affrontare questo tema. Di seguito faremo una breve introduzione al Cynefin framework, strumento basilare per leggere con la giusta prospettiva le realtà alle quali far fronte in un processo di agilizzazione.
Il Cynefin framework è uno strumento inventato da Dave Snowden nel 1999, ampiamente approfondito e utilizzato in vari ambiti e ancora molto attuale; potremmo ovviamente dare molti dettagli su questo strumento, ma, per rispettare lo spirito di questo libro, saremo anche in questo caso estremamente sintetici.
Il Cynefin framework modella i diversi livelli di complessità dei sistemi, distinguendo ogni livello in base al contesto e al comportamento che meglio si adatta al contesto stesso. Si parla di quattro domini, che guidano il comportamento: l’ovvio, il complicato, il complesso e il caotico.
Questi quattro domini hanno un livello crescente di impredicibilità e un loro modello di comportamento definito.
Sistemi che compongono più scenari riconducibili a questi quattro domini si catalogano in un quinto dominio: il disordine, dal quale si esce frammentando il sistema nei suoi scenari ed assegnando ogni scenario ad uno dei domini precedenti.

Possiamo perciò vedere il Cynefin come una spirale: ogni piano della spirale sarà associato ad un dominio, ma l’intero sistema sarà definito dall’unione e dall’interazione di tutti i suoi domini.
Ad ogni dominio è associato il pattern comportamentale che meglio vi si addice:

Nel dominio dell’Ovvio, il modello comportamentale è sense-categorize-responde, il legame fra causa ed effetto è molto stretto ed evidente, ad ogni azione corrisponde una reazione diretta e si possono definire ed utilizzare delle best practice.

Nel dominio del Complicato, il modello comportamentale è sense-analyze-responde, il legame fra causa ed effetto è ancora decisamente forte, ma non necessariamente evidente: la percezione di questo legame è funzione dal livello di competenza del singolo; ad ogni azione corrisponde una reazione che potrebbe esser distante nel tempo e nello spazio, servono conoscenze specifiche per cogliere questo legame; in questo dominio si utilizzano le good practices, tipicamente un esperto dell’area sarà in grado di risolvere sistematicamente il problema.

Nel dominio del Complesso, il modello comportamentale è probe-sense-responde, i singoli componenti del sistema si influenzano vicendevolmente, ogni azione su una parte del sistema ha ripercussioni sulle altre parti e gli effetti dipendono dalle condizioni specifiche del sistema stesso; in questo dominio si utilizzano le pratiche emergenti, qui è necessario effettuare degli esperimenti, monitorare il comportamento del sistema e iterare, persistendo sull’esperimento e effettuando un pivoting.

Nel dominio del Caotico, il modello comportamentale è act-sense-respond, il legame fra causa e effetto è totalmente impredicibile, l’unica cosa da fare quando ci si trova in questo dominio è uscirne, si deve agire prontamente e decisamente; a posteriori si può cercare di lavorare per decomporre questo dominio o cercare di mitigare il rischio di entrare nuovamente all’interno del dominio del caotico; per far questo si può utilizzare lo story telling.
Un ottimo articolo in italiano sul Cynefin framework è stato scritto da Giovanni Puliti qualche anno fa: lo potete trovare QUI.

Popcornflow

Compreso il concetto di complessità, ci è chiaro che la realtà che andiamo ad affrontare necessita di essere trattata empiricamente tramite esperimenti safe to fail monitorati.
Uno strumento interessante e piuttosto diffuso per sperimentare in modo efficace è il PopcornFlow di Claudio Perrone: uno schema di azioni che hanno l’obiettivo di guidare gli esperimenti affinché si possa scegliere in tempo se proseguire o pivotare e sia relativamente semplice riconoscere quando un esperimento è un successo o un fallimento.

Vediamo insieme come funziona PopcornFlow: l’obiettivo di PopcornFlow è di combattere l’inerzia, abilitare il cambiamento attraverso piccoli e continui esperimenti; il primo principio di PopcornFlow recita: ”Se il cambiamento è difficile, rendilo continuo” e il modo proposto da questo strumento è una serie di fasi da seguire iterativamente:

• Problems and Observations: dapprima si sceglie il problema da trattare eleggendo un’opinione condivisa (”Ognuno ha il diritto di esprimere la propria opinione, ma un’opinione condivisa è un fatto”, secondo principio di PopcornFlow).
• Options: quindi si collezionano delle opzioni che potrebbero trattare e risolvere il problema; in questa fase è fondamentale che ognuno porti liberamente il suo contributo, non ci siano censure e si propongano tutte le opzioni che ci vengono in mente, più o meno sensate.
• Possible Experiments: le migliori opzioni permetteranno di creare un backlog dei possibili esperimenti; questo backlog è composto da azioni concrete, pratiche, che derivano dalle varie opzioni.
• Committed: ogni volta che ci impegniamo a mettere in pratica un esperimento, lo descriviamo in un formato ben definito, che prevede:

* Action: l’azione concreta dell’esperimento
* Reason: il motivo per cui mettiamo in campo questo esperimento
* Expectations: le aspettative che abbiamo per questo esperimento
* Duration: quanto durerà questo esperimento
* Review Date: la data alla quale valuteremo se l’esperimento è andato a buon fine (ha raggiunto le aspettative), o è fallito (non ha raggiunto le aspettative); a questa data decideremo se proseguire l’esperimento, ritenerlo chiuso, o pivotare.

• Ongoing: gli esperimenti in corso
• Review: gli esperimenti conclusi, o interrotti, in fase di analisi dei risultati * Next: le prossime azioni legate all’esperimento: continuare con l’esperimento, aggiornando le aspettative e la durata, concludere l’esperimento, introdurre un nuovo esperimento sulla base delle aspettative iniziali o quelle aggiornate
• Done: gli esperimenti conclusi.

Una consapevolezza che PopcornFlow mira a trasmettere a chi è interessato ad utilizzare questo strumento è che il fallimento (di un esperimento) non è esclusivamente un’eventualità negativa, ma è anche e soprattutto un atto di apprendimento. Il terzo principio di PopcornFlow: ”L’obiettivo non è fallire velocemente e fallire spesso, ma apprendere velocemente e apprendere spesso”.

Improvement Kata
L’Improvement Kata, teorizzato da Mike Rother nel suo libro ’Toyota Kata’ del 2009, è per l’appunto un kata, ovvero una routine praticata per acquisire un’abilità; in questo caso l’abilità è la mentalità del miglioramento continuo.
Attraverso il kata, l’abilità viene installata a livello di competenza inconscia e diventa un automatismo della mente (vedi i 4 stadi della competenza).
L’improvement kata è uno strumento utilizzato per prendere decisioni, misurarne l’efficacia e iterare tendendo verso una visione all’interno di un sistema complesso. Il pattern degli Improvement Kata prevede cicli iterativi composti da 4 fasi:

• Definire una vision, chiarendo il problema da risolvere o l’ambito che vogliamo migliorare.
• Prendere atto delle condizioni attuali, registrandone le metriche in modo riproducibile.
• Definire le condizioni che vogliamo raggiungere, ovvero qual è il nostro obiettivo per la prossima iterazione; definire chiaramente l’obiettivo, condividerlo in modo trasparente e esprimerlo in modo misurabile aumenta il focus delle persone. In questa fase inizia a chiarirsi il gap fra l’attuale e il desiderato e si evidenziano quindi i primi impedimenti sui quali si dovrà lavorare. * Definire e avviare l’esperimento che, nelle intenzioni, ci porterà nelle condizioni desiderate; in questa fase emergeranno empiricamente i veri ostacoli ci potrebbero impedire di raggiungere l’obiettivo e, di conseguenza, quali ostacoli sarà necessario rimuovere.

Al termine delle 4 fasi si può effettuare una retrospettiva, analizzando il nuovo gap fra l’attuale e il desiderato, valutando cosa ha funzionato e cosa invece può essere migliorato, quali eventi sono accaduti e cosa potrebbe nuovamente accadere e portando queste valutazioni come apprendimento nella prossima iterazione. Nella nuova iterazione viene confermata o modificata la vision, si monitorano nuovamente le condizioni attuali, aggiornandone le metriche, si valuta il gap e definiamo il nuovo obiettivo; infine viene avviato il nuovo esperimento. QUI il podcast di Officina Agile sugli Improvement Kata, che potrà darvi molti altri dettagli.

Tempi, risorse, costi: il triangolo di ferro e l’agilità

Il triangolo di ferro nel project management

Il triangolo di ferro (meglio conosciuto in inglese come Iron Triangle) è un modello ideato da Martin Barnes nel 1969 (Martin Barnes: ingegnere inglese, fondatore dell’Associazione per il Project Management) teorizza una composizione dei vincoli per l’evoluzione e lo sviluppo di un progetto in base a tre principali fattori, intorno ai quali il progetto si regge: la durata (time), le risorse (resources) e l’ambito (scope) del progetto.
Time: si riferisce alla durata del progetto, in termini di giorni, settimane, mesi… è la stima di quanto il progetto debba durare per raggiungere l’obiettivo.
Resources: si riferisce alle persone e, più genericamente, ai costi che si stimano essere necessari per raggiungere l’obiettivo.
Scope: lo scope di un progetto è il suo obiettivo, ovvero il risultato finale che il progetto porterà in campo e che intende soddisfare le richieste del cliente.

Il triangolo di ferro si chiama appunto ’di ferro’ per la sua scarsa flessibilità: non è possibile modificare uno dei vincoli (time, resources, scope) senza impattare anche sugli altri.
Nel project management tradizionale si ipotizza che il triangolo di ferro sia inserito in un contesto nel quale l’unico vincolo fisso è lo scope, mentre i restanti due vincoli sono variabili; un esempio pratico: una volta concordato lo scope di un progetto (concordo con il cliente quale soluzione risolverà il suo problema), in base alla deadline richiesta dal cliente (time), avremo di conseguenza anche i costi (risorse).

Il triangolo di ferro e il Cynefin

Il modello del triangolo di ferro, così come è stato descritto, sembra efficace quando il contesto muta lentamente e il ciclo di vita del progetto ha una durata inferiore al periodo di stabilità del contesto stesso. Ipotizziamo un contesto nel quale i fattori che possono incidere sulle necessità del cliente varino con estrema lentezza (il mercato, i competitor, la tecnologia, etc…) e ipotizziamo che sia il cliente che il fornitore abbiano completa consapevolezza delle problematiche, degli strumenti e delle opzioni applicabili in questo contesto: in tal caso è lecito pensare che il nostro progetto soddisferà il cliente seguendo un processo che preveda dapprima una analisi dettagliata del problema e una scelta implementativa e, a seguire, una fase esecutiva nella quale ci avvicineremo alla deadline ’giocando’ sulle risorse. La descrizione di questo tipo di contesto e di problematiche richiama fortemente il quadrante del Complicato del Cynefin framework: anche in questo caso si ha un problema, se ne analizzano le cause e si definisce un piano, quindi si implementa questo piano per raggiungere l’obiettivo, utilizzando tipicamente delle best practices.

Il triangolo agile e il Cynefin

Immaginiamo ora di trovarci in un contesto nel quale le condizstima di quanto ilioni variano velocemente, le assunzioni che possiamo fare devono adattarsi velocemente ad una realtà in continuo mutamento, le condizioni di mercato, competitor, tecnologia, cambiano con una frequenza maggiore di quella che abbiamo ipotizzato per i nostri rilasci di valore.
In tal caso risulterà estremamente rischioso portare in produzione l’implementazione di requisiti che non sono stati verificati frequentemente durante lo sviluppo stesso del progetto: dovremo integrare in corsa le modifiche derivanti dalle variazioni del contesto; conseguentemente: la pianificazione a lungo termine ha un’elevata probabilità di risultare uno spreco di risorse; dovremo accettare di ripianificare frequentemente, utilizzando strategie che minimizzino i costi dei cambi di requisito.
Siamo nel quadrante del Complesso del Cynefin framework e stiamo ribaltando il triangolo di ferro: lo scope è adesso variabile e, nel nostro progetto, fissiamo invece tempi e risorse per determinare i costi.
Il nostro cliente non sta pagando per la promessa di un (inaffidabile) risultato, ma per le professionalità e le skill che saremo in grado di mettergli a disposizione. In quello che possiamo chiamare triangolo agile, vanno considerati due principali fattori che determinano le caratteristiche del processo: qualità e valore.
La qualità è un fattore da considerare come non variabile, definito in accordo fra il Dev Team e il PO e formalizzato con una Definition of Done.
Il valore è quello che in buona sostanza sostituisce il concetto di scope, concentrandosi non tanto su effimeri obiettivi a priori, quanto su risultati basati su feedback frequenti.
I nostri constraint saranno quindi: Risorse e Tempi: dipendenti dal parametro fisso della Qualità Scope: variabile, basato sul feedback del Valore. Come si può ben immaginare, avviare un progetto con scope variabile necessita di una notevole fiducia tra le parti, non essendo definito a priori l’output finale del progetto stesso; esistono diverse tipologie di contratto agile (approfondimenti nella sezione dedicata), utili a capire l’approccio nella fase di contrattazione e accordo con il cliente (es: Time and Material, Target Cost, Incremental Delivery, Pay per Use…). La domanda sorge spontanea: perché il cliente dovrebbe riporre la sua fiducia nel fornitore? Di rimando, rispondiamo con un’altra domanda: meglio un rischio consapevole, o un inconsapevole rischio?

Kanban

Cosa è Kanban

Kanban è un metodo che ci mostra il nostro lavoro, come lo stiamo facendo e quanto lo
stiamo realizzando efficacemente. La sola visualizzazione di queste informazioni ci permette di aumentare la consapevolezza dei nostri processi, migliorarci implicitamente e abilitare delle iniziative di miglioramento esplicito.
Kanban parte da visualizzare quello che stiamo facendo ora e come lo stiamo facendo, ma
risulta efficace se ci si concentra su come migliorare i flussi di lavoro, attraverso un processo di continuous improvement.

I Valori Kanban

Kanban è basato su nove valori, che sostengono i suoi principi e le sue pratiche:

• Trasparenza: lo scambio aperto di informazioni migliora il flusso di informazioni.
• Equilibrio: per massimizzare l’efficacia del processo, diversi aspetti e punti di vista

devono essere in equilibrio.

• Collaborazione: Kanban è un metodo per migliorare il lavoro in team.
• Focus sul cliente: il focus di Kanban è sul valore rilasciato al cliente, che sia interno o esterno all’organizzazione.
• Flusso: il lavoro è composto da un flusso di valore; visualizzare questo flusso è l’inizio di Kanban.
• Leadership: Kanban sponsorizza la ’leadership by example’; al fine di ottenere valore e miglioramento, la leadership è necessaria a tutti i livelli.
• Consapevolezza: consapevolezza del proprio stato, sia a livello personale, che di azienda. Kanban è una metodologia per il miglioramento continuo ed è fondamentale saper riconoscere il punto in cui ci troviamo.
• Accordo: l’efficacia del proprio lavoro si raggiunge anche attraverso l’accordo sugli

obiettivi, con un impegno comune verso il miglioramento.

• Rispetto: la base di tutti i valori, tenere in considerazione le altre persone e mostrare il rispetto verso di loro.

Kanban Agendas

Vediamo quali sono i tre fronti (noti come Agendas) sui quali Kanban lavora per ottenere l’obiettivo di improvement del valore:

• Sostenibilità: trovare un equilibrio fra l’impegno sulla produzione e la soddisfazione del cliente, un bilanciamento che si ottiene prima di tutto partendo dalla visualizzazione del flusso di lavoro.
• Orientamento al servizio: l’obiettivo è di fornire servizi che soddisfano appieno le aspettative del cliente.
• Sopravvivenza: tende ad assicurare la sopravvivenza dell’organizzazione, in un contesto di continuo cambiamento. Kanban segue un approccio evolutivo al cambiamento, improntato al continuous improvement sulla base di esperimenti safe to fail.

I principi fondanti di Kanban

Suddivisi in due gruppi (Change Management e Service Delivery), sono definiti sei principi fondanti di Kanban.

Principi del Change Management:

• Inizia da cosa stai facendo, comprendendo i processi attuali e rispettando i ruoli e le responsabilità esistenti.
• Il miglioramento si raggiunge attraverso il cambiamento evolutivo.
• Le azioni di leadership, a qualsiasi livello, devono essere incoraggiate.

I principi del change management si basano sulla consapevolezza della resistenza al cambiamento e sulla volontà di confrontarsi con questa resistenza rispettando le persone e la loro storia.

Principi del Service Delivery:

• Concentrati sulle necessità e le aspettative dei clienti.
• Gestisci il lavoro e lascia che le persone si auto-organizzino intorno ad esso.
• Fai evolvere le procedure, per migliorare il servizio al cliente.

I principi del service delivery descrivono un flusso continuo: dai processi ai ’work item’, verso l’ottimizzazione del servizio al cliente, nell’ottica della riduzione degli sprechi (tutto ciò che non ha come focus la sdoddisfazione del cliente).
Notiamo la similitudine con il decimo principio agile: ”La semplicità - l’arte di massimizzare il lavoro non svolto - è essenziale”; cogliamo anche l’occasione per riflettere sulla similitudine fra Agile e Lean e per citare due articoli: ”Kanban: agile o no?” uscito a Dicembre 2013 su MokaByte e ”Lean e Agile, similitudini e differenze” uscito a Gennaio 2015 sul sito di Felice Pescatore (Agile Business Coach ed esperto DevOps).

Il Flusso Kanban

Un sistema Kanban è formato da una serie di scoperte cognitive e le loro associate procedure, rese visibili in una Kanban Board; i ’work item’ fluiscono attraverso varie fasi di un processo, ordinatamente da sinistra a destra.
Questo sistema ha alcuni vincoli per poter essere chiamato ’Kanban’:

• il Work In Progress (gli item in lavorazione) deve essere limitato, ovvero i work item contemporaneamente in DOING non devono mai superare una certa soglia (si parla di WIP Limit)
• devono essere chiari il Commitment Point e il Delivery Point

Il Commitment Point è il punto di ingresso alla fase nella quale il servizio si prende l’impegno di deliverare il lavoro, mentre il Delivery Point è il punto di uscita dalla fase nella quale il servizio ha ultimato il lavoro: dopo questa soglia, il lavoro può essere considerato consegnabile al cliente.
Prima del Commitment Point, i work item sono considerati opzioni o idee sulle quali il servizio può o dovrebbe lavorare, ma non sono ancora state prese in carico; dopo il Delivery Point i work item sono considerati completi. Il tempo intercorso tra Commitment e Delivery Point è comunemente chiamato Lead Time, mentre il tempo che intercorre tra il momento in cui un work item viene ’consegnato al sistema’ e il Delivery Time viene chiamato Customer Lead Time, ovvero l’attesa che il cliente effettivamente percepisce fra quando effettua una richiesta e quando viene servito.
Questa distinzione è utile per poter fare le opportune valutazioni volte al dimensionamento del servizio: tenendo in opportuna considerazione la capacità del sistema. Questo ci permette di introdurre la legge di Little: riferendoci alle fasi che vanno dal Commitment Point al Delivery Point, il tasso medio di delivery (Delivery Rate) equivale al rapporto tra la media del WIP e la media del Lead Time. Possiamo generalizzare questo concetto applicando ad altre singole fasi del sistema, o a gruppi di fasi del sistema e chiamandolo Throughput (medio), definito come rapporto tra la media del WIP e media del tempo di attraversamento (Time in Process o Cycle Time) sulle fasi considerate. Una considerazione che nasce da quanto sopra è che, a parità di capacity, per ottimizzare il Lead Time (livello di servizio), è opportuno minimizzare il WIP (parallelismo, leggesi anche Context Switching). Dalla legge di Little deriva una pratica comune in Kanban per il monitoring e l’analisi dei flussi tramite il Cumulative Flow Diagram (CFD), che traccia il cumulato dei work item in ingresso e in uscita da ogni fase del sistema: tramite il CFD è possibile ottenere graficamente i valori medi di Throughput, WIP e Cycle Time.

Le Pratiche di Kanban

Kanban prevede sei pratiche generali per la gestione di un sistema kanban:

• Visualizzare: rendere il lavoro e le procedure visibili su una Kanban board è il risultato di un lavoro di collaborazione e comprensione del sistema e del processo, che porta ad allineamento e chiarezza sulle aree di miglioramento. Le fasi del processo che vanno a costituire una Kanban board posso essere definite in modo incrementale e affinarsi via via che il i vincoli e i punti di improvement vengono scoperti. Giovanni Puliti racconta in questo bell’articolo un percorso di definizione di una Kanban board. Tipicamente ogni colonna di una board rappresenta una fase del processo e possono essere usati dei raggruppamenti delle fasi in riga (Swimlane) per evidenziare dei particolari stati o delle condizioni. Una particolare tipologia di Swimlane, dedicata ai Work Item ad alta priorità, è comunemente chiamata Expedite Lane.
• Limitare il WIP: per abilitare un sistema in Pull, anziché in Push, e mitigare gli effetti del Context Switching è opportuno limitare il numero degli item in progress (ricorda il comune mantra in Lean e in Agile: ”Stop Starting, Start Finishing”). In Lean (in particolare: Toyota Production System, 3M) si parla di Muri - il sovraccarico - come uno dei tre principali sprechi da combattere, estremizzato nell’implementazione Toyota con la pratica del Just In Time). Ottimizzare il WIP in base alla capacità del sistema è un fattore fondamentale per migliorare la qualità e il livello di servizio.
• Gestire il flusso: in Kanban questo significa agire per massimizzare il valore, minimizzare il lead time e rendere il servizio predicibile. Nell’ottica di raggiungere questi obiettivi è fondamentale combattere i colli di bottiglia e lavorare a stretto contatto con il cliente, concordando i razionali per la prioritizzazione dei work item.
• Rendere le procedure esplicite: le procedure che si applicano al processo definiscono dei vincoli condivisi che tendono ad efficientare il lavoro; esse devono essere semplici, chiare, visibili e devono poter essere modificate da chi eroga il servizio, con l’obiettivo di massimizzare il valore e la predicibilità. Esempi di procedure possono essere il WIP limit, la Definition of Ready (condizioni che devono soddisfare i work item per poter oltrepassare il Commitment Point), la Definition of Done (condizioni che devono soddisfare i work item per poter oltrepassare il Delivery Point), le politiche di Replenishment (come selezionare i nuovi work item quando la capacity lo permette, ovvero quando il WIP è sotto una certa soglia).
• Implementare dei feedback loop: il feedback, come sappiamo, è un elemento fondamentale per il Continuous Improvement; Kanban definisce sette specifiche opportunità di feedback, dette anche Cadenze: meeting a intervalli regolari (la frequenza dipende dal contesto, tipicamente: daily, weekly, monthly, quarterly) che guidano l’evoluzione del processo nell’efficientamento del servizio.

Le sette Cadenze sono:
* Strategy Review: per la definizione e il miglioramento dei servizi offerti
* Operations Review: per comprendere l’equilibrio tra i servizi offerti e massimizzare il valore deliverato
* Risk Review: per valutare e mitigare i rischi legati alla delivery dei servizi
* Service Delivery Review: per esaminare e migliorare l’efficacia dei servizi
* Replenishment Meeting: per selezionare i nuovi work item che possono attraversare il Commitment Point e ispezionare gli item che potranno essere selezionati in futuro
* Kanban Meeting: daily meeting per allineamento e pianificazione del lavoro della giornata in modo auto-organizzato
* Delivery Planning Meeting: per monitorare e pianificare la delivery al cliente. • Migliorare in modo collaborativo, evolvere in modo sperimentale: Kanban è una metodologia volta al miglioramento continuo, che parte dal flusso di lavoro esistente e lo evolve empiricamente senza che vi sia prefissato un obiettivo a priori, ma con la consapevolezza che il sistema, in accordo al contesto nel quale esso vive, necessiti di un continuo mutamento.

## I Ruoli di Kanban
Kanban esorta al continuo miglioramento in forma collaborativa, nonostante ciò si è affermata nel tempo l’efficacia della specificità in due aree di responsabilità chiave: la prima legata al Commitment Point e la seconda legata al Delivery Point.
Queste responsabilità sono state sintetizzate nella metodologia stessa con la definizione di due ruoli:

• Service Request Manager: lavora al livello del Commitment Point, è responsabile di comprendere le aspettative del cliente, facilitare la gestione del Replenishment Meeting, della prioritizzazione dei work item e della loro compliance alla Definition of Ready
• Service Delivery Manager: lavora al livello del Delivery Point, è responsabile del flusso del sistema, dell’ottimizzazione del Lead Time e della rimozione dei colli di bottiglia. Si occupa di facilitare il Kanban meeting e il Delivery Planning.

Risorse Kanban

Oltre agli articoli citati in questa sezione, consigliamo:
* Il libro ”Essential Kanban Condensed” di David J Anderson e Andy Carmichael.
* Il libro ”Kanban in action” di Marcus Hammarberg e Joakim
Sunden.

• I nostri due podcast:

* Kanban Cadences
* Ruoli in Kanban

Extreme Programming

Cosa è Extreme Programming

Extreme Programming (XP) è un framework agile dedicato allo sviluppo software, che definisce valori e pratiche volti alla produzione di codice di qualità.
A differenza di framework quali Scrum o Kanban, XP non si focalizza sul processo, bensì sulle pratiche ingegneristiche: questo fa sì che Scrum e XP, ad esempio, possano essere adottati allo stesso tempo (vedremo più avanti come questo connubio siano non solo fattibile, ma anche auspicabile).
XP si basa su cinque valori, quattordici principi e ventiquattro pratiche (tredici pratiche e undici a corollario); le fondamenta per attuare le pratiche XP sono quattro attività basilari del processo di sviluppo software: sviluppo del codice, sviluppo del test, ascolto e design.
Cosa caratterizza XP, secondo Kent Beck:

• I cicli brevi di sviluppo, che si traducono in un flusso di feedback continuo.
• L’approccio alla pianificazione incrementale: la definizione di un piano generale, che si evolve durante la vita del progetto.
• La capacità di pianificare l’implementazione di funzionalità in modo flessibile, rispondendo alle mutevoli esigenze di business.
• Affidarsi a test automatici per monitorare i progressi dello sviluppo e consentire al sistema di evolvere e evidenziare i difetti in anticipo.
• La documentazione scritta è sostituita dalla comunicazione orale, dai test e dal codice.
• La consapevolezza che il design della soluzione evolve fintanto che il sistema vive.
• Fiducia nella collaborazione attiva di persone motivate.
• Si affida a pratiche che funzionano sia nelle dinamiche di team, che in quelle di progetto.

Vedremo di seguito perchè quando è efficace l’adozione di XP e il dettaglio di valori, pratiche e attività.

Perchè XP

Extreme Programming è stato sviluppato da Kent Beck (uno dei firmatari del Manifesto Agile) a partire dal 1996 ed è stato formalizzato per la prima volta dallo stesso Beck nel 1999 nel suo libro ‘Extreme Programming Explained’ (la seconda edizione del libro è disponibile su Amazon QUI).
Nonostante il nome ‘programmazione estrema’, che potrebbe essere fuorviante, vedremo come le pratiche XP tendano principalmente a valutare massimizzare l’efficacia del prodotto nell’accogliere i cambiamenti dei requisiti e a rilasciare software con un rischio controllato.
Le condizioni nelle quali XP risulta particolarmente efficace possono essere riassunte come segue:

• Situazioni nelle quali i requisiti variano velocemente.
• Progetti con una data di scadenza stringente e un elevato rischio dovuto all’utilizzo di nuove tecnologie.
• Gruppi di sviluppi piccoli.
• Le tecnologie utilizzate permettono l’automazione di test di unità e test funzionali.

A QUESTO link potete trovare un’interessante approfondimento sul tema ‘quando XP dovrebbe essere utilizzato’.
Da tenere in considerazione che, così come per Scrum, anche per XP avere dei team co-locati è senz’altro una caratteristica che ne facilita l’utilizzo e la pratica; d’altra parte questo non può essere considerato un vincolo ferreo, a nostro parere, dato che il mondo del lavoro sta sempre più accogliendo il remote working e le tecnologie, così come gli strumenti e i processi, stanno sempre più facilitando questo tipo di approccio.

Così come alcune condizioni esaltano l’efficacia di XP, altre la limitano fortemente; fra queste, vogliamo citarne un paio, non così inusuali:

• Sistemi nei quali i vincoli sugli scenari di utilizzo sono (volutamente o casualmente) laschi: in questi casi le condizioni di funzionamento del sistema non sono sempre note a priori e le casistiche di adozione (e do testing del sistema risultano impredicibili). Un esempio relativamente comune è l’integrazione fra due o più sistemi che non condividono interfacce con contratti specifici.
• Sistemi legacy instabili dove la complessità e il volume del codice comporterebbero un effort-XP smisurato rispetto alla banda a disposizione.

A QUESTO link potete trovare un’interessante approfondimento sul tema ‘quando XP non dovrebbe essere utilizzato’.

Valori di Extreme Programming

Vediamo i cinque valori sui quali XP si basa:

• Semplicità: faremo ciò che è necessario e richiesto, ma niente di più. Ciò massimizzerà il valore creato per l’investimento fatto fino ad oggi. Adotteremo piccoli e semplici passi verso il nostro obiettivo e mitigheremo i fallimenti man mano che si verificano. Creeremo qualcosa di cui siamo orgogliosi e lo terremo a lungo termine a costi ragionevoli .

XP incoraggia ad iniziare sempre con la soluzione più semplice ed aggiungere funzionalità extra in un secondo momento. Una delle caratteristiche dell’approccio di Extreme Programming è la progettazione del software basata sulle esigenze contingenti, piuttosto che il design e l’architettura per il domani (spesso viene utilizzato l’acronimo YAGNI - You ain’t gonna need it - ovvero - Non ne avrai bisogno -). Anche in XP troviamo più di una caratteristica che ricorda il principio del ‘last responsible moment’: è bene sottolineare che questo tipo di approccio comporta inevitabilmente un rework; la sua forza, d’altronde, è proprio quella di non ipotizzare soluzioni a lungo termine quando non abbiamo certezze (ricordiamo che una delle condizioni che massimizzano l’efficacia di XP è proprio un contesto con requisiti che cambiano frequentemente).
Tutto ciò ricorda molto il decimo principio agile: Simplicity - the art of maximizing the amount of work not done - is essential.

• Comunicazione: tutti fanno parte del team e comunichiamo faccia a faccia ogni giorno. Lavoreremo insieme su tutto, dai requisiti al codice. Creeremo insieme la migliore soluzione al nostro problema .

Una comunicazione efficace fra il team di sviluppo e gli stakeholder, ma anche all’interno del team favorisce le performance e la qualità del prodotto e, soprattutto, abbassa il rischio di divergenza fra le aspettative dei clienti e l’incremento di prodotto.
Tutto ciò ricorda molto il secondo valore agile (Customer collaboration over contract negotiation) e il seguente dei cinque valori di Scrum: Apertura - I team di Scrum cercano costantemente nuove idee e opportunità di apprendimento. I team agili sono anche onesti quando hanno bisogno di aiuto.

• Feedback: ci impegneremo al massimo sul commitment di ogni iterazione, fornendo software funzionante. Portiamo in demo il nostro software il prima possibile e frequentemente, ascoltiamo i feedback attentamente e apportiamo di conseguenza le modifiche necessarie. Parleremo del progetto e vi adatteremo il nostro processo, non viceversa .

Grazie ad un feedback frequente, il team può identificare le aree di improvement e rivedere le sue pratiche e i suoi processi. Il valore del Feedback è strettamente legato anche ai valori di Comunicazione e Semplicità: una comunicazione efficace e diretta esalta la qualità del feedback; un design semplice massimizza l’efficacia del feedback, permettendo una conversazione focalizzata.

• Rispetto: *ognuno di noi prova e dimostra all’altro il rispetto che merita, in quanto team member stimato. Tutti contribuiscono al valore, anche semplicemente con l’entusiasmo. Gli sviluppatori rispettano le competenze dei clienti e viceversa. Il management rispetta il nostro diritto di accettare la responsabilità e ricevere autorità sul nostro lavoro.
• Coraggio: saremo onesti su progressi e stime. Non ci prepariamo delle scuse per eventuali fallimenti, perché intendiamo avere successo. Non temiamo nulla perché nessuno lavora mai da solo. Ci adatteremo ai cambiamenti ogni volta che accadranno.

Come vedremo di seguito, più di una pratica incarna il valore del coraggio. Una di queste pratiche è quella di progettare e codificare sempre per l’oggi e non per il domani. Il coraggio consente essere confidenti con il refactoring del codice, quando necessario e permettere alle modifiche future di essere implementate più facilmente. Ancora: il coraggio è sapere quando eliminare il codice: rimuovere il codice sorgente che è obsoleto, non importa quanto sforzo sia stato fatto per creare quel codice sorgente. Inoltre, coraggio significa perseveranza: un programmatore potrebbe rimanere bloccato su un problema complesso per un giorno intero, quindi risolverlo rapidamente il giorno successivo, ma solo se si usa la perseveranza.

Principi di Extreme Programming

I Principi di XP sono visti come una specificazione dei Valori, permettono di dare indicazioni più concrete per guidare il comportamento. Vedremo di seguito i Principi basilari di Extreme Programming.

###Humanity
Il software è scritto dalle persone: dietro a questo semplice e, a prima vista, scontato principio, c’è una consapevolezza profonda dei bisogni che spesso vengono sottovalutati. Il processo di sviluppo deve tenere in considerazione le necessità della persone; Kent Beck, nella descrizione di questo principio, si riferisce implicitamente alla piramide di Maslow nel descrivere questo principio:

• prima di tutto le persone hanno bisogno di sicurezza, per sè stessi e per i propri cari, in modo da essere a loro agio e poter dare il meglio: il posto di lavoro non deve essere a rischio. Maslow esprime queste necessità nei primi tre livelli della piramide: ‘Psychological needs’, ‘Safety needs’.
• le persone si sentono realizzate quando provano un senso di appartenenza e si identificano in un gruppo, con il quale condividono degli obiettivi, quando possono contribuire alla crescita della società. Maslow esprime queste necessità nei seguenti due livelli della piramide: ‘Love and Belonging’, ‘Esteem’.
• le persone hanno bisogno della loro privacy e di spazio per raggiungere i miei obiettivi, che non contrastano con quelli del team. I dettagli della vita privata non rientrano nei piani del team, ma ognuno deve essere libero di poter auto determinarsi e poter dedicare del tempo per sè stesso (sustainable pace). Per Maslow questa è la punta della piramide: Self-actualization.

Economics

Tutto quello che facciamo deve essere pagato da qualcuno: assicurati che tutto quello che fai abbia un valore di business, altrimenti rischi che di ottenere solo un inutile successo tecnico. Le priorità sono date dal business e, spesso, ciò che conviene al business è di fare scelte che anticipano gli introiti e posticipano le uscite: questo principio ha un perfetto connubio con la pratica del Design Incrementale: ogni pratica che segue il principio del Last Responsible Moment tende a difendere le necessità del business.

Mutual Benefit

Ogni scelta deve sempre considerare il giusto compromesso fra tutte le parti interessate: quando si prende una decisione, soprattutto quando i vincoli di tempo sono stretti, questo principio va tenuto in considerazione per evitare di fare degli errori che pagheremo in futuro e creare delle situazioni di tensione fra le persone. Un semplice esempio può essere la scrittura di un’ampia documentazione tecnica del software che sto scrivendo: questa potrebbe aiutare un domani un altro sviluppatore, ma sicuramente rallenterà il mio lavoro oggi e costringerà entrambi a un notevole sforzo per la manutenzione e l’aggiornamento della documentazione. Il compromesso è quello di scrivere dei test automatizzati esaustivi, che aiuteranno me a definire il design ed essere più confidente nello sviluppo e nel refactoring, aiuteranno inoltre il prossimo sviluppatore che ne otterrà gli stessi benefici.

Self-Similarity

Quando la natura trova una forma che funziona, la usa
ovunque può; lo stesso principio si applica allo sviluppo del software: prova a copiare la struttura di una soluzione in un nuovo contesto, anche su scala diversa. Per chi già conosce o ha letto di Scrum@Scale, questo principio non suona come nuovo.
Pensiamo alla pianificazione trimestrale, dove vengono trattati i Temi e si pianificano le Storie, lo stesso principio su usa su scala settimanale, dove si trattano le Storie e si pianificano i Test (solitamente ‘System-Level
Tests’); quotidianamente tratto i Test, decido quali test di unità sviluppare che mi faranno passare anche il System-Level Test e sviluppo il codice che mi farà passare questi test.

Improvement

Non tendere alla perfezione, ma cerca di perfezionare il tuo processo, il tuo design, le tue storie.
La frase ‘il meglio è nemico del bene’, o più precisamente ‘Best is the enemy of good enough’ dà un senso a questo principio XP, ma non lo chiarisce del tutto: dobbiamo rifuggire l’immobilismo causato dalla ricerca della soluzione perfetta e agire con il meglio che possiamo fare oggi; inoltre dobbiamo agire ogni giorno per perfezionare quello che abbiamo messo in campo: Extreme Programming punta a raggiungere l’eccellenza nello sviluppo software tramite il continuo miglioramento.

Diversity

I team di sviluppo software dove ognuno è uguale all’altro non sono efficaci: i team devono essere composti da persone con differenti capacità, attitudini e prospettive, in modo da sfruttare le diversità e l’intelligenza collettiva per trovare soluzioni ai problemi. I conflitti e le diverse opinioni all’interno del team sono considerate da XP delle opportunità e non situazioni da evitare. Il principio di Diversity si traduce nella pratica di Whole Team, che vedremo più avanti.

Reflection

I team performanti non si limitano a fare il loro lavoro, ma pensano a come possono farlo meglio, analizzano i loro successi e i loro fallimenti, non nascondono i loro errori, ma li evidenziano per poter imparare da questi.
I cicli trimestrali e settimanali includono del tempo per la riflessione del team: il principio di Reflection, oltre ad essere codificato anche nell’Agile Manifesto, risulterà familiare a chi già conosce Scrum. Il momento di riflessione ha due principali vincoli da rispettare:

• solitamente si analizzano azioni ed accadimenti del passato, cosicché i feedback possano riferirsi a qualcosa di concreto;
• si prendono azioni per il futuro, in modo da tradurre la riflessione in qualcosa che abbia un valore tangibile.

Flow

Lo sviluppo software predilige un processo che prevede un flusso continuo, piuttosto che una serie di fasi successive. Prevedere un processo a step porta ad avere una peggiore gestione del rischio, una bassa frequenza del feedback e una scarsa predicibilità. In XP vengono rilasciati piccoli incrementi di valore frequentemente, l’integrazione e la build sono continui e il feedback sulla qualità del proprio lavoro avviene quotidianamente.

Opportunity

Impara a vedere i problemi come opportunità di cambiamento: per raggiungere l’eccellenza, i problemi devono diventare opportunità di apprendimento e di miglioramento. XP, come ogni Agile framework, non è fatto per nascondere i problemi, ma, al contrario, per farli emergere e ti offre principi e pratiche per poterli affrontare; parte dell’essere estremi, per XP, è proprio la scelta consapevole di trasformare ogni problemi in una opportunità: una opportunità per crescere professionalmente, per approfondire delle relazioni e per migliorare il software.

Redundancy

I problemi critici (alto impatto, alta probabilità) dovrebbero essere gestiti in più modi contemporaneamente: introdurre ridondanza ha un costo, ma concorre a mitigare i rischi, abbattendo la probabilità di accadimento: affinché un problema si verifichi, infatti, ogni fattore della ridondanza dovrebbe fallire. Ad esempio, i difetti software, in XP, sono risolti da diverse pratiche:

• Pair Programming
• Continuous Integration
• Sitting Together
• Real Customer Involvement
• Daily Deployment

Failure

Se non conosci il modo migliore per risolvere un problema, allora agisci per fallire in fretta: anche il fallimento ha un importante valore, ovvero la conoscenza e la consapevolezza che ne derivano. Talvolta il fallimento non è una scelta: ad esempio quando non si hanno sufficienti informazioni per poter prendere una scelta ponderata; in tali casi, anziché posticipare l’azione, una scelta vincente potrebbe essere quella di agire sbagliando (consapevolmente): preparati accuratamente per poter accogliere il feedback che deriverà dal fallimento, evidenzia i punti critici, le informazioni mancanti e le opzioni che potrebbero chiarirsi dopo l’attività, che possiamo considerare un esperimento. Questo principio richiama il mantra ‘fail fast, fail often’, citato ance dal PopcornFlow nella formula ‘learn fast, learn often’.

Quality

La qualità non è una variabile per la gestione di progetto: sacrificare la qualità non comporta necessariamente un incremento della Velocity, così come una maggiore qualità non comporta necessariamente un calo di Velocity. In XP la gestione di un progetto la si fa negoziando lo scope: i cicli di pianificazione trimestrale e settimanale sono momenti esplicitamente dedicati al monitoraggio e alla contrattazione dello scope.

Baby Steps

Il cambiamento deve essere suddiviso e implementato in piccoli passi: talvolta sembra conveniente attuare cambiamenti radicali tutto in una volta, ma questo approccio è spesso pericoloso. Quando le organizzazioni sono complesse, tanti piccoli cambiamenti possono costituire, insieme, dei cambiamenti radicali.
XP traduce in pratiche questo principio attraverso il Test-first programming e la Continuous Integration.
Due concetti che vogliamo solo accennare qui e approfondiremo in altre sezioni, sono alla base del Lean e del Toyota Production System:

• Kaizen: il cambiamento continuo, dato dall’attuazione di numerosi e piccoli cambiamenti incrementali.
• Kaikaku: un cambiamento radicale e implementato in un arco temporale limitato

Accepted Responsibility

La responsabilità non può essere assegnata; può solo essere accettata. Le pratiche XP rispeccchiano questo principio: le persone del team stimano i task e decidono autonomamente quali assegnarsi. Responsabilità e autorità viaggiano di pari passo: quando sono responsible di una certa attività, devo avere anche l’autonomia (autorità) per poter decidere come metterla in atto.

Pratiche di Extreme Programming

Le pratiche (o regole) di Extreme Programming dette ‘primarie’ possono essere adottate per iniziare ad applicare XP e migliorare il ciclo di sviluppo del software; l’ordine con il quale vengono messe in campo dipende dal contesto nel quale ci troviamo: potremmo aver bisogno dapprima di migliorare la nostra fase di pianificazione, oppure potrebbe essere prioritario adottare le regole relative alla programmazione per migliorare migliorare la qualità del prodotto.

Pratiche Primarie

### Sit Togheter
Il team deve avere a disposizione un open space dedicato: la comunicazione, uno dei cinque valori di XP è fondamentale per un team che lavora in Extreme Programming e, per migliorare l’efficacia della comunicazione, una delle più semplici ed efficaci azioni che si possono prendere è di mettere le persone nella situazione di poter comunicare senza barriere: si creeranno dei link che porteranno ad efficientare la comunicazione ed abbattere la burocrazia. Alcune possibilità sono:

• Posizionare i computer in un’area comune: questo incoraggia e facilita il pair programming.
• Dedicare delle zone dell’open space ai meeting ricorrenti, come il daily stand up: aiuta le persone a non perdersi la riunione.
• Posizionare dei tavoli per i meeting all’interno dell’open space: facilita le persone nell’organizzazione dei meeting e incoraggia ad allineamenti spontanei.
• Avere a disposizione delle whiteboard permette di ottenere dei meeting più efficaci e aiuta nell’allineamento aggiungendo il canale visivo alla comunicazione.

Whole Team

Un team deve avere tutte le competenze necessarie per il successo del progetto: questa è l’idea di cross-functional team, presente anche il altri framewor, come Scrum. Lo spirito di squadra e l’unione di intenti permette al team di essere resiliente e adattivo. Il team cresce e accresce le sue competenze coltivando la collaborazione e la cooperazione; il team può accogliere nuovi membri se servono nuove skill; se, invece, qualcuno dovesse risultare non più necessario, allora sarà per lui l’occasione di esserlo altrove.
Un team di oltre dodici persone inizia ad essere disfunzionale a livello comunicativo: mantenere una dimensione adeguata del team è importante per massimizzarne l’efficacia. Ricordiamo che Scrum consiglia che la dimensione di un team sia non minore di tre persone e non maggiore di nove.

Informative Workspace

Lo spazio di lavoro deve rispecchiare il tuo lavoro: un osservatore interessato dovrebbe essere in grado, attraversando il tuo workspace, di ottenere un’idea generale di come sta andando il progetto in quindici secondi. Molti team implementano (parzialmente) questa pratica utilizzando post-it e board cartacee attaccati al muro. L’ordinamento delle card trasmette, spazialmente, informazioni rapide.
Lo spazio di lavoro deve anche fare attenzione ad altre necessità: avere a disposizione acqua e snack offre comfort e incoraggiare interazioni sociali positive. La pulizia e l’ordine lascia le menti libere di pensare ai problemi. Mentre la fase di programmazione viene svolta in open space, altri spazi separati potrebbero lasciare alle persone un po’ di privacy, in orari dedicati.

Energized Work

Lavora solo quante più ore puoi essere produttivo e solo
quante ore riesci a sostenere: andare in burnout e rendere improduttivi i prossimi giorni di lavoro non fa bene né alla persona, né al team. In un progetto software non è difficile introdurre degli errori e smettere di produrre valore, ma quando si è stanchi è difficile saperlo riconoscere. Il consiglio è di non dedicare più tempo al lavoro, ma sfruttare meglio il tempo: ad esempio, potresti usare il seguente working agreement in due delle ore che quotidianamente dedichi allo sviluppo: spegni il telefono e le notifiche delle email, questo potrà portare già un miglioramento evidente.

Pair Programming

Scrivi il codice in coppia allo stesso PC: una delle pratiche più note e più utilizzate di XP, il pair programming è un dialogo fra due persone che programmano simultaneamente, esaltando, in tal modo, le fasi di analisi, design e test.
Il pair aiuta a chiarirsi le idee, facilita l’allineamento, esalta il principio della ‘Collective Code Ownership’ e mantiene alta la produttività: quando una persona è confusa, o frustrata, l’altra persona della coppia prende l’iniziativa. Quando si è in una fase di prototipazione o di indagine e si ritiene più efficace lavorare da soli, magari in parallelo, lo si può fare; in un secondo momento ci si allinea con il team, mantenendo il focus più sull’idea, che sul codice: questo permette di non condizionare gli altri sulla specifica soluzione e mettersi nelle condizioni di poter evolvere il sistema in modo collaborativo.

Pairing and Personal Space

Tieni in considerazione che ogni persona ha una sensibilità diversa nell’utilizzo dello spazio fisico: per alcune culture è più comune avere una prossimità fisica con il proprio interlocutore, in altri casi le persone sono più a loro agio mantenendo una maggiore distanza. Dobbiamo tenere in considerazione entrambi i casi per poter lavorare efficacemente con i nostri colleghi. Anche e soprattutto quando si lavora in pair, è fondamentale tenere in considerazione e rispettare le caratteristiche personali, dando la giusta attenzione ai segnali che le altre persone ti mandano.

Stories

Pianifica utilizzando funzionalità visibili all’utente: svincolati dal significato di ‘requisito’ come work item richiesto, concentrati sul problema del cliente e trova una soluzione innovativa per risolverlo.
Le User Story hanno tipicamente le seguenti caratteristiche:

• hanno una stima, data dal team, che indirettamente si riflette sull’effort necessario per sviluppare la funzionalità;
• hanno una descrizione breve;
• sono scritte su una card (solitamente in Post-it).

Ron Jeffries ha formalizzato le caratteristiche di una User Story secondo le ormai note 3C:

• Card: le User Story sono scritte su Card, che contengono la descrizione dell’obiettivo, la priorità e la stima.
• Conversation: la richiesta della funzionalità (meglio: l’esplicitazione del problema) viene comunicata dal cliente al team di sviluppo attraverso una conversazione (in larga parte verbale).
• Confirmation: il cliente comunica al team quali Acceptance Test verranno usati per accettare la storia una volta terminata.

Weekly Cycle

Pianifica il lavoro una settimana alla volta: durante questo meeting:

• Controlla il progresso del lavoro del team, in relazione a quanto pianificato
• Chiedi ai clienti di scegliere le storie da pianificare per la settimana successiva
• Suddividi le storie in task: i team member potranno committarsi sui task e stimarli.

Inizia la settimana scrivendo test automatici che verranno eseguiti quando
le storie sono completate. Con un ciclo di sviluppo così breve e con un piano di test pronto, dopo soli due giorni sarà facile capire se la pianificazione sarà rispettata o meno.
Kent Beck punta molto sul valore di suddividere le storie in task, avere per ogni task il commitment e la stima di un team member; questo approccio tende a valorizzare il senso di ownership.

Quarterly Cycle

Pianifica il lavoro un trimestre alla volta: ogni tre mesi rifletti sul team, sul progetto, sul suo progresso e sull’allineamento sui macro-obiettivi.
Durante la pianificazione trimestrale:

• identifica i colli di bottiglia;
• avvia le azioni correttive
• pianifica le epiche del trimestre
• scegli le storie per indirizzare i Temi
• focalizzati sulla big picture, dove il progetto si inquadra all’interno dell’organizzazione.

Il trimestre è una scala temporale largamente utilizzata all’interno delle organizzazioni: questo aiuta a sincronizzarsi con altre attività di business dell’azienda e con i fornitori.
Differenziare i Temi (o Epiche) dalle storie serve anche a contrastare la tendenza dei team a concentrarsi sui dettagli, senza riflettere sul quadro generale. Inoltre i Temi sono estremamente utili per disegnare una roadmap.

Slack

Nei tuoi piani introduci delle piccole attività che possono essere eliminate se sei in ritardo: è importante rispettare il commitment per coltivare un clima di fiducia; raggiungere pochi obiettivi concordati permettono di mantenere un rapporto saldo.
Lo Slack time può essere strutturato in molti modi: possiamo pianificare una Geek Week, oppure riservare il 20% della banda a Spike e attività di innovazione.

Ten-Minute Build

Esegui la build del sistema e tutti i test in dieci minuti: una build che impiega più di dieci minuti verrà eseguita molto meno spesso e perderai delle importanti opportunità per ottenere un feedback. Una build più breve non ti constringe a fare una pausa caffè nell’attesa. Un processo automatizzato di esecuzione della build e di tutti i test che impiega meno di dieci minuti mette nelle condizioni gli sviluppatori di potervi lavorare e apportare miglioramenti continuamente.

Continuous Integration

Integra e testa le modifiche dopo non più di un paio di ore: la fase di integrazione è spesso imprevedibile: se non eseguito frequentemente, potrebbe richiedere più tempo di quello dedicato allo sviluppo.
I modelli di integrazione possono essere sincroni (concludo le modifiche al codice, le integro, quindi vengono eseguiti i test e la build, ne attendo il termine e verifico che tutto sia corretto prima di ricominciare a programmare), oppure asincroni (integro le modifiche e ricomincio a programmare; i test e la build vengono eseguiti con un certo delay e vengo notificato dell’esito da una mail o una notifica su un radiator). Kent Beck consiglia di tendere verso l’integrazione sincrona, cosicché la coppia possa avere il tempo di riflettere su ciò che ha fatto, nel momento in cui l’ha fatto.

Test-First Programming

Scrivi un test automatico che fallisce prima di modificare qualsiasi codice: il test-first programming indirizza diversi problemi in una sola volta:

• Evoluzione minimale dello scope: dichiarando esplicitamente ciò che il programma dovrebbe fare, si evita di scrivere codice ‘just in case’, che potrebbe non servire, ma potrebbe comunque generare bug.
• Accoppiamento e coesione: se risulta difficile scrivere il test, questo è un segnale di un probabile problema a livello di design. Un codice è facilmente testabile se è liberamente accoppiato e molto coeso (Coesione significa che una classe dovrebbe rappresentare un unico concetto; Accoppiamento: una classe dipende da un’altra mentre usa gli oggetti della classe)
• Fiducia: scrivendo codice testato, aiuterete i vostri colleghi ad avere fiducia in voi e nel vostro codice.
• Ritmo: scrivere prima il test aiuta a essere focalizzati sull’obiettivo e non perdersi nella scrittura del codice.

Incremental Design

Investi del tempo ogni giorno nel design del sistema: quando ci si rende conto che il design dovrebbe essere migliorato per adattarsi alle necessità del progetto, allora è opportuno lavorarci in modo iterativo e incrementale. Tieni sempre in considerazione il rapporto fra i costi dei cambiamenti (di design) e i costi dei bug. Tieni monitorato il tuo sistema e adattalo velocemente alle esigenze, evitare di arrivare nella situazione in cui il costo di un cambiamento sia drasticamente alto. L’indicazione che dà XP sul Design Incrementale (o emergente) non è che progettare in anticipo sia necessariamente un male, ma il design fatto vicino a quando viene utilizzato è più efficiente. Le best practice che esaltano il design emergente sono il riuso del codice e il continuo refactoring.

Pratiche a corollario

Dopo aver messo in campo le pratiche primarie, è possibile focalizzarsi sulle pratiche a corollario; è importante rispettare l’ordine se si vogliono evitare dei possibili disastri.
Ad esempio: il Daily Deployment è una pratica che può essere messa in campo solo dopo aver lavorato sulla qualità e aver portato il rate dei difetti vicino allo zero, grazie alle pratiche primarie di Pair Programming, Continuous Integration e Test-First Programming.

Real Customer Involvement

Rendi parte del team le persone che sono direttamente influenzate dal prodotto del team. Lascia che i clienti visionari diano il loro contributo durante i Planning trimestrali e quelli settimanali. Se riesci a rendere il prodotto del team veramente prezioso per il cliente, quest’ultimo pagherà pur di partecipare allo sviluppo. Mettendo insieme il cliente finale (chi ha un bisogno) e il team (chi può soddisfare questo bisogno), riuscirai a minimizzare gli sprechi e massimizzare il lavoro non svolto. L’impegno del team sarà quello di soddisfare il cliente con il minimo effort e cercare di mantenere il prodotto meno specifico possibile, in modo che possa soddisfare anche le richieste di altri clienti.

Incremental Deployment

Quando devi rimpiazzare un sistema legacy, fallo gradualmente. Bisogna fare attenzione al fatto che non stiamo parlando di come implementare il nuovo codice (es: strangulation vs greenfield), ma di come farne emergere il valore e acquisire i feedback (ovvero: come portarlo in produzione): sostituisci una piccola funzionalità e mandala in produzione raccogliendone i feedback, magari utilizzando un A/B testing: questo ti permetterà di mitigare i rischi di fallimento.

Team Continuity

Mantieni stabili i team efficienti. Le performance di un team non sono date solo dalla somma delle hard skill, ma anche dall’equilibrio che il team stesso riesce a stabilire. Il tutto è maggiore della somma delle parti. Spesso la programmazione delle risorse basata sulle hard skill e sulla schedulazione è una attività di micro-management che porta a una disottimizzazione a livello sistemico. Mantenere team stabili può voler dire che il core team rimane stabile e un limitato numero di team member può fare job rotation in base alla necessità.

Shrinking Teams

Man mano che il potenziale di un team aumenta, mantieni stabile il carico di lavoro e riduci gradualmente le sue dimensioni. Quando un team inizia ad avere troppo pochi membri (molto competenti), fondilo con un altro team di ridotte dimensioni. Kent Beck racconta come questa pratica derivi dal Toyota Production System; ho trovato questa idea illuminante: piuttosto che aumentare il carico su un team e renderlo potenzialmente un anello debole come rischio per la delivery, porta le competenze su altri team e fai crescere il sistema.

Root-Cause Analysis

Ogniqualvolta venga rilevato un difetto dopo lo sviluppo, elimina il difetto e la sua causa; l’obiettivo è duplice: evitare che il difetto si ripresenti e far sì che il team impari dai propri errori.
In XP il fix di un bug si schematizza in 4 passi:

• Scrivi un end-to-end test che riproduca il difetto;
• Scrivi un test di unità, con scope più ridotto possibile, che riproduca il difetto;
• Correggi il sistema in modo che il test di unità passi; questo farà passare anche il test end-to-end (in caso contrario, modifica il test di unità);
• Una volta che il difetto è risolto, capisci perché il difetto era sfuggito e metti in campo le modifiche necessarie per prevenire questo tipo di difetto in futuro.

Taiichi Ohno, padre del Toyota Production System, ci lascia un fondamentale strumento per questa ultima fase: la cosiddetta Five Whys Analysis: chiediti cinque volte il perché il problema si è verificato, raggiungendone la radice e lavora su quella.

Shared Code

Chiunque nel team può migliorare qualsiasi parte del sistema in qualunque momento. Avere una responsabilità condivisa sul codice del sistema massimizza la resilienza del team. Una possibile obiezione è che una ownership non definita riduce il senso di accountability: per evitare che questo succeda è opportuno che ci sia un forte senso di responsabilità collettiva all’interno del team; alcune pratiche che possono aiutare nel senso della Collective Code Ownership sono il Pair Programming e la Continuous Integration.

Code and Tests

Manutieni solo il codice e i test come artefatti permanenti: la documentazione può essere generata dal codice di produzione e dai test. Questa pratica può essere messa in campo in modo incrementale, riducendo la documentazione prodotta un po’ alla volta; ad esempio, il manuale utente potrebbe essere un tipo di documentazione più difficile da superare, rispetto alla documentazione tecnica.

Single Code Base

Esiste un unico code stream: puoi sviluppare su un branch temporaneo, ma non lasciare vivo per più di qualche ora. Questa pratica non intende ovviamente limitare la modularità del sistema, si riferisce piuttosto a sottolineare il costo del backporting in caso di più versioni contemporaneamente in produzione. Se si hanno molteplici code base contemporaneamente attive, ci troveremo inesorabilmente in contesti di lavoro bug prone, con alta probabilità di introdurre difetti e regressioni: in questi casi è opportuno mettere in atto un piano per ridurre gradualmente le versioni in produzione.

Daily Deployment

Manda in produzione il codice ogni notte: il gap fra il codice in sviluppo e il codice in produzione è un ritardo di feedback che può tradursi in un rischio per lo sviluppo. Questa pratica risulta difficile, se non impossibile da applicare, qualora non siano state messe in campo altre pratiche primarie, in modo da limitare il defect rate, automatizzare l’integrazione e la build del sistema, rendere incrementali il roll out e il roll back del sistema. Il Daily Deployment, inoltre, richiede un processo di product management e, in particolare, di prioritizzazione, estremamente efficace e in sintonia con il cliente, al fine di ricevere feedback immediati sui nuovi sviluppi.

Negotiated Scope Contract

I contratti che stipuli con il cliente abbiano tempi, costi e qualità fissi, ma lo scope deve poter essere negoziato in corso dello sviluppo del sistema. Anzichè scrivere contratti di lunga durata che prevedono elevati costi per le change request, scrivi più contratti brevi, con bassi costi per i cambiamenti.

Pay-Per-Use

Con i sistemi Pay-Per-Use il sistema addebita i costi al momento dell’utilizzo, rendendo i soldi l’ultimo feedback per lo sviluppo. Questo sistema stimola al miglioramento continuo.
Un’alternativa al Pay-Per-Use è il modello a sottoscrizione, nel quale l’utilizzo del software viene pagato mensilmente o trimestralmente: con questo modello, il team può utilizzare la customer retention come misura dell’efficacia del proprio operato.

Scrum

Cosa è Scrum

Scrum è un framework agile dedicato a supportare lo sviluppo di prodotti in contesti complessi; a differenza di Extreme Programming, Scrum non si dedica alle pratiche tecniche, ma al processo di sviluppo del prodotto.
Le nozioni base di Scrum sono riportate, dagli ideatori del framework, in una guida, che è possibile consultare liberamente sul sito Scrum Guides: in questa sezione ci atterremo a quanto riportato nella Scrum Guide per descrivere il framework, cercando di contestualizzarlo secondo la nostra esperienza.

Scrum si caratterizza per essere un framework (ovvero un insieme di indicazioni non prescrittive, legate fra loro da alcune regole) da applicare in contesti complessi per determinare i processi e le tecniche più efficaci al fine di massimizzare il valore prodotto.
La teoria di Scrum è molto sintetica e semplice da interpretare; comprendere a fondo e saper applicare Scrum richiede invece grande costanza e applicazione.

I tre numeri che sintetizzano Scrum sono:

• 3 Ruoli
• 5 Eventi
• 3 Artefatti

Il 353 è il cuore di Scrum: tutto ruota attorno al 353 ed ogni suo elemento è fondamentale per il giusto equilibrio e l’efficacia del framework; in questa sezione ne vedremo i dettagli.

Perché Scrum

Come ormai sappiamo, alla base del nostro viaggio (ed anche di Scrum) ci sono la teoria della complessità e l’empirismo: la storia ha verificato che, quando trattiamo prodotti e contesti complessi, il buon vecchio approccio legacy di Project Management nel quale tutte le attività venivano pianificate a priori, spesso da un unico eroe, non funziona: dobbiamo accettare che la realtà è in continua evoluzione e che le conoscenze sono distribuite; é quindi necessario adeguare la pianificazione in modo incrementale e allargare il processo decisionale a chi veramente ha le competenze per valutare e decidere; in estrema sintesi, riteniamo che Scrum abbia, fra i suoi principali obiettivi, quello di massimizzare il valore attuando un’oculata gestione del rischio di progetto/prodotto e massimizzando la predicibilità.

I pilastri di Scrum

Tre pilastri sostengono Scrum: Trasparenza, Ispezione e Adattamento, essi sono alla base del processo di Continuous Improvement che, in sostanza, è ciò che alimenta Scrum e, verosimilmente, tutti i framework agili.
Per poter implementare il Continuous Improvement in modo efficace e sostenibile, Scrum teorizza che devono essere valorizzate tre ‘pratiche’, costantemente monitorate dal ruolo dello Scrum Master:

• Trasparenza: tutti gli aspetti di processo significativi devono essere visibili e le informazioni facilmente accessibili; questo è pilastro è uno strumento cardine per il Risk Management in Scrum.
• Ispezione: gli artefatti vengono frequentemente ispezionati per verificare eventuali variazioni indesiderate.
• Adattamento: da un’ispezione ne consegue tipicamente un’adattamento (della pianificazione, del processo e dei working agreements).

Scrum prevede quattro eventi nei quali viene implementata un’azione di inspect and adapt: il Planning, il Daily Meeting, la Review e la Retrospective; ne parleremo in dettaglio più avanti.

Scrum Team

Scrum si basa sul concetto di team per implementare pratiche e processi organizzativi atti a massimizzare l’efficacia in un contesto complesso: sappiamo che l’unica costante è il cambiamento ed in questa costante possiamo fondare le basi del nostro processo; è quindi necessario avere un sistema resiliente ed efficace e, al contempo, mantenere la trasparenza necessaria per potersi prontamente adattare al cambiamento.
Partiamo da quanto sopra come presupposto e descriviamo di seguito i ruoli di Scrum:

• il Product Owner (PO): vogliamo consegnare un prodotto di valore, dove il valore è valutato dal cliente, perciò necessitiamo di qualcuno (il PO) che conosca il mercato, sappia interpretare e valutare le necessità dei clienti in modo da massimizzare l’efficacia del team. Il PO è tipicamente un business man, sa cosa va fatto, ma non sa come; esso deve priorizzare le richieste del mercato e, per questo, il PO è una singola persona e non un comitato. Per quanto detto, fra le responsabilità del PO ci sono le seguenti attività:

* Esprimere chiaramente (per gli stakeholder e per il team) e ordinare gli item del backlog, al fine di massimizzare il valore del team di sviluppo.
* Assicurarsi che il Product Backlog sia visibile e trasparente a tutti.

• il Development Team: vogliamo avere un processo di sviluppo efficiente (sfruttare al meglio le potenzialità e le competenze di ognuno), e resiliente (non lavoriamo a silos, ma investiamo sul knowledge sharing e sul lavoro di squadra), perciò lo sviluppo del prodotto non è delegato ai singoli, ma ai team (di dimensioni da 3 a 9 persone); ogni team è composto da tutte le competenze necessarie per poter creare e deliverare valore, il valore che il Product Owner ha ritenuto prioritario. Il team di sviluppo è quindi cross-funzionale e auto-organizzato, la responsabilità individuale rimane all’interno del team, mentre all’esterno la responsabilità è del team nella sua interezza. Il dev team decide autonomamente come portare a casa il valore e lo fa servendosi del suo Scrum Master.
• lo Scrum Master (o Servant Leader): in un contesto nel quale il PO è focalizzato sul valore e il Dev Team è focalizzato sulla qualità, lo Scrum Master è il trait d’union che cerca di massimizzare l’efficacia dello Scrum Team praticando e divulgando l’agilità; esso aiuta il PO e il Dev Team:

* nel massimizzare la trasparenza e l’allineamento sul Product Backlog
* nello sperimentare tecniche efficienti per la gestione del backlog
* facilitando gli eventi Scrum
* facilitando il PO nella pianificazione e nelle altre attività
* facilitando il team nell’auto-organizzazione e nelle altre attività

Gli Eventi Scrum

Il Risk Management è compreso nel processo Scrum ed un esempio ne è il processo di sviluppo iterativo incrementale, nel quale ad ogni iterazione si vuole:

• rilasciare un incremento di prodotto
• applicare un improvement (inspect and adapt) figlio del feedback dell’iterazione (empirismo).

L’efficacia dell’improvement è direttamente legata alla qualità del feedback, che a sua volta dipende da quanto e come il nostro processo è riuscito ad essere trasparente: questo passaggio dovrebbe aiutare a comprendere l’importanza dei tre pilastri.

Il processo iterativo incrementale di Scrum si basa sui cinque eventi (Sprint, Planning, Daily, Review, Retrospective) che sono per il team quanto necessario per un efficace allineamento interno ed esterno e riducono, o azzerano, la necessità di ulteriori meeting. Ogni evento, compreso lo Sprint, è time-boxed: questo vuol dire che l’evento non può durare più du una certa quantità di tempo, ma può durare meno.

Sprint

Lo Sprint è un periodo di durata fissa durante il quale il team trasforma lo Sprint backlog in incremento di prodotto e conduce gli altri eventi Scrum.
Come detto, lo Sprint è time-boxed: la sua durata massima è fissa e non supera un mese (è piuttosto comune usare un time-box di due settimane); lo Sprint può tuttavia terminare prima del previsto, in alcuni casi particolari: infatti, qualora lo Sprint goal dovesse diventare obsoleto, il Product Owner termina lo Sprint prima del suo termine programmato (si parla di Sprint abort o Sprint cancellation) e, dopo averlo chiuso (Review e Retrospective), il PO e il Dev Team avviano lo Sprint successivo.

Durante lo Sprint il Goal rimane quindi invariato, ma lo scope dello Sprint può essere chiarito e rinegoziato fra il PO e il Dev Team, man mano che maggiori dettagli vengono compresi.
Se la durata dello Sprint è breve, allora sarà basso il rischio di produrre lavoro inutile qualora il Goal dello Sprint diventi obsoleto; dobbiamo chiarire che il solo processo del team non può, tuttavia, assicurare un’ottimale gestione del rischio: tutta l’organizzazione, infatti, deve essere corte e responsiva, organizzata per massimizzare il valore accogliendo il cambiamento.

Sprint Planning

Il lavoro eseguito durante uno Sprint viene preventivamente pianificato durante un evento time-boxed chiamato Sprint Planning. A questo evento partecipa il Team di Sviluppo, il Product Owner, lo Scrum Master e, se necessario, alcuni SME invitati dal team, la sua durata dovrebbe essere inferiore alle otto ore, in input a questo meeting ci sono:

• il Product Backlog
• il Product Increment dello Sprint precedente
• la capacity del team
• le performance che il team ha ottenuto nello Sprint precedente (si parla comunemente di ‘Velocity’).

L’output del Planning è lo Sprint Backlog e lo Sprint Goal. Al termine del Planning, il Team di Sviluppo si committa sul Goal di Sprint, ovvero un incremento di prodotto determinato da una lista ordinata di storie, e si è chiarito il come questo obiettivo verrà raggiunto. Nella pratica, quello che tipicamente succede è che alcune storie (secondo un ordine di priorità definito dal Product Owner) vengono selezionate dal Product Backlog e portate nello Sprint Backlog in base alla capacity del team; il dev team definisce il commitment point e, solitamente, vengono selezionate alcune storie stretch, eccedenti la capacity, sulle quali non c’è il commitment del team, ma che possono essere lavorate qualora ce ne sia l’opportunità.

Il Product Owner arriva allo Sprint Planning con un’idea dello Sprint Goal: l’obiettivo che intende centrare attraverso gli sviluppi che verranno selezionati per lo Sprint, ma formalizza questo obiettivo durante il Planning e con la collaborazione del Dev Team, che decide il commitment point (su quanti backlog item si committerà durante lo Sprint) e, di conseguenza, influenza significativamente la definizione dello Sprint Goal.

Lo Sprint Goal aiuta il team a focalizzarsi su un obiettivo comune, a limitare il WIP e a comprendere l’obiettivo di business, facendo di conseguenze e le giuste scelte tecniche e le opportune variazioni.

Nella prima parte del meeting, lo Scrum Team ha definito una lista ordinata di item sui quali si committa e l’obiettivo dello Sprint (il cosa); nella seconda parte, invece, il Dev Team deciderà come affrontare i backlog item per raggiungere l’obiettivo, tipicamente decomponendo gli item del backlog (le Storie) in task di breve durata (almeno per le prime storie dello Sprint). Qui il ruolo del PO è cruciale sia per fornire al dev team eventuali chiarimenti su alcune storie, sia per trovare dei possibili compromessi.

Al termine del meeting, il Dev Team racconta al Product Owner e allo Scrum Master come ha deciso di auto-organizzarsi per raggiungere lo Sprint Goal.

Sprint Planning: a cosa fare attenzione
Per nostra diretta esperienza, il Planning è uno degli eventi più cruciali e delicati di Scrum; condividiamo a riguardo i seguenti punti di attenzione:
* Un team con scarsa attenzione alla Definition of Ready e alla readiness del backlog, può accettare in Sprint attività che non riuscirà a portare a termine

• Se il Product Owner non ha chiaro il Product Backlog e le priorità, lo Sprint Goal non sarà definito, o non avrà un formato SMART: lo Sprint intero ne risentirà
• Se il Product Backlog non è pronto al Planning, il meeting tenderà a durare più del previsto e ne risentirà la parte di definizione dei task
• Serve allineamento con gli altri team, per assicurarsi di pianificare Spike e varie attività di interesse comune.

Daily Scrum

Il Daily Scrum (o Daily Meeting o Stand up Meeting) è un evento quotidiano condotto dal Dev Team, con un time-box di 15 minuti, al quale possono partecipare:

• lo Scrum Master per aiutare il team a mantenere il focus e rispettare il time-box
• chiunque altro nella veste di ascoltatore.

Il Daily viene condotto solitamente al mattino (sempre alla stessa ora) ed è estremamente utile sia per organizzare il lavoro del team, sia per mantenere alto il commitment e il focus, sia per ottenere preziose informazioni sulle previsioni dell’andamento dello Sprint.

La struttura del Daily può variare da team a team, ma solitamente si utilizza un timer per rispettare il time-box e permettere ad ognuno di poter parlare e, inoltre, tutti i team member sono soliti rispondere a queste tre domande:

• Cosa ho fatto ieri per permettere al team di raggiungere lo Sprint Goal?
• Cosa farò oggi che aiuterà il team a raggiungere lo Sprint Goal?
• Vedi qualche impedimento che potrebbe impedire al team di raggiungere lo Sprint Goal?

Molto spesso capita che il team, al termine dei 15 minuti, si prenda ancora un breve intervallo di tempo per ripianificare insieme la giornata e concordare le relative azioni.

Daily Scrum: a cosa fare attenzione
Per la nostra esperienza, le seguenti anomalie sono piuttosto comuni:

• i team tendono a non rispettare l’orario di inizio e il timebox del meeting: un evento ricorrente sul calendario e un pomodoro durante il meeting possono aiutare; inoltre è opportuno che lo Scrum Master sia presente ai primi Daily del team e che li aiuti a capire come condurre il meeting, fintanto che il team non avrà preso padronanza con questa cerimonia
• talvolta si tende a dimenticare su cosa abbiamo lavorato il giorno precedente: questo può essere sintomo di uno scarso pair, di un eccessivo context switching e di un utilizzo scorretto dei tool di issue tracking
• spesso capita che non ci sia chiarezza sul secondo punto del Daily: ricordiamoci che alla domanda “Cosa farò oggi che aiuterà il team a raggiungere lo Sprint Goal?” ci si aspetta una risposta che includa un commitment (ovvero un obiettivo chiaro) e non un generico impegno sulle attività dello Sprint: senza chiarezza su questo punto, l’auto-organizzazione del team potrebbe risentirne
• in assenza dello Scrum Master, capita spesso che il team dimentichi di porsi il terzo quesito del Daily: se non c’è attenzione agli impedimenti, le performance del team ne potrebbe risentire fortemente; se non utilizziamo l’intelligenza collettiva per migliorare, non ha molto senso lavorare in team.

Sprint Review

La Review è un meeting con time-box di massimo 4 ore, che viene condotto dallo Scrum Team (Dev Team, Product Owner e Scrum Master) al termine di ogni Sprint. In input alla Review c’è il Product Increment, in output c’è un Product Backlog aggiornato.

Se consideriamo questo evento nell’essenza originale di Scrum, senza scomodare dei framework di scaling, abbiamo due distinti obiettivi che coesistono in questo singolo evento due distinti: da una parte il Dev Team vuole presentare il Product Increment, ovvero i risultati ottenuti dal team con le sue fatiche durante lo Sprint, con l’aspettativa che questo soddisfi le esigenze del Product Owner (ricordiamo qui il concetto di Definition of Done); dall’altra parte il Product Owner, che ha tutto l’interesse a revisionare ed accettare le storie del Dev Team e a mostrarle agli stakeholder (invitati dal PO) affinché possa ricevere e integrare i loro feedback all’interno del Product Backlog, che, di conseguenza, verrà aggiornato.

Una possibile agenda per la Review è la seguente:

• il Dev Team sottopone il Product Increment al Product Owner, dimostrando le storie sviluppate; di conseguenza il PO accetta o rifiuta le storie del team; le storie rifiutate ritornano nel Product Backlog
• il PO mostra il Product Increment accettato agli stakeholder; il Dev Team è a disposizione per le Demo e per rispondere alle domande
• lo Scrum Team recepisce i feedback degli stakeholder e instaura con loro una conversazione al fine di rivedere gli obiettivi e le priorità, aggiornando le stime di delivery, il budget, la timeline
• il PO aggiorna il Product Backlog e ipotizza le prossime storie in priorità per il successivo Sprint, condividendole con gli stakeholder

Sprint Review: a cosa fare attenzione
In base alla nostra esperienza, consigliamo di fare particolare attenzione ai seguenti punti:

• il PO è interessato a massimizzare le performance del team, potrebbe avere difficoltà a rifiutare le storie “non Done”: una DoD aggiornata, trasparente e manutenuta può aiutare lo Scrum Master a evidenziare tale anomalia
• un Dev Team poco responsabilizzato o poco autonomo sul fronte della qualità, potrebbe portare in Review storie “non Done” senza segnalare al PO eventuali carenze tecniche: conviene mantenere delle metriche aggiornate anche sul fronte della qualità e fare particolare attenzione ai Requisiti Non Funzionali, sia nella Definition of Ready, sia nella Definition of Done.
• un PO troppo lontano dal mercato e dai clienti potrebbe far fatica a coinvolgere gli stakeholder: senza un feedback tempestivo, si rischia di avere un backlog mal prioritizzato e, di conseguenza, impiegare l’effort del team sugli obiettivi sbagliati.

Sprint Retrospective

Al termine di ogni Sprint, la retrospettiva è una cerimonia fondamentale del processo di inspect and adapt.
In input alla Retrospettiva c’è lo Sprint appena concluso, in output c’è un piano di improvement.
In questo meeting il protagonista è il Dev Team, ma anche lo Scrum Master deve esprimere tutte le sue doti di facilitatore e il Product Owner può risultare fondamentale per individuare azioni concrete e efficaci.
Il time-box di questo meeting è al massimo di 3 ore e lo Scrum Master dovrà assicurarsi che venga rispettato; lo spirito positivo e costruttivo del meeting viene talvolta sottolineato all’inizio del meeting recitando la cosiddetta Direttiva Prima, che non è però uno strumento ‘ufficiale’ e non è accettato e condiviso da tutti. Ogni rappresentate dello Scrum Team partecipa a questo meeting per migliorare quello che rappresenta: il Dev Team per l’auto-organizzazione del team, lo Scrum Master per il processo Scrum, il Product Owner per la gestione del Product Backlog.
L’obiettivo della Retrospettiva è di:

• ispezionare com’è andato lo Sprint appena concluso, in riferimento alle persone, le relazioni, il processo e gli strumenti
• identificare e ordinare gli elementi che più hanno inciso positivamente e quelli che potrebbero portare i maggiori miglioramenti
• creare un piano per implementare questi miglioramenti

Gli improvement che emergono come output dalla retrospettiva vengono pianificati dal team nello Sprint successivo.

Sprint Retrospective: a cosa fare attenzione
Per nostra esperienza, consideriamo i seguenti dei punti di attenzione per le retrospettive:

• I team poco maturi (vedi Tuckman Model) tendono a non affrontare i problemi: questo comporta inevitabilmente ad ottenere dei piani di improvement poco efficaci o nulli; è importante lavorare sulla maturità del team e coinvolgere tutto lo Scrum Team quando necessario
• I team poco responsabilizzati tendono a vedere tutti i problemi all’esterno: quando il team non ha (o non pensa di avere) la necessaria autonomia per mettere in campo azioni concrete, il piano di improvement prevederà principalmente azioni in carico ad attori esterni e, di conseguenza, sarà inattuabile. Consigliamo di lavorare sulla responsabilizzazione del team.
• Team che non hanno confidenza con questo evento tendono a portare problemi non azionabili e non uscire dal meeting con un piano: lo Scrum Master dovrebbe stare attento al time-box e assicurarsi di produrre un piano entro il termine del meeting.
• Team poco sensibili al concetto di Continuous Improvement tendono a non mettere in campo il piano: consigliamo di pianificare le azioni di improvement in testa allo Sprint Backlog e visualizzarle nella Sprint Board.

Gli artefatti di Scrum

Gli artefatti, in Scrum, non sono solamente dei prodotti necessari affinché lo Scrum Team crei valore all’interno dello Sprint, essi sono anche strumenti fondamentali per esaltare i pilastri di Scrum: la trasparenza, l’ispezione e l’adattamento trovano la loro massima espressione implementativa proprio nei tre artefatti: il Product Backlog, lo Sprint Backlog e il Product Increment.

Product Backlog

Il Product Backlog è l’unica sorgente di requisiti (nuove funzionalità e modifiche) che comportino qualsiasi modifica al prodotto; essa è espressa in una lista ordinata e l’unico responsabile per i contenuti di questa lista, per la sua visibilità e accessibilità e per l’ordinamento è il Product Owner.
Le caratteristiche di un Product Backlog sono le seguenti:

• non è mai completo e si esaurisce solo quando il prodotto esce di produzione
• è dinamico, varia continuamente e si adatta al contesto (requisiti di business, condizioni del mercato, tecnologia)
• può essere condiviso da più team, ma è unico per un prodotto.

Gli elementi del Product Backlog hanno tipicamente i seguenti attributi:

• hanno una descrizione (spesso nel formato User Story: Come <tipo_utente>, Voglio <obiettivo>, Affinché <motivazione>)
• sono ordinati (con un qualche algoritmo di prioritizzazione, che tipicamente include i seguenti fattori: valore, time criticality, effort e readiness)
• hanno una stima (spesso vengono usati gli Story Points)
• hanno un valore (direttamente o indirettamente collegati al business value)
• include una descrizione di come testare la storie, affinché possa rispettare la Definition of Done.

Il Product Backlog si evolve tramite la contribuzione di tutti gli stakeholder (questo artefatto deve essere pubblico, visibile, trasparente), mediata dal Product Owner (il responsabile dell’artefatto), tramite un processo di refinement: ovvero l’attività ricorrente alla quale collaborano il PO, il dev team e tutti gli stakeholder che possono contribuire a dare informazioni e che ha come obiettivi:

• aggiungere informazioni nel backlog e, di conseguenza aggiungere o rimuovere item nel/dal backlog
• stimare gli elementi del backlog (la stima dell’effort viene data dal dev team, mentre la stima del valore viene data dal PO)
• ordinare gli elementi del backlog, in base all’algoritmo di prioritizzazione scelto dal PO.
• rendere Ready (cioè pronti ad essere presi in carico dal team e pianificati in Sprint) gli elementi in testa al backlog: questo processo viene formalizzato rispettando la Definition of Ready

Dato un Backlog di prodotto, il Product Owner traccia il lavoro svolto e quello rimanente basandosi sulla stima del team e valuta queste informazioni per aggiornare gli stakeholder sul progresso del progetto (strumenti comuni di monitoraggio di queste informazioni sono Burn-Up e Burn-Down Chart, o Cumulative Flow Diagrams).
Ci preme sottolineare che questo approccio non è da considerarsi limitante per chi non lavora strettamente ‘a progetti’, poiché i concetti stessi di progetto e epica possono essere per molti aspetti sovrapposti.

Sprint Backlog

Lo Sprint Backlog è un artefatto la cui visibilità e gestione è di responsabilità del dev team ed è composto da due elementi:

• una lista di item selezionati dalla testa del Product Backlog, che equivale ad un commitment del team sulle funzionalità che svilupperanno nello Sprint (ovvero l’incremento di prodotto)
• un piano per portare ottenere questo incremento di prodotto

Lo Sprint Backlog viene formalizzato durante l’evento di Sprint Planning che, come detto precedentemente, ha come ulteriore output lo Sprint Goal.

In testa allo Sprint Backlog, inoltre, viene posizionato un item che identifica l’azione di improvement identificata come output della retrospettiva.

Durante lo Sprint, lo Sprint Backlog (item e piano) viene aggiornato e modificato dal dev team in base alle attività concluse dal team e alle informazioni che emergono lavorando sul backlog stesso: l’obiettivo rimane quello di ottimizzare gli sforzi del team per raggiungere lo Sprint Goal.
Mantenere questo backlog visibile e trasparente è fondamentale per mantenere tutti gli stakeholder (PO in primis) aggiornati sull’andamento dello Sprint.

Increment

Il Product Increment è composto da tutti gli elementi del backlog completati durante lo Sprint e gli Sprint precedenti ed ha una principale caratteristica: deve essere utilizzabile dagli utenti del prodotto; ciò implica che ogni elemento che esce da uno Sprint deve rispettare delle condizioni concordate con gli stakeholder (principalmente tramite i requisiti durante i meeting di refinement) e con il Product Owner (attraverso un documento formale, costantemente aggiornato, che censisce le caratteristiche che il Product Increment deve avere per essere accettato e che viene solitamente chiamato ‘Definition of Done’).

I Valori di Scrum

Il 3-5-3 di Scrum (3 Ruoli, 5 Eventi, 3 Artefatti), che abbiamo appena descritto, si regge sul rispetto delle regole del framework e sulla maturità dello Scrum Team, che il framework stesso descrive secondo cinque valori principali:

• Impegno
• Coraggio
• Focus
• Apertura
• Rispetto

Questi valori, in uno Scrum Team, permettono di esaltare i pilastri di Scrum (Trasparenza, Ispezione e Adattamento) e ottenere il massimo tramite l’auto-organizzazione e la tensione sana delle responsabilità, rispettando ruoli, eventi e artefatti.
Come facilmente comprensibile e descritto all’inizio di questa sezione, Scrum è un framework semplice da insegnare, ma complesso da implementare e richiede un’elevata maturità dello Scrum Team.

Wave 0: Transition Team

Inizia la fase di Training della transizione Agile: il primo ciclo di Assessment e Strategy si sono conclusi, abbiamo una foto dell’organizzazione, della sua cultura e storia, dei suoi processi, dei punti di forza e di debolezza.
Assieme agli sponsor principali è stata definita una prima versione della strategia di agilizzazione: si è deciso chi coinvolgere inizialmente e quali fattori di successo o fallimento dovranno essere monitorati. Siamo pronti ad iniziare il cambiamento e… probabilmente ci troveremo nella fase di incompetenza incosciente.

In questa fase iniziale è importante porre le basi per rispondere alle difficoltà che con estrema probabilità ci troveremo davanti a causa della resistenza al cambiamento.
L’entità che sta per trasformarsi dovrà affrontare un impegno che potrà risultare faticoso e di non breve durata, di conseguenza sarà importante assicurarsi che i principali sponsor della transizione Agile siano ben consci di cosa li attende e abbiano gli strumenti per poter rispondere alle difficoltà che li attendono.

Prima ancora di iniziare con l’agilizzazione dei team di produzione, è importante quindi che si formi un team di transizione, composto dagli stakeholder sponsor del cambiamento, persone che hanno l’autorevolezza per essere ascoltate e seguite dall’entità. Tanto più la comprensione dei principi e dei valori agili sarà radicata all’interno del Transition Team, quanto più sarà facile rispondere alle difficoltà che il processo di cambiamento ci porrà davanti. Il Transition Team ha bisogno di essere formato accuratamente, con training coaching dedicati; in questa fase possono essere altrettanto importanti attività esperienziali e attività di team building. Una esperimento da valutare può essere un piano di Safari del Transition Team in altre organizzazione, sia per imparare dall’esperienza di chi ha già superato la fase di transizione iniziale, sia per acquisire maggiore fiducia. La composizione del Transition Team è senz’altro un’attività delicata: il team, come ogni team, dovrà acquisire un’amalgama e un affiatamento tali da permettergli una buona performance, dovrà esservi allineamento sulla vision e sui working agreement e la skill matrix del team dovrà riuscire a coprire tutti gli ambiti gestiti dall’entità in transizione.

Il Transition Team, come tutti i team di produzione, seguirà verosimilmente le fasi di Tuckman, con profondità e ampiezza non noti a priori: nel periodo iniziale potrebbe essere importante la presenza assidua di un coach. Se l’entità in transizione copre un’area di processo produttivo particolarmente articolata, come detto in precedenza, sarà opportuno che il Transition Team sia formato in modo da coprire con le sue singole competenze tutte le fasi di quest’area: ogni elemento dovrà sentirsi rappresentato e, cosa ancor più rilevante, l’unione delle competenze e delle esperienze del Transition Team dovranno renderlo cross-funzionale e quanto più possibile autonomo e autorevole nelle sue scelte.

Tuckman Model

Il modello di Tuckman è un modello comportamentale relativo a gruppi di persone (team)
elaborato dallo psicologo Brune Wayne Tuckman nel 1965; non intendiamo dilungarci sulla
descrizione di questo modello, poiché in rete è possibile trovare materiale a sufficienza per approfondire, ci limiteremo ad una breve descrizione: il modello di Tuckman descrive lo sviluppo delle interazioni all”interno di un gruppo categorizzandolo in quattro fasi
successive:

• dapprima il gruppo si dedica alla ricerca dei limiti comportamentali interpersonali e ogni componente del gruppo ’prova’ le relazioni con gli altri componenti; questa fase si chiama Forming ed è una fase di pace apparente;
• nella seconda fase emergono i conflitti e ogni componente del gruppo cerca il proprio ruolo e la propria posizione all’interno del gruppo; da questa ricerca possono nascere dei conflitti e questa fase viene chiamata Storming;
• nella terza fase le singolarità del gruppo si sono assestate, si creano coesione e spirito di gruppo, rispettando ognuno i ruoli degli altri; questa fase è detta Norming;
• infine, nella quarta e ultima fase le singolarità del gruppo partecipano a creare la magia della cooperazione e dell’intelligenza collettiva: il gruppo è flessibile, resiliente e performante, questa fase è chiamata Performing.

Anche la quarta fase avrà a sua volta un termine, dovuto a variazioni interne o esterne al gruppo: il ciclo di Tuckman riprenderà dalla prima fase in avanti, con ampiezza e periodo di ogni fase verosimilmente diverse dal ciclo precedente.

Wave 1: il primo team (leader team)

Dopo aver fatto chiarezza sulla cultura e i processi dell’entità, formato il Transition Team, definito degli obiettivi, concordato gli indicatori, è arrivato il momento di lanciare il primo team.
Diversi fattori possono concorrere alla scelta del team, la sua composizione e il suo scope, vediamo quelli che per noi sono i principali:

• Il primo team dovrà essere un leader per i team che seguiranno: il leader team dovrà ispirare grazie ai suoi risultati, che dovranno essere pubblici e immediati da accedere; il leader team dovrà essere facile da seguire: gli strumenti e i processi dovranno essere semplici da condividere e comprendere, i team member stessi dovranno coinvolgere dal resto dell’organizzazione, alimentando un movimento di follower. Un esempio significativo e simpatico di come si crea la leadership lo da Derek Sivers.
• Il primo team si troverà ad affrontare nuove sfide e dovremo essere abili nel settare un contesto che accolga il team nel cambiamento: i team member si troveranno a mettere in discussione le loro sicurezze e potrebbero avere la necessità di conferme sui loro bisogni; in questa ottica ci può aiutare la piramide di Maslow.

Sarà importante, quindi: impostare il progetto di team concordando un working agreement di job safe - role unsafe: in questa nuova esperienza, il proprio posto di lavoro non è in ogni caso in discussione, non tutti saranno necessariamente in grado di guidare il cambiamento, in tal caso non è opportuno agire con accanimento, ma deve essere prevista una strategia che permetta alle persone di poter chiedere un riposizionamento senza che questo sia visto come un dramma.

• Il team sarà un’entità stabile, per quanto possibile (Scrum PLOP pattern: Stable Teams) e dovremo creare un senso di appartenenza al team, una sua identità nella quale riconoscersi e un contesto all’interno del quale sentirsi al sicuro e liberi di esprimersi. Sarà importante coltivare una leadership fluida all’interno del team, un meccanismo di rewards e un’abitudine a celebrare i successi, in modo che i risultati derivanti dal proprio lavoro quotidiano possano essere riconosciuti e la propria autostima possa crescere. Infine l’amalgama del team dovrà permettere di esaltare i valori agili e pianificare, sviluppare e monitorare le competenze e la professionalità dei team member; per questo punto potrà essere decisiva una valutazione sulla skill matrix del team e una progettualità sugli sviluppi T-shaped, PI-shaped, COMB-shaped delle persone e del team.
• Il leader team si troverà di fronte, per primo, a problematiche nuove, da affrontare con entusiasmo e proattività, di conseguenza sarà importante un elevato livello di engagement e, per questo, scegliere di formare il team a partire da una base volontaria potrebbe rivelarsi una scelta vincente. Prima di mettere in campo questo esperimento, ad ogni modo, sarà importante valutare accuratamente i diversi scenari che si potrebbero prospettare a fronte della richiesta di una candidatura spontanea e definire le strategie da azionare nei vari casi per matchare le condizioni dei due punti precedenti (questo potrebbe implicare, ad esempio, la definizione di alcuni vincoli stringenti nel job posting interno e l”eventuale ricorso ad una selezione diretta da parte del Transition Team, opzione che dovrà essere accuratamente specificata).
• Il leader team dovrà essere auto-organizzato e cross-funzionale: la bussola è il value stream e il team dovrà essere in grado di rilasciare valore in modo continuativo e autonomo; questo può voler dire studiare i processi di produzione dell’entità e valutarli in modo critico, individuando i path a lunghezza minima che portano dai requisiti agli ambienti di produzione. I vari uffici e i reparti potrebbero essere tagliati orizzontalmente per la composizione del team: potremmo voler passare da component team a feature team, eliminando una serie di interfacce che stanno solo rallentando la produzione del valore (Lean, Muda: waiting). Nella scelta del prodotto o servizio in scope al leader team sarà opportuno tenere in considerazione più fattori: il livello di rischio in base alla cultura di partenza dell’azienda, la situazione attuale del mercato di riferimento, le aspettative del management in termini di tempi, costi e valore prodotto (inteso anche come know how), etc… Un’interessante indicazione sulla scelta del prodotto/servizio per il lancio del team pilota la da Paolo Sammicheli in questo video; non mettere in gioco i prodotti/servizi e i relativi clienti che rappresentano la solida base economica dell’organizzazione, nè tantomeno rischiare con il team pilota le opportunità più promettenti per il futuro, ma attestarsi nel mezzo, in modo da poter programmare esperimenti safe to fail.

Creato il team, dovremo guidare l’inception, definendo uno obiettivo e uno scope chiari, un processo semplice e pulito, dei working agreement efficaci e condivisi internamente ed esternamente al team. Sarà importante quindi agire da subito sugli impedimenti, rimuovendoli direttamente, o evidenziandoli e scalandoli per la rimozione, settare dei quick win e celebrare pubblicamente i successi. Dovremo individuare i leader del cambiamento e sostenere le loro iniziative, partendo da queste persone con il coaching individuale; quindi gli esperimenti vincenti potranno essere selezionati e formalizzati, entrando a far parte di un kit che sarà reso disponibile anche ai futuri team.

Wave 2: partono altri team, si parla di scaling

Abbiamo lanciato il primo team, è l’ora di verificare i criteri di successo e fallimento che ci siamo imposti, in base alle metriche che abbiamo scelto e monitorato. Non c’è niente di più sbagliato che perseverare su un errore, dovremo quindi decidere in accordo con il Transition Team: il primo team è stato un successo e possiamo continuare con la strategia di agilizzazione su nuovi team, oppure è il caso di pivotare modificando le condizioni?

Nel secondo caso, ci troveremo ad dover valutare le motivazioni del fallimento del team ed effettuare una root cause analysis: uno strumento base per questo tipo di attività e lo Hishikawa diagram (o fishbone diagram), che potremo utilizzare in collaborazione con diversi attori (il leader team, il Transition Team, i coach, gli altri reparti). Al termine dell’analisi potremo concordare su diverse tipologie di azione: da una nuova formazione del leader team, alla rimozione di impedimenti chiave per modificare il contesto. In ogni caso sarà necessario iterare nuovamente con il leader team, eventualmente aggiornando i criteri di successo e fallimento e le relative metriche.

Qualora, invece, il leader team avesse raggiunto gli obiettivi settati, sarà arrivato il momento di lanciare nuovi team: in base alla strategia iniziale avremo deciso probabilmente quanti team lanciare, ma la composizione del team sarà definita solo in base ai feedback raccolti durante la wave 1 e, soprattutto, solo adesso potremo decidere se e quale framework di scaling è opportuno utilizzare. Come avrete notato, ci capita spesso di consigliare di rimandare scelte importanti, come la composizione dei team e la definizione del framework di scaling; qualora vi foste domandati come mai tendiamo a rimandare queste scelte fino all’ultimo momento utile, potreste approfondire il principio di Last Responsible Moment.
In base allo stato nel quale si trova l’entità che si sta agilizzando, potremo scegliere di fare scelte più conservative nella composizione dei nuovi team, o più ardite: il cambiamento si troverà probabilmente ancora sotto giudizio e dovremo capire se il mood in questo momento è guidato dall’entusiasmo o dalla diffidenza. In entrambi i casi sarà necessario non perder di vista il Value Stream e il Transition Team ci potrà aiutare in questo. Inoltre i team della wave 2 saranno comunque composti in modo da massimizzare la cross-funzionalità e l’auto-organizzazione. Per ogni team imposteremo success e failure criteria e metriche in base ai loro scope e agli obiettivi: alcuni di essi potranno avere un percorso impegnativo per la gestione del knowledge sharing e sarà quindi opportuno impostare un piano di formazione adeguato.
La vicinanza del Transition Team è ancora fondamentale e un buon modo per non perdere contatto con i team sarà quello di usare il principio del Gemba Walking.

Ci troviamo ora con più team che dovranno coordinarsi, sullo stesso prodotto o su prodotti distinti, probabilmente sullo stesso value stream e, quindi, quali e quanti responsabili del prodotto abbiamo identificato? Fare questa scelta in base alle competenze che l’entità ha a disposizione potrebbe rivelarsi un errore fatale, valutiamo invece quale configurazione può portare più valore all’entità e minimizzare il waste e i livelli di riporto: la comunicazione è tanto più efficace quanto meno sono le indirezioni. Inoltre: quale architettura sottosta al nostro prodotto o servizio e, soprattutto: qual è la vision dell’entità su questo fronte? Abbiamo a che fare con uno o più prodotti/servizi? Quale forma stiamo dando ai backlog: sono fra loro indipendenti o vincolati? Sulla base di queste valutazioni dovremo scegliere, insieme al Transition Team, quale framework di scaling utilizzare, tenendo bene a mente che la scelta che faremo condizionerà non solo i risultati dell’agilizzazione, ma anche l’architettura, i processi e le prestazioni dell’entità.

I framework di scaling Agile sono molti, ne citiamo solo alcuni: Scaled Agile Framework, Less, Nexus, Scrum@Scale: ognuno ha le sue peculiarità e può essere più adeguati di altri in determinate condizioni, ma quello che non dobbiamo mai dimenticare è la vision: il cambiamento, come sappiamo, è un processo molto faticoso e lo strumento di scaling che vogliamo utilizzare potrebbe facilitarlo o rallentarlo, per questo consigliamo di fare questa scelta non tanto sulla base delle condizioni correnti, ma sulla visione che l’entità ha di se stessa nel futuro.