Cosa vuol dire che le metodologie Agili possono funzionare soltanto in un mondo perfetto? Considerando anche i commenti degli altri, possiamo interpretarlo come: “Le metodologie Agili possono funzionare solo in un mondo perfetto perchè nella realtà esistono dei vincoli che non possono essere superati”

La risposta che ho dato quando mi è stato esposto questo dubbio è perfettamente in linea con il commento di Vieri del Bianco

In una recente intervista è stato chiesto a Kent Beck cosa voglia dire “essere agili” (il DOMANDONE…). La sua risposta mi ha decisamente colpito (estremamente sintetica e in definitiva illuminante): “My definition is that you accept input from reality and you respond to it”.
Ma questa è l’antitesi del mondo perfetto… io la interpreto con l’essere capaci di modificare gli strumenti/metodologie/pratiche/valori per plasmarsi sulla “realtà” (e la realtà non è solo il cliente, o l’ambiente di lavoro e le sue regole, ma anche la squadra con cui si ha a che fare).
Questo è, a mio avviso, il cuore dei metodi agili (e l’Agile Manifesto sembra confermarlo).

Pensate solo al motore della natura evolutiva delle metodologie Agili: la retrospettiva. Il team si interroga continuamente sul proprio metodo di lavoro e lo fa basandosi sia su dati soggettivi, ma sopratutto su dati oggettivi = metriche raccolte durante il processo produttivo, metriche che vengono stabilite basandosi su quelli che sono i reali obiettivi del progetto e quindi del suo committente. Questo comporta un continuo adattamento del team e del metodo che deriva da un confronto costante con i risultati ottenuti. Questa è l’essenza delle metodologie Agili: un estremo realismo, una vocazione alla trasparenza e alla comunicazione

Tuttavia, come è stato accennato nei commenti, a volte la realtà impedisce la corretta applicazione di alcune pratiche rendendole controproducenti, altre volte i valori e i principi vengono talmente disillusi da rendere impossibile l’adozione di una metodologia agile, è vero, non lo nego, anch’io mi sono trovato in situazioni simili e non ho potuto fare altro che arrendermi all’evidenza

Facciamo un ragionamento però: una delle critiche che vengono mosse alle metodologie Agili è quello di essere “acqua calda”, nient’altro che buon senso applicato, il che è sostanzialmente vero, ma quindi cosa vuol dire quando il buon senso non può essere utilizzato? Probabilmente quelli che consideriamo come vincoli sono in realtà vizi che possono e dovrebbero essere eliminati, vizi che in realtà rappresentano delle grosse opportunità di miglioramento

Al che sorge spontanea la domanda: “Quando dovremmo sfruttare l’adattabilità delle metodologie Agili per aggirare un ostacolo e quando invece l’ostacolo dovrebbe essere abbattuto?”. Ovviamente non esiste una risposta che può essere data a priori, un consiglio? In un momento di calma e lucidità identificate quali sono i vostri veri obiettivi, valori e principi, confrontatevi sempre con essi in maniera obiettiva e misurabile, se lavorerete per migliorarvi continuamente, siete sulla buona strada :-) Ovviamente lo scrivo più che altro rivolgendomi a me stesso :-)

Se avete altri commenti a riguardo mi piacerebbe sentirli, altrimenti possiamo passare alla prossima domanda: “Quale aumento di produttività possiamo aspettarci da un team che inizia ad adottare SCRUM? In quali tempi?”

Uno degli strumenti che utilizziamo durante i corsi è il “Backlog delle domande”: se qualcuno ha una domanda, può farla subito, se la risposta viene stimata di costo inferiore ai 30”, la risposta viene data immediatamente, altrimenti viene inserita nel Backlog (una pagina di un flipchart che tutti possono vedere). Durante la giornata dedichiamo un paio di pomodori per rispondere alle domande: Io e Matteo facciamo il ruolo del team = stimiamo le domande a seconda della complessità; i partecipanti al corso giocano il ruolo dei clienti = ogni partecipante vota la domanda per la quale vuole una risposta; finita questa attività di planning, rispondiamo alle domande in ordine di voto fino a consumare il tempo a disposizione

Ad oggi abbiamo fatto corsi ad oltre 200 persone, alcuni avevano una formazione tecnica altri no, alcuni erano programmatori altri no, alcuni erano giovani altri meno, alcuni avevano letto qualcosa sulle metodologie Agili altri erano totalmente digiuni, ecc… E’ facile immaginare la quantità di domande che sono state poste ed è altrettanto facile immaginare che non abbiamo avuto il tempo di rispondere a tutte :-) Ed eccoci arrivati al punto: volevo utilizzare il blog per riprendere alcune di queste domande, non per scrivere delle risposte, ma per continuare ad interrogarmi su delle questioni che troppo spesso do per scontante…

Durante l’ultimo corso che abbiamo tenuto, una ragazza ha espresso un dubbio che mi ha particolarmente colpito, la frase suonava più o meno così: “Apprezzo veramente i concetti e le pratiche che stanno alla base delle metodologie Agili, ma temo che possano funzionare solo in un mondo perfetto…”

Voi cosa le avreste risposto?

L’articolo indica alcune pratiche che possono essere utilizzate dai programmatori per “mantenere un programma nella propria testa”, inizialmente sia l’obiettivo dell’articolo che alcune delle pratiche proposte mi hanno un po’ disorientato in quanto in apparente netto contrasto con quanto dettato dalle metodologie Agili: “Se Paul Graham è un mito, e ha ragione, allora hanno torto le metodologie Agili?” No, hanno ragione entrambi, i principi che stanno alla base sono gli stessi, come al solito tutto torna :-)

Prendiamo per esempio una delle pratiche più forti fra quelle proposte: “Keep rewriting your program”; come dargli torto? Capita spesso che durante la scrittura di un programma un programmatore arrivi ad un momento in cui la sua conoscenza attuale del problema e della relativa soluzione non sia più rispecchiata dal codice, riscrivendolo potremmo inserire nel codice tale conoscenza e quindi otterremmo del codice migliore. D’altra parte molti conosceranno la “Sindrome del secondo sistema” e sapranno quindi che la maggior parte delle riscritture dei progetti software risulta fallimentare. “Come è possibile che entrambe queste evidenze empiriche siano vere? Come risolvono la questione le metodologie Agili?”

Cos’è il refactoring se non un’attività di continua riscrittura del codice? Kent Beck spiega perchè eXtreme Programming è eXtreme: tutte quelle pratiche che hanno dimostrato nel tempo di essere valide sono state portate all’estremo. La revisione del codice funziona? Bene, revisioniamo il codice sempre! = Pair Programming. La riscrittura di programmi porta a dei programmi con un design migliore? Bene, riscriviamo i nostri programmi continuamente! = Refactoring

Attraverso la pratica del refactoring possiamo trasformare (riscrivere) continuamente il nostro codice affichè rispecchi nella maniera migliore possibile la conoscenza che attualmente abbiamo del dominio del problema e della sua soluzione. Continuamente! Il trucco è sempre quello: se un’attività è rischiosa, difficile, costosa, ma potenzialmente di grande valore, quello che dobbiamo fare non è evitarla o prevenirla, ma trovare un modo per renderla meno rischiosa, meno difficile e meno costosa, mantenendone il valore inalterato (pensate per esempio alla Continuous Integration)

Al solito ci sono pratiche a corollario che portano il codice ad essere rappresentazione della nostra conoscenza:

• Unit Tests: come specifica eseguibile del comportamento dei componenti del nostro software
• Acceptance Tests: come specifica eseguibile delle funzionalità esibite dal nostro software
• Shared Code: fare in modo che il nostro codice sia leggibile a tutti i componenti del team (lo considero un super set di “Write rereadable code” dell’articolo di Graham)
• Domain Driven Design: sviluppare un linguaggio di dominio (Ubiquitous Language) all’interno del codice. Questa pratica potrebbe essere portata all’estremo scrivendo un’interprete per un DSL (Graham come Lisper a questo proposito ne sa qualcosa)

E’ estremamente semplice da disegnare e da tenere aggiornato, potrebbe sembrare una sciocchezza, ma non lo è: la complessità di disegno del grafico ci potrebbe portare ad utilizzare uno o più programmi specifici per il plotting, il che ci porterebbe a dover inserire manualmente i dati relativi, il che probabilmente ci porterebbe a considerare la possibilità di utilizzare uno o più software per memorizzare i nostri dati di processo in modo da poter automatizzare la generazione del grafico. Ne vale la pena? A mio parere questo è un’antipattern abbastanza comune che dovrebbe essere accuratamente evitato, per questo consiglio tutti i miei team di disegnare i loro grafici di processo a mano e di fare il traking dopo o durante lo stand-up meeting.

E’ estremamente intuitivo: sull’asse verticale sono rappresentati i punti storia, ovvero una misura della complessità (cumulativa) delle funzionalità che dovremmo implementare, sull’asse orizzontale sono rappresentati i giorni che abbiamo a disposizione per completare il nostro lavoro. L’ho definito “intuitivo” sia perchè è semplice identificare l’obiettivo (consumare i punti storia entro la data prevista), sia perchè basta un colpo d’occhio per capire se siamo in ritardo o se siamo in anticipo sulle nostre previsioni: se siamo sopra l’andamento ideale, siamo in ritardo, altrimenti siamo in anticipo

Un’altra caratteristica “Agile” di questo tipo di grafico è la possibilità di identificare molto rapidamente dei trend, possiamo avere feedback immediato su quello che è lo stato del progetto oggi e sullo stato in cui sarà il progetto domani se non modificheremo il nostro processo produttivo.

Ultimamente ad uno dei miei team è stato affidato un progetto che dovrà essere sviluppato contemporaneamente al loro progetto principale. Ovviamente c’è stato dato un budget di tempo (e quindi di costo) all’interno del quale abbiamo negoziato le funzionalità che dovranno essere implementate. Durante una retrospettiva ho consigliato di tener traccia dell’andamento di questo progetto (che ha uno scope ben definito a dispetto del loro progetto principale) attraverso un burn down chart. In quel momento mi sono accorto che per questo tipo di progetti il burn down chart nel suo formato originale può portare a dei problemi.

Il progetto in questione è limitato nello scope e nel tempo, ma deve anche essere limitato nell’effort che il team può spendere per la sua realizzazione. Avendo come unica metrica il burn down chart tradizionale correremmo il rischio di dedicare troppe energie (leggi persone/ore) per mantenere ideale l’avanzamento di questo progetto secondario a discapito del progetto principale

Quando ci si trova di fronte ad una situazione di questo genere una soluzione potrebbe essere quella di tener traccia, all’interno dello stesso grafico, anche dell’effort. Supponiamo che il nostro budget preveda 5 mesi uomo, calcolando 10 pomodori/giorno/uomo (un pomodoro è un’unita di tempo di 25 minuti), per 20 giorni/mese/uomo, fanno un totale di 1000 pomodori che possiamo spendere come team su questo progetto. In questo modo abbiamo un grafico che non solo ci comunica l’andamento del progetto, ma lo mette in relazione con l’effort spesa. Per esempio nell’immagine qui di fianco possiamo vedere come l’andamento del progetto sia praticamente perfetto, a discapito però di un’utilizzo eccessivo di risorse

Software development is a complex process that requires lots of comunications. The Daily Scrum meeting is where the team comes to comunicate

Ken Schwaber inizia così il capitolo dedicato a questa pratica all’interno del suo libro, pratica che, come altre cose nel caos informatico, ha molti altri nomi

• Daily Scrum Meeting
• Stand-Up Metting
• Daily Stand-Up Meeting
• Daily Status Meeting

In pochi secondi, cos’è lo Stand-Up Meeting? E’ un momento che si ripete tutti i giorni alla stessa ora, nel quale tutto il team si raduna in uno stesso luogo per fare il punto della situazione attuale. In particolare ogni componente del gruppo viene a conoscenza di cosa hanno fatto gli altri il giorno prima, quali difficoltà hanno incontrato e cosa faranno oggi

La stessa pratica viene citata in molti libri facendo riferimento a metodologie agili differenti, ma conservandone le caratteristiche

• Limitata nel tempo, 10/15 minuti al massimo
• Tutti i partecipanti devono stare in piedi (ecco perchè Stand-Up) per sottolineare la brevità dell’evento
• Si tiene tutti i giorni nello stesso posto e alla stessa ora, principalmente per dare la possibilità alle persone esterne al team di sincronizzarsi in modo da poter partecipare anche se passivamente (vedi dopo), ma anche per dare autorevolezza all’evento (non è una cosa fatta così per fare, fa parte del nostro processo produttivo). Molti utilizzano (e consigliano) questo momento come l’inizio della giornata lavorativa
• Ci si riunisce in cerchio senza impedimenti nel mezzo, per enfatizzare il fatto che si vuole realizzare una comunicazione di tipo uno a molti
• Si parla a turno uno alla volta, spesso per identificare chi ha la parola viene utilizzato un token (un pupazzo, un cappello, …) utile sopratutto nei team più numerosi
• Chi ha la parola comunica al team rispondendo a tre domande
  • Cosa ho fatto ieri
  • Quali difficoltà/ostacoli ho incontrato
  • Cosa farò oggi
• Prevalentemente il flusso di comunicazione è interno al team, gli esterni al team possono (sono invitati a) partecipare solo in maniera passiva

Molte persone credono che lo Stand-Up Meeting sia rispondere a queste tre domande, ma in realtà non è così importante a quali domande si da risposta, ciò che è veramente importante sono le informazioni che vengono scambiate all’interno del team e il raggiungimento degli obiettivi che questa pratica si prefigge

• Identificare/sottolineare gli obiettivi del team
• Identificare/sottolineare gli ostacoli in modo che altri componenti del team possano rimuoverli
• Identificare/sottolineare lo stato attuale, i progressi fatti e i piani futuri
• Migliorare la comunicazione all’interno del team
• Migliorare la collaborazione all’interno del team

Raggiungere, anche parzialmente, questi obiettivi “spendendo” solo 10/15 minuti al giorno sembra proprio un buon affare. Iniziare con questa pratica è semplice, ma quali sono gli elementi che identificano un buon Stand-Up Meeting?

• Rapido: massimo 10/15 minuti, se andate oltre con una certa regolarità rendete evidente questo fatto facendo squillare un timer alla fine dei 15 minuti di modo che tutti sappiano che hanno “sforato”
• Focalizzato: niente persone che si guardano in giro please! E’ mancanza di rispetto verso chi sta parlando
• Energico: deve essere un momento attivo, un momento in cui tutto il team è chiamato a partecipare
• Di supporto: le persone devono sentirsi ascoltate, un buon modo per creare questa sensazione è di occuparsi dei problemi che vengono sollevati durante il meeting. Ci tengo a sottolineare questo aspetto perchè è un primo passo verso la costruzione di un team, ovvero un gruppo di lavoro dove le responsabilità vengono condivise
• Auto organizzato: non ci deve essere un “centro”, la comunicazione deve essere uno a molti

L’implementazione di questo tipo di pratica è sicuramente più semplice in team piccoli (< 8 persone), ma nella mia esperienza personale ho visto questi antipattern

• Chi parla si riferisce sempre alla stessa persona, generalmente al “capo” (project leader, project manange, …). Cosa fare?
  • Assicurarsi che il gruppo formi un cerchio senza ostacoli nel mezzo (effetto tavola rotonda)
  • Sottolineare all’inizio del meeting gli obiettivi dello stesso e il modello di comunicazione (uno a molti) che meglio li supporta, utilizzate magari una breve frase che segni anche l’inizio del meeting
  • Eleggere un facilitatore che faccia seguire le “regole” del meeting facendo ruotare spesso questo ruolo all’interno del team. Aiuterà tutti a responsabilizzarsi e a far proprie queste “regole”
• Il giro delle persone che prendono la parola è sempre quello, inizia sempre il più “brillante” e termina sempre il più “timido”. Trovate un modo creativo e divertente per scegliere l’ordine degli interventi
  • Ognuno pesca una carta da un mazzo di carte, il prossimo è chi ha pescato la carta più alta e non ha ancora parlato
  • Stessa cosa ma con un dato multifaccia
  • Chi ha la parola decide chi sarà il prossimo lanciandogli il token (un pupazzo, un cappello, …)
• Il team utilizza il tempo del meeting per risolvere i problemi anzichè individuarli. E’ leggitimo chiarire un concetto se non lo è, ma la risoluzione dei problemi non deve essere affrontata durante il meeting, in quanto si rischia di togliere tempo alle altre persone (rispetto) e quindi si rischia di perdere la possibilità di individuare problemi magari più gravi o urgenti. A tutti gli effetti questa è un’interruzione di un’attività e come tale deve essere gestita
  • Uno dei partecipanti se ne accorge e richiama l’attenzione degli altri attraverso una frase di rito “Take Offline!”
  • A questo punto i partecipanti alla discussione (e gli eventuali interessati) allocano del tempo durante la giornata per proseguire
  • Quest’ultimo passo risulta fondamentale per instaurare quel clima di “supporto” di cui abbiamo parlato prima
• Il meeting si tiene alla macchinetta del caffè durante il tempo che il team solitamente dedicava alla colazione. Questa situazione è problematica in quanto priva di autorevolezza la pratica, non degna di ottenere del tempo dedicato, e indispone le persone perchè private di un momento dedicato a loro stessi e non al team. La soluzione è semplice, ricavate per questa pratica 15 minuti all’inizio della giornata lavorativa :-)
• Il meeting finisce senza che tutti abbiano una sensazione di “ordine”

Quest’ultimo antipattern vorrei approfondirlo in maniera particolare perchè l’ho incontrato frequentemente proprio nei team di ridotte dimensioni, sopratutto in quei team in cui vengono già utilizzate pratiche per promuovere quella che Cockburn chiama Osmotic Communication. Questo succede perchè gli obiettivi dello Stand-Up Meeting sostanzialmente vengono già raggiunti da un ambiente progettato per massimizzare la comunicazione fra i componenti del team. Ma allora il “disordine” da dove arriva? Il tipo di comunicazione “ambientale” è molto efficace, ma non si può certo definire organizzata, lo Stand-Up Meeting è un buon momento per “riordinare” queste informazioni e in parte questo obiettivo viene raggiunto, ma si può fare di più.

Quello che propongo è la creazione di un deliverable, un artefatto che catturi in maniera organizzata quello che sarà il piano di lavoro della giornata



Su una lavagnetta magnetica viene creata una griglia: una riga per ogni task che verrà lavorato, una colonna per ogni pomodoro (unità di misura corrispondente a 25 minuti di lavoro non interrompibile) disponibile nella giornata, ogni componente del team viene rappresentato da una calamita di colore diverso. Durante lo Stand-Up Meeting l’owner di un task ne stima la durata ed alloca il tempo necessario al completamento del task, scegliendo il suo pair in base alle persone disponibili. Terminato lo Stand-Up Metting il team dispone di un piano d’azione per tutta la giornata, in questo modo tutti i componenti del team hanno sia una visione globale del progetto che un piano concreto di lavoro

Inoltre

• Il piano giornaliero può essere facilmente aggiornato nel caso di (sovra|sotto)stime
• Il piano giornaliero è visibile a tutti, interni ed esterni al team, contribuendo alla comunicazione ambientale di cui parlavamo prima
• E’ una buona base di dati per lo Stand-Up Meeting del giorno successivo

P.S. L’idea di utilizzare le calamite di colore diverso per identificare diversi componenti del team è veramente carina e divertente, ma come al solito i team d’oltre oceano sono più avanti :-)