Le Tre Opzioni Reali

Scrum funziona meglio quando il team rilascia funzionalità con una cadenza prevedibile. Sprint di due settimane impongono una conversazione di pianificazione ogni quattordici giorni, una demo che rende visibili i progressi e una retrospettiva che fa emergere gli attriti prima che si cristallizzino. Si ottengono ruoli definiti — un product owner che custodisce il backlog, uno scrum master che custodisce il processo e sviluppatori che custodiscono l'impegno.

La struttura è il punto. I team di prodotto che costruiscono verso obiettivi trimestrali hanno bisogno del ritmo di "abbiamo pianificato questi otto ticket, ne abbiamo completati sette, ecco perché." Gli stakeholder ottengono previsioni basate sulla velocity storica piuttosto che su ipotesi ottimistiche. Gli sviluppatori ottengono il permesso di dire "questo non è in questo sprint" senza una battaglia politica.

Il costo di Scrum è la rigidità. I cambiamenti di scope a metà sprint sono costosi. Le cerimonie richiedono tempo reale — un team di sei persone spenderà 4–6 ore per sprint nei rituali. Se il lavoro è guidato da interruzioni o le priorità cambiano quotidianamente, quella rigidità diventa zavorra anziché leva.

Kanban ottimizza il throughput in ambienti dove il lavoro non aspetta il confine dello sprint. Un ticket di supporto escalato alle 14:00 non si preoccupa che la pianificazione dello sprint sia solo giovedì. Kanban dice: visualizza il lavoro, limita quanto è in corso contemporaneamente e prendi il prossimo elemento con priorità più alta quando si libera capacità.

La board è il sistema. Le colonne rappresentano fasi (Da Fare, In Corso, Revisione, Fatto) e i limiti WIP limitano quanti ticket possono stare in una colonna simultaneamente. Un team di 3 persone con un limite WIP di 4 su "In Corso" non può iniziare nuovo lavoro finché qualcosa non avanza. Quel vincolo è ciò che rende Kanban più di una lista di attività — costringe il team a finire prima di iniziare.

Kanban si adatta ai team operativi, ai team di piattaforma e a qualsiasi gruppo il cui lavoro in arrivo è imprevedibile nei tempi ma relativamente uniforme nelle dimensioni. Funziona bene anche come trampolino — i team incerti su Scrum possono eseguire Kanban per un mese per costruire abitudini di flusso prima di aggiungere gli sprint.

Non ogni team ha bisogno di una metodologia adesso. Un team di 3 persone seduto nella stessa stanza, che rilascia un prodotto, con un backlog breve e conversazione quotidiana — quel team ha già cicli di feedback. Aggiungere cerimonie sprint o board Kanban sopra non crea valore; crea overhead fine a se stesso.

I fondamentali di questo corso — disciplina del controllo sorgente, ticket significativi, stima di base e una comprensione condivisa di cosa significa "fatto" — sono sufficienti per rilasciare bene per team dove il costo di coordinamento è basso. Il segnale che serve più struttura non è "abbiamo letto di Scrum e sembra professionale." È dolore concreto: passaggi di consegne mancati, sorprese croniche al momento della demo, lavoro che resta inattivo perché nessuno sapeva che era bloccato, o nuovi membri del team che non possono fare onboarding senza una settimana di affiancamento.

Se questi problemi non si verificano, resta qui. Rivedi questa decisione tra tre mesi o quando il team cresce oltre le cinque persone.