Le Sei Pratiche Fondamentali

Tutto inizia con la visibilità. Se non puoi vederlo, non puoi gestirlo.

Una board Kanban rende visibile il lavoro—cosa è in corso, cosa è in attesa, cosa è bloccato. Ma la visualizzazione va oltre la board:

• Visualizzare gli elementi di lavoro: Card che rappresentano il lavoro effettivo
• Visualizzare il flusso di lavoro: Colonne che mostrano le fasi attraverso cui passa il lavoro
• Visualizzare le policy: Regole esplicite su come si muove il lavoro
• Visualizzare i blocchi: Indicatori visivi quando il lavoro è bloccato
• Visualizzare la capacità: Quanto lavoro può gestire ogni fase

Approfondiremo questo aspetto nel Modulo 2.

Questa è la pratica più controintuitiva, e la più potente. Facendo meno cose contemporaneamente, ne completi di più complessivamente.

I limiti WIP sono vincoli su quanti elementi possono trovarsi in una determinata fase (o nell'intero sistema) contemporaneamente. Quando si raggiunge un limite, non puoi iniziare nuovo lavoro—devi prima aiutare a completare qualcosa.

Questo crea flusso, riduce il cambio di contesto e fa emergere i colli di bottiglia. Il Modulo 3 copre questo aspetto in profondità.

Con il lavoro visualizzato e il WIP limitato, ora puoi gestire come il lavoro fluisce attraverso il sistema.

Gestire il flusso significa:

• Misurare lead time e cycle time
• Identificare e affrontare i colli di bottiglia
• Uniformare le dimensioni dei batch
• Ridurre i tempi di attesa

L'obiettivo è una consegna prevedibile e sostenibile—non sprint eroici. Il Modulo 4 copre le metriche di flusso.

Le regole implicite creano confusione e conflitto. Le policy esplicite creano chiarezza.

Ogni colonna sulla tua board dovrebbe avere policy chiare:

• Cosa significa "fatto" per questa fase?
• Chi può portare lavoro in questa fase?
• Cosa succede quando qualcuno è bloccato?
• Come vengono gestite le priorità in caso di conflitto?

Le policy non devono essere complesse. "La code review richiede due approvazioni" è una policy. "Gli elementi bloccati ricevono una bandiera rossa e vengono discussi nello standup" è una policy.

Kanban definisce sette cadenze—riunioni regolari per diversi scopi di feedback. A differenza degli eventi prescritti di Scrum, queste sono raccomandazioni che adotti in base alle necessità.

Le cadenze chiave includono:

• Standup giornalieri (focus sul flusso, non report di stato)
• Riunioni di rifornimento (prioritizzazione del nuovo lavoro)
• Pianificazione della consegna (quando e cosa rilasciare)
• Revisioni della service delivery (come stiamo andando complessivamente?)

Il Modulo 5 copre questi aspetti in dettaglio.

Questo si ricollega al cambiamento evolutivo. Il miglioramento non è un evento una tantum—è continuo e sperimentale.

Usa il metodo scientifico:

1. Osserva il sistema (metriche di flusso, blocchi)
2. Formula un'ipotesi ("Ridurre il limite WIP nella code review accelererà la consegna")
3. Sperimenta (provalo per due settimane)
4. Misura i risultati
5. Adatta (mantieni, modifica o ripristina il cambiamento)

Gli esperimenti falliti non sono fallimenti—sono apprendimento. L'unico fallimento è non sperimentare affatto.