Gestire le Violazioni dei Limiti WIP

Quando viene raggiunto un limite WIP, hai tre opzioni:

1. Aspettare — Non iniziare nuovo lavoro; aiuta a completare qualcosa in corso
2. Convergere — Più persone aiutano a liberare il collo di bottiglia
3. Violare — Inizia nuovo lavoro comunque, riconoscendo l'eccezione

Tutte e tre sono valide a seconda del contesto. La chiave è che la violazione sia visibile e consapevole, non invisibile e inconsapevole.

Un limite violato è un segnale: "Sta succedendo qualcosa di insolito. Presta attenzione."

Passo 1: Riconoscere il segnale Il limite è raggiunto. Questo è il sistema che funziona, non che si rompe.

Passo 2: Chiedere perché

• C'è un blocco che impedisce al lavoro di finire?
• Una fase a valle è intasata?
• Abbiamo preso troppo lavoro?
• Qualcosa è inaspettatamente complesso?

Passo 3: Scegliere una risposta

• Aiutare a completare qualcosa: Revisionare una PR, fare pair su un bug, rimuovere un blocco
• Convergere sul collo di bottiglia: Più persone si concentrano sul liberare l'ingorgo
• Aspettare: Se il blocco è esterno, potrebbe non esserci nient'altro da fare che aspettare
• Escalare: Se il pattern persiste, sollevarlo nello standup o alla leadership

Passo 4: Non violare automaticamente La tentazione è dire "ma questo è importante!" e iniziare comunque. Resisti. I limiti esistono per proteggere il flusso.

A volte violare il limite è la scelta giusta. Esempi:

Emergenza reale: La produzione è down, e siamo al limite WIP per Dev. Sì, inizia comunque la correzione.

Dipendenza bloccante: L'elemento bloccato sta aspettando input esterno. Iniziare qualcos'altro è meglio che restare inattivi.

Apprendimento: Un nuovo membro del team ha bisogno di fare pair, e questo supera temporaneamente il limite.

Ma rendilo visibile:

• Usa un indicatore visivo (card di colore diverso, flag, ecc.)
• Discutine nello standup
• Traccia le violazioni nel tempo

Se violi frequentemente i limiti, qualcosa non va. O:

• I limiti sono troppo bassi
• Il lavoro arriva troppo velocemente
• I blocchi non vengono risolti
• Il team non crede nei limiti

Le violazioni sono dati. Tracciale per migliorare:

Cosa catturare:

• Quando è avvenuta la violazione?
• Perché il limite è stato raggiunto? (blocco, ondata a monte, ecc.)
• Perché abbiamo scelto di violare? (emergenza, non potevamo aiutare altrove, ecc.)
• Qual è stato l'impatto?

Pattern da cercare:

• Stessa colonna che raggiunge sempre i limiti → collo di bottiglia, affrontare la causa radice
• Limiti raggiunti dopo il rifornimento → prendere troppo nella pianificazione
• Violazioni sempre da una persona → possibile bisogno di formazione o supporto
• Violazioni sempre per un tipo di lavoro → forse quel tipo necessita di gestione diversa

Discussione in retro: "Abbiamo violato il limite WIP di Dev 4 volte questo sprint. Tre erano perché Code Review era intasato. Dobbiamo aumentare la capacità di Review?"

Questo trasforma le violazioni in opportunità di miglioramento invece che in sensi di colpa.