Come specificare i limiti WIP in Kanban?

No, nessuna formula. Non ce n'è uno.

Molto dipende dal modo in cui funziona la tua squadra, dalle pratiche che usi, ecc. Se abbini il programma, nella colonna di sviluppo avrai dei limiti inferiori rispetto a un certo numero di sviluppatori.

Se introduci Kanban nel team esistente, puoi provare a mappare tutto il lavoro attualmente in corso in MMF e quindi vedere quante funzioni hai in colonne diverse. Ti darebbe un'idea di quali limiti hai davvero al momento e questo è un buon punto di partenza per impostare i limiti Kanban.

Un altro consiglio che ottieni è il feeling istintivo della tua squadra. Fai ciò che senti è giusto. Quindi controlla se i tuoi limiti non sono troppo stretti o troppo larghi e regolati. Alcuni dicono "il consiglio di amministrazione ti dirà" e questo è fondamentalmente vero. Se colpisci il collo di bottiglia ogni settimana probabilmente hai limiti impostati troppo bassi. Se uno o due bloccanti non sono un problema i limiti sono troppo alti.

Ho scritto un post su come abbiamo impostato i nostri limiti quando stavamo creando la nostra scheda Kanban: link

Ho provato due estremi, entrambi suggeriti da persone diverse. Uno è quello di usare limiti alti e di modificarli fino a farli male, e l'altro è il contrario, per iniziare con n-1 dove n è il numero di persone che potrebbero tirare un'attività verso quella colonna. Quest'ultimo è più doloroso per le squadre nuove di kanban, ma ci ha aiutato ad arrivare a un punto di massimizzazione del flusso più veloce della prima opzione perché quando abbiamo sentito dolore (colli di bottiglia) il nostro primo istinto era quello di esaminare il problema alzando il limite del WIP come l'ultima risorsa e, di conseguenza, abbiamo scoperto e risolto diversi problemi di processo che altrimenti sarebbero stati altrimenti invisibili.

Mentre sono d'accordo non c'è una formula in quanto tale - allo stesso tempo c'è la possibilità reale di modellare il tuo processo Kanban. Ciò ti aiuterà a simulare i risultati probabili per cose come il tempo di ciclo, il tempo di attesa, l'efficienza, ecc.

Ho implementato un simulatore che modella il nostro processo Kanban. Simula il flusso di storie a tutto campo sotto i nostri limiti Kanban attorno ai limiti del WIP e alle risorse del team. Abbiamo uno stato che richiede la revisione dei clienti esterni. Tutti noi sospettavamo che questo stadio fosse qualcosa che uccide il nostro tempo di ciclo sostenendo le nostre storie.

La sensazione istintiva era quella di inscatolare questa fase ma non sapevamo se questo avrebbe semplicemente spinto il problema altrove. Né sapevamo fino a che punto andare con il pugilato del tempo né quanto grande sarebbe stato il miglioramento.

È tutto molto bello dire che continui a modificare, ma può essere molto dirompente. Le persone si abitueranno a un processo e si sentiranno frustrati con qualcuno che cerca costantemente di modificare l'intuizione. Quindi spesso devi fare un ottimo caso prima di implementare il cambiamento.

Quando modellisti puoi modificare senza interruzioni e avere una fiducia molto maggiore che i tuoi ritocchi porteranno al risultato che desideri. Inoltre andrà in qualche modo a ottenere la tua formula magica.

Vorrei iniziare con un numero di "slot" in ogni colonna che è uguale al numero di persone che avrebbero raccolto il lavoro nella colonna associata. Ciò rivelerà colli di bottiglia o punti dolenti. Indirizza il punto dolente finché non è sparito.

Sperimentare nel tempo con la riduzione del numero di slot in ogni colonna.

Uso due tecniche per specificare il limite WIP quando iniziamo un nuovo progetto o una squadra.

Nel caso di un progetto di sviluppo: stiamo lavorando in coppia (stiamo facendo XP), il che significa che due membri possono lavorare su un elemento alla volta. Se la squadra era composta da 6 persone, il WIP sarebbe 3, in base alla frase precedente. Comunque la programmazione delle coppie è un lavoro estenuante, ea volte i colleghi vorrebbero lavorare un po 'da soli, ne do uno più, quindi il limite WIP per 6 membri sarebbe 4.

Quando parliamo di manutenzione, test di verifica o progetto di supporto, poi controllo il lavoro parallelo che i vari colleghi possono fare, sommando questo numero e sottraendolo con uno. Ad esempio, tutti dal team menzionato in precedenza possono occuparsi di 2 problemi paralleli, il limite WIP sarebbe 12, ma con il -1, è 11. Il -1 mi assicura che il team rimane concentrato e lavora insieme. Se in questo caso il limite del WIP fosse 12, tutti lavorerebbero sul suo massimo di due carte e non si verificherebbe alcuna collaborazione.

Voglio entrare in empatia nel fatto che io uso queste tecniche solo all'inizio quando il progetto / team inizia. Successivamente, l'adeguamento del limite WIP è compito della squadra in base alle proprie emozioni, carico, obiettivo ecc.