Né cascata né sprint infiniti: il metodo a chiuse, per chi deve scegliere

Venerdì, 17:42. Stai chiudendo il portatile quando arriva la mail del Dott. Brambilla. Oggetto: TRASFORMAZIONE AGILE — URGENTE. Il testo è breve: «Ho visto un webinar. Dal prossimo trimestre diventiamo Agile. Lunedì alle 9 voglio la tua proposta. P.S. Il cliente nuovo vuole data di consegna, prezzo e funzionalità fissati nel contratto. Prepara anche il Gantt.»

Rileggi l'ultima riga tre volte. Agile, con il Gantt. Data, prezzo e funzionalità fissati, ma «diventiamo Agile». Sei il team lead di sette persone, e sei l'unica cosa che c'è tra quella mail e il loro prossimo trimestre.

Hai un weekend. Lunedì mattina, in sala riunioni, puoi presentare il solito Scrum da manuale, che Brambilla trasformerà in qualcos'altro nel giro di due settimane. Oppure puoi provare a capire cosa sta succedendo davvero, e proporre qualcosa che funzioni per il progetto e per le persone che ci lavorano. Scegli la seconda. Apri un file vuoto e cominci dai sintomi.

Quello che chiamano Agile

Non devi cercare lontano: li hai visti tutti, in questa azienda e in quella prima.

• Il daily da quindici minuti che ne dura quarantacinque. Ognuno, a turno, racconta al capo cosa ha fatto ieri. Non serve a sbloccare nessuno: è un rapporto di avanzamento in piedi.
• Lo sprint preso alla lettera. Due settimane di corsa, con il giovedì sera della seconda passato in ufficio. Poi si riparte subito, senza pausa. Uno sprint dopo l'altro, per sempre: nessun atleta lo farebbe.
• La velocity come KPI. Il management confronta i punti di team diversi e chiede che crescano del 20% a trimestre. I team, che non sono stupidi, gonfiano le stime. La velocity sale, il prodotto no.
• Gli story point convertiti in ore, così da poter fare il Gantt, che era quello che si voleva fare dall'inizio.
• «Agile» come sinonimo di «niente pianificazione». Le priorità cambiano ogni martedì, l'architettura non la decide nessuno, la documentazione è «il codice», e il debito tecnico non entra mai nello sprint.

Il risultato è un ibrido, sì, ma il peggiore possibile: tutta la rigidità del waterfall (data, prezzo e funzionalità fissi) con tutta l'ansia dell'Agile (cambi continui, scadenze ogni due settimane). Il nome tecnico, coniato da Ron Jeffries, uno dei firmatari del Manifesto Agile, è Dark Scrum. Martin Fowler, un altro firmatario, parla di Agile Industrial Complex: un'industria di certificazioni e consulenze che vende cerimonie a chi non ha mai letto il testo originale. Dave Thomas, un terzo firmatario, nel 2014 intitolò un post Agile is Dead (Long Live Agility). Jeffries, che probabilmente ha inventato gli story point, nel 2019 ha scritto: «Se li ho inventati io, adesso mi dispiace.»

Così fai la cosa che in azienda non ha fatto nessuno: vai a leggere il testo originale.

Due documenti che nessuno ha letto

Il Manifesto Agile è stato scritto a febbraio 2001 da diciassette sviluppatori, in una località sciistica dello Utah. Sono quattro valori e dodici principi, si leggono in cinque minuti. I valori dicono che si preferisce il software funzionante alla documentazione esaustiva, la collaborazione con il cliente alla negoziazione del contratto, la risposta al cambiamento al seguire un piano. E aggiungono una frase che tutti dimenticano: «pur riconoscendo il valore delle voci a destra». Il piano non è vietato. È meno importante del software che funziona.

Poi arrivi all'ottavo principio, e ti fermi:

«I processi agili promuovono uno sviluppo sostenibile. Sponsor, sviluppatori e utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.»

Indefinitamente. Il Manifesto non parla di sprint. Parla di un ritmo che puoi tenere per anni. Il giovedì sera in ufficio, ogni due settimane, è l'esatto contrario di quello che c'è scritto.

Il secondo documento è ancora più sorprendente. Il modello waterfall viene di solito attribuito a un articolo del 1970 di Winston Royce, Managing the Development of Large Software Systems. Lo apri e scopri che Royce disegna la famosa cascata (requisiti, analisi, progettazione, codice, test, esercizio) e subito sotto scrive che quel modo di procedere «è rischioso e invita al fallimento». Il resto dell'articolo propone correzioni: tornare indietro di una fase quando serve, coinvolgere il cliente, e soprattutto «farlo due volte», cioè costruire prima un prototipo da buttare per capire dove sono i problemi veri. La figura è diventata famosa, il testo no. Nel 1985 lo standard militare americano DOD-STD-2167 trasforma quella figura in una procedura obbligatoria per il software della difesa, e da lì si diffonde ovunque. Il waterfall puro, quello che tutti criticano, l'aveva già criticato il suo presunto inventore.

Sono le undici di sera, e ti rendi conto che la domanda «Agile o waterfall?» è sbagliata. Non devi scegliere una religione. Devi capire, per ogni decisione del progetto, quanto costa cambiare idea.

Quanto costa cambiare idea?

Sabato mattina, con il caffè, prendi l'elenco delle cose da fare per il cliente nuovo e le dividi con due domande. Quanto siamo sicuri di cosa serve? E quanto costerebbe cambiarla dopo?

• Incerta ed economica da cambiare: l'interfaccia, i testi, il flusso di registrazione, le funzioni di cui nessuno conosce il valore reale. Qui l'Agile vince senza discussioni: costruisci poco, mostra, correggi.
• Chiara e costosa da cambiare: il contratto con il gateway di pagamento, i requisiti GDPR, l'integrazione con il gestionale del cliente che ha una data di go-live fissa. Qui serve un piano, scritto e concordato. Cambiare idea a metà costa settimane.
• Incerta e costosa da cambiare: il modello dei dati, l'architettura, la scelta tra un database relazionale e uno a documenti. È la zona pericolosa. Qui serve il consiglio di Royce: un prototipo da buttare, costruito apposta per sbagliare in fretta, prima di prendere la decisione definitiva.
• Chiara ed economica: i bug, le piccole migliorie. Basta un flusso continuo, senza cerimonie.

Jeff Bezos, nella lettera agli azionisti di Amazon del 2015, distingueva tra decisioni «porta a senso unico» e «porta a doppio senso». Le prime vanno prese lentamente e con cura, le seconde in fretta, da chi ha le informazioni, perché si può sempre tornare indietro. Il problema delle aziende, scriveva, è che finiscono per trattare tutte le decisioni come porte a senso unico. Il problema del Dark Scrum è l'opposto: tratta tutto come una porta a doppio senso, anche lo schema del database con dieci anni di dati dentro.

Perché il tuo team è stanco: la matematica

Sabato pomeriggio guardi la pianificazione del trimestre che Brambilla ha preparato. Ogni persona è allocata al 100%, e lui ne è fiero: «Nessuna risorsa sprecata.» È qui che ti viene in mente un corso di ricerca operativa dell'università.

Un team che riceve lavoro si comporta come una coda: le richieste arrivano a intervalli irregolari, e ognuna richiede un tempo variabile. Nel modello più semplice, la coda M/M/1, il tempo medio di attesa prima che qualcuno inizi a lavorare su una richiesta, misurato in multipli del tempo di lavorazione, è ρ/(1−ρ), dove ρ è l'utilizzo. Prova a calcolarlo:

# coda M/M/1: attesa media in coda, in multipli del tempo di lavorazione
for rho in (0.5, 0.7, 0.8, 0.9, 0.95, 0.99):
    print(f"utilizzo {rho:4.0%}   attesa ≈ {rho / (1 - rho):5.1f}× il lavoro")

# utilizzo  50%   attesa ≈   1.0× il lavoro
# utilizzo  70%   attesa ≈   2.3× il lavoro
# utilizzo  80%   attesa ≈   4.0× il lavoro
# utilizzo  90%   attesa ≈   9.0× il lavoro
# utilizzo  95%   attesa ≈  19.0× il lavoro
# utilizzo  99%   attesa ≈  99.0× il lavoro

La curva non è lineare: esplode. Passare dall'80% al 95% di utilizzo non rende il team il 15% più produttivo. Moltiplica per quasi cinque i tempi di attesa. Ogni imprevisto (un bug in produzione, un collega malato, una richiesta urgente del cliente) non trova spazio, e si accoda a tutto il resto. La sensazione che hanno le persone, «siamo sempre in ritardo e non so perché», non è un problema di impegno. È matematica.

La seconda formula è ancora più semplice, la legge di Little: tempo medio di attraversamento = lavoro in corso / throughput. Se il tuo team chiude dieci attività a settimana e ne ha quaranta aperte, ciascuna ci mette in media quattro settimane. Se ne tieni aperte quindici, ce ne mette una e mezza, senza che nessuno lavori un minuto di più. Meno cose iniziate, più cose finite. E meno passaggi da un'attività all'altra, che sono la prima causa di stanchezza mentale per chi programma.

Ti appunti due numeri per lunedì: pianificare al massimo l'80% della capacità, e mettere un limite al lavoro in corso.

Il metodo a chiuse

Domenica pomeriggio vai a fare due passi sui Navigli. Sotto un ponte c'è una vecchia conca, una chiusa: due porte di legno che si chiudono a punta, una vasca in mezzo. Le barche non scendono a cascata, e non vanno nemmeno alla deriva seguendo la corrente. Navigano liberamente nel tratto tra una chiusa e l'altra, e ogni tanto attraversano una vasca dove il livello dell'acqua cambia in modo controllato, una volta sola, con le porte chiuse. Quella forma delle porte, dice il cartello, si deve a Leonardo da Vinci, che studiò le conche dei navigli di Milano. Gli storici sono più prudenti (Leonardo fu uno dei diversi ingegneri che le migliorarono), ma a Milano si chiamano ancora «porte vinciane».

Torni a casa e scrivi la proposta. La chiami così: metodo a chiuse. Sta in una pagina.

1. La chiusa iniziale (2–4 settimane). Prima di partire si prendono solo le decisioni a senso unico: architettura di base, modello dei dati, contratti con i sistemi esterni, vincoli normativi. Per quelle incerte si costruisce un prototipo da buttare, come suggeriva Royce. Ogni decisione si scrive in un Architecture Decision Record di una pagina: contesto, decisione, conseguenze. È il pezzo di waterfall che serve davvero, e dura settimane, non mesi.
2. Tratti navigabili di sei settimane. Tempo e budget sono fissi, il perimetro è variabile: si decide all'inizio quanto tempo vale un problema, non quanto tempo richiederà, e si consegna la versione migliore che sta in quel tempo. È l'idea dell'«appetito» di Shape Up, il metodo pubblicato da Basecamp nel 2019. Al cliente che vuole data, prezzo e funzionalità fissi rispondi con il triangolo di ferro: se ne possono fissare due su tre. Fissiamo data e prezzo, e decidiamo insieme, ogni sei settimane, cosa entra.
3. Due settimane di acqua ferma dopo ogni tratto. Niente funzionalità nuove: bug, debito tecnico, piccoli esperimenti, documentazione, formazione. E fiato. È la differenza tra una corsa a intervalli e uno sprint senza fine.
4. Dentro il tratto, flusso continuo. Una lavagna Kanban con un limite al lavoro in corso, niente sprint dentro lo sprint. Il daily dura quindici minuti e risponde a una sola domanda: chi è bloccato, e chi lo può aiutare? Gli aggiornamenti di stato si scrivono, in modo asincrono, e il capo li legge quando vuole.
5. Una demo ogni due settimane, con utenti veri. Questo è il cuore dell'Agile, e resta intatto: il ciclo di feedback breve che ti fa scoprire «non era quello che intendevo» dopo quindici giorni invece che dopo diciotto mesi.
6. Si misura il flusso, non le persone. Al posto della velocity, i quattro indicatori DORA: frequenza di rilascio, tempo da commit a produzione, percentuale di rilasci che causano problemi, tempo di ripristino. Sono misure del sistema, non dell'impegno, e non si confrontano tra team diversi.
7. Ritmo sostenibile, per contratto. Capacità pianificata all'80%. Gli straordinari si trattano come un incidente: se capitano, si fa una retrospettiva per capire perché, come si fa con un server che va giù. Il principio numero otto del Manifesto, finalmente preso sul serio.

Rileggi la pagina. Non c'è niente di nuovo, in realtà. C'è un pezzo di Royce, un pezzo del Manifesto, un pezzo di Kanban, un pezzo di Shape Up e un po' di teoria delle code. Ma messi insieme rispondono a tutte e due le richieste di Brambilla: il cliente ha una data, un prezzo e delle chiuse dove può decidere; il team ha un ritmo che può tenere per anni.

Lunedì, ore 9

In sala riunioni c'è il proiettore acceso e il caffè non è ancora finito. Presenti la pagina. Brambilla ascolta in silenzio, cosa che non era mai successa. Alla fine fa due domande.

La prima: «E il Gantt?» Gli mostri le chiuse: tre date, scritte in rosso, che corrispondono alle decisioni a senso unico e alle consegne contrattuali. Tra una chiusa e l'altra, niente barre colorate: un perimetro che si decide ogni sei settimane, guardando il software funzionante. Lui ci pensa un attimo, poi dice: «Al cliente piacerà. Le date ci sono.»

La seconda: «Due settimane senza funzionalità nuove? Non è uno spreco?» Gli mostri la tabella della coda M/M/1. «Al 99% di utilizzo», gli dici, «ogni richiesta urgente del cliente aspetta in media novantanove volte il tempo che serve a farla. Le due settimane di acqua ferma sono il motivo per cui le richieste urgenti avranno qualcuno libero per gestirle.»

Brambilla resta in silenzio per qualche secondo. Poi chiede di poter tenere la tabella, per mostrarla al consiglio di amministrazione. Lo prendi per un sì.

Fuori dalla sala, una delle sviluppatrici del tuo team ti chiede com'è andata. Le rispondi che da ottobre il giovedì sera si torna a casa. Lei ti guarda come se le avessi annunciato un aumento di stipendio. In un certo senso è così.

Muuu. 🐄