Ciò che ti manca è un backlog con priorità assoluta e limiti WIP appropriati (limiti di work in progress).
In primo luogo, supponendo che stiate iniziando a utilizzare 3 stati (Aperto / Backlog, In corso, Fatto), il team deve avere un modo per estrarre gli elementi dal backlog in base alle priorità stabilite dal proprietario del prodotto. Non importa se questi sono avanzi dal tempo pre-agile. Tutto deve essere prioritario rispetto a qualsiasi altra cosa, giusto? Quindi raggruppa il tuo arretrato, dando al team la possibilità di scegliere tra i primi del backlog. Inoltre, non importa se gli oggetti sono descrizioni di bug approssimativamente tratteggiate o storie completamente saltate, ciò che conta è che tu abbia una sorta di rappresentazione visiva dell'idea del proprietario del prodotto che il team può lavorare con esso. Passa a un modo più formale di definire questi desideri lungo il percorso (fino a quando alla fine ti ritroverai con solo bug e storie corrette). I bug sono un dato di fatto nello sviluppo del software, quindi considerali come storie quando si assegnano le priorità.
In secondo luogo, dire al team di presentare un numero massimo di elementi che vorrebbero avere in corso allo stesso tempo e lasciare che il team definisca questo come limite iniziale WIP. Questo valore può essere regolato nel tempo a seconda del modo in cui funziona per te.
Sembra anche che tu pensi di sapere meglio come il team dovrebbe organizzare il proprio lavoro (assegnare un nuovo sviluppatore ai bug, mantenere gli altri focalizzati). Ho visto questo tipo di comportamento prima e di solito è un segno di comportamento disfunzionale. La squadra dovrebbe sapere meglio come risolvono gli elementi sulla tavola Kanban, a condizione che agiscano e pensino come una squadra. In questo modo possono massimizzare il rendimento e utilizzare tutti al meglio delle sue capacità. Interferenze dall'esterno (microgestione e simili) possono danneggiare la squadra. Detto questo, ci sono sempre due lati della storia, poiché i team devono crescere e potrebbero aver bisogno di una guida adeguata per ottenere una certa qualità laddove le pratiche agili funzionano in modo efficace. Se hanno problemi a suddividere il lavoro, questo è qualcosa che può essere affrontato come parte di retrospettive / cicli di feedback che sono essenziali per migliorare cose come la distribuzione del lavoro, per esempio.
Ricorda che Kanban si basa sul fatto che il pull del team invece di spingere gli elementi nel team. Infine, in caso di fallimento dell'approccio di un unico grande team, tu e il tuo team potete sempre prendere in considerazione la suddivisione del team in diversi team più piccoli, ciascuno con propri processi e flussi di lavoro Kanban con schede individuali, adattati alle esigenze specifiche del team (ad esempio una squadra di bugfixing , team di funzionalità, team di tester). Alla fine, tu e il tuo team di sviluppo deve governare il processo, non il contrario .