Un Framework per le Decisioni

I team che possono descrivere il lavoro della prossima settimana oggi sono candidati per Scrum. I team che non possono descrivere il lavoro di domani oggi sono candidati per Kanban.

Valutati su una scala da 1 a 5: 1 significa "abbiamo una roadmap prioritizzata e la maggior parte degli sprint va più o meno secondo i piani." 5 significa "metà del nostro lavoro arriva non pianificato — incidenti, escalation dei clienti, richieste ad-hoc da altri team." La maggior parte dei team di funzionalità prodotto si colloca a 1–2. La maggior parte dei team di piattaforma, DevOps e supporto si colloca a 4–5. I team a 3 sono genuinamente ambigui — e "Scrumban" (cadenza Scrum con pull in stile Kanban per il lavoro non pianificato) è una risposta ragionevole per loro.

L'intuizione chiave: la prevedibilità non riguarda la disciplina. Un team può essere estremamente disciplinato e avere comunque un lavoro imprevedibile perché il dominio lo richiede. Non confondere "non possiamo prevedere" con "non pianifichiamo."

Lo sprint di Scrum è un impegno time-box: il team accetta di proteggere un periodo fisso dai cambiamenti di scope. Questo funziona solo se l'organizzazione rispetterà effettivamente il confine.

Fai due domande: Il tuo product owner può dire "no, quello aspetta fino al prossimo sprint" a un VP senza essere scavalcato? E il team può realisticamente partecipare a planning, standup, review e retro ogni ciclo senza che queste cerimonie vengano cancellate per "qualcosa di più urgente"? Se entrambe le risposte sono sì, puoi sostenere la cadenza di Scrum. Se una delle due è no, gli sprint collasseranno in un flusso continuo con riunioni extra — il peggio di entrambi i mondi.

Kanban non richiede impegno di cadenza. Puoi comunque tenere retrospettive e sessioni di pianificazione regolari, ma nulla si rompe se ne salti una o la sposti di qualche giorno. Per i team in organizzazioni che abitualmente scavalcano i piani, la mancanza di un confine di sprint in Kanban è onestà, non sciatteria.

La struttura è un'impalcatura — compensa ciò che il team non ha ancora costruito come memoria muscolare. Un team di sei ingegneri che hanno lavorato insieme per due anni potrebbe non aver bisogno di una definizione formale di "ready" perché l'hanno interiorizzata. Un team formatosi il mese scorso sì.

Segnali concreti che indicano più struttura (Scrum):

• Più di due ingegneri si sono uniti nell'ultimo trimestre
• Il team non ha una storia condivisa di cosa significhi "done"
• Il lavoro viene regolarmente avviato senza criteri di accettazione chiari
• Le retrospettive rivelano ripetute incomprensioni

Segnali che indicano meno struttura (Kanban o solo fondamentali):

• Il team ha membri stabili e contesto condiviso
• Gli ingegneri si auto-organizzano efficacemente senza assegnazioni di ruolo
• Gli elementi di lavoro sono ben compresi e relativamente uniformi
• Il problema principale di coordinamento è il throughput, non l'allineamento

I nuovi team traggono quasi sempre beneficio dall'iniziare con più struttura e allentarla man mano che si costruisce la fiducia. Il contrario — aggiungere struttura a un team che sta già lottando — sembra punitivo e genera risentimento.

Scrum è un framework tutto-o-niente per design. Non puoi eseguire "mezzo sprint" — o ti impegni nel time-box e nelle cerimonie, o non hai Scrum. Adottarlo significa cambiare come il team pianifica, rivede e riflette in un'unica mossa. È una transizione big-bang, e funziona meglio quando il team è coinvolto e uno scrum master (o equivalente) è pronto a fare coaching durante i primi sprint difficili.

Kanban è incrementale per natura. Inizi visualizzando il tuo flusso di lavoro attuale su una board — non è ancora richiesto alcun cambiamento di processo. Poi aggiungi limiti WIP. Poi inizi a misurare il cycle time. Ogni passo aggiunge valore indipendentemente. Se un passo non funziona, lo rimuovi senza disfare tutto il resto.

Per i team scettici sui cambiamenti di processo o scottati da precedenti adozioni di metodologie, il percorso incrementale di Kanban è a rischio più basso. Dimostri il valore a ogni passo prima di impegnarti ulteriormente. L'approccio big-bang di Scrum è più veloce per l'adozione completa ma ha un tasso di fallimento più alto nei team che non sono pronti per l'impegno.

La metodologia sbagliata è recuperabile — ma il costo di recupero varia. Un team che prova Scrum per due sprint e decide che non va bene ha perso un mese di adattamento e un po' di buona volontà. Un team che si riorganizza attorno a SAFe e acquista strumenti enterprise ha un percorso di inversione molto più difficile.

Valuta onestamente il tuo costo di cambio: Quante persone devono cambiare le loro abitudini quotidiane? Stai acquistando strumenti o facendo cambiamenti all'organigramma per supportare la metodologia? Gli stakeholder esterni vengono riaddestrati su come interagire con il team? Più punti di contatto ci sono, più alto è il costo di sbagliare — e più forte è l'argomento per iniziare con l'opzione più semplice.

Per la maggior parte dei team che fanno la loro prima scelta di metodologia, la risposta è: inizia con Kanban (basso impegno, facile da invertire) o Scrum (impegno moderato, reversibile in uno sprint). Non iniziare con un framework di scaling. Non iniziare con qualcosa che richiede coordinamento cross-team che non hai ancora. Abbina il peso della metodologia al peso della decisione.