Nel precedente post ho continuato la dissertazione sul massimizzare il flusso, ed ho spiegato come sia fondamentale estendere la Kanban Board a più stadi del processo possibili. Lo scopo finale è visualizzare tutti i passi che portano *dall’idea ai guadagno*. In un sistema software quindi dovremmo avere come ultima colonna un qualche cosa simile a: Usabile in produzione dal cliente finale.
La domanda principale è: Usabile dal cliente finale significa guadagno?
In parole povere, il fatto che una determinata feature/card sia in produzione, è condizione spesso necessaria, ma non assolutamente sufficiente affinché inizi a generare guadagno. In questo caso quindi, anche se abbiamo massimizzato il flusso grazie alla nostra Kanban Board, non ci stiamo necessariamente avvicinando al Goal. Quello che viene spesso trascurato nell’implementazione del metodo Kanban è il considerare la metrica probabilmente più importante dei processi agili: IL FEEDBACK!!!!
L’aspetto interessante è che, si è tentato per anni di mutuare tecniche di progettazione da altre branche dell’ingegneria all’informatica (vedi il waterfall) ed il successivo fallimento di molti di questi tentativi ha generato un assioma di questo tipo:
Essendo il sistema waterfall mutuato da un altra branca dell’ingegneria, è possibile che mal si adatti all’informatica. Ergo è piuttosto inutile cercare di adattare metodologie di progetto da altre branche dell’ingegneria, perché l’informatica è troppo differente.
Questa affermazione è sempre vera? Venendo da studi di Elettronica, per me è naturale che un sistema di controllo per essere stabile debba necessariamente usare il principio del feedback.
Ora consideriamo che: il metodo Kanban è un sistema di controllo, il cui scopo è monitorare l’avanzamento dall’idea al prodotto finito grazie alla Board. A questo punto io sono fermamente convinto che:
Uno degli errori maggiori in Kanban applicato ad un progetto software è credere che il flusso finisca una volta raggiunta l’ultima colonna, ignorando per questo il feedback!!!!
Se grazie a Kanban abbiamo aumentato di molto il flusso di produzione (software o manifatturiero, …), ma nel contempo abbiamo una qualità scadente, siamo ben lontani dal Goal, a meno che il Goal non sia avere orde di clienti insoddisfatti (o di vendere contratti di assistenza).
In questo particolare caso l’ingegneria dei controlli e dell’automazione ci viene in aiuto, perché il modo migliore per capire se il prodotto del nostro processo è valido e di qualità, è acquisire FEEDBACK!.
Nei prossimi post vedremo quindi che tipologia di feedback utilizzare e come integrare questo processo in Kanban.
Gian Maria.