La presentazione "Kanban sucks" sosteneva che:

1) E' più facile fingere di fare Kanban che fingere di fare Scrum.

2) Il numero di regole in un processo è inversamente proporzionale alla disciplina richiesta per implementarlo.

A causa di (1), molti usano Kanban perché non hanno la disciplina richiesta da Scrum, che impone pratiche difficili come le iterazioni e le retrospettive. Ma a causa di (2), chi non ha la disciplina per Scrum a maggior ragione non l'avrà per Kanban, che ha meno regole. In pratica, la quasi totalità dei progetti che usano Kanban non applicano nè i principi Agili, nè le regole di Kanban. Di solito i limiti al WIP valgono fin quando il capo non si incazza o qualche task resta bloccato, l'ottimizzazione del flusso non la fa niuno, e il sistema è "push" anziché "pull". Di fatto vedo team che appendono una board al muro, incaricano qualcuno di aggiornarla e si illudono di essere agili. Kanban è l'ultima frontiera del cargo culting.

Quindi la mia tesi pacatamente argomentata è che Kanban fa schifo al cazzo, nello stesso senso in cui fa schifo al cazzo la dittatura del proletariato: è un buon sistema di idee in teoria, ma nel mondo reale offre talmente tante opportunità di abuso, consapevole o meno, da risultare disfunzionale e maligno. Nei termini della teoria dell'evoluzione, Kanban non è una strategia evolutivamente stabile (http://en.wikipedia.org/wiki/Evolutionarily_stable_strategy).

Sono certo che se applichi Kanban in modo coerente e disciplinato, funziona. Il fatto è che non vedo molti team che lo fanno. I team che raccolgono maggiori successi non applicano Kanban, ma il proprio metodo, che a volte include principi che capita siano stati popolarizzati da Kanban (rendi visibile ciò che fai, limita il WIP, eccetera). Il fatto che Kanban rifugga i dettagli aiuta a confondere le acque. Un caso eclatante è l'espressione "Kanban board": in base alla definizione comune, *qualsiasi* board che visualizzi lo stato dei task con delle colonne è una Kanban board. Di fatto, Kanban ha preso quello che già facevamo, ci ha messo un marchio e se lo è attribuito.

Kanban è anche un punto di arrivo nell'involuzione di Agile da sistema di pratiche (XP) a sistema di idee astratte. Come sa chiunque abbia implementato un diagramma UML, l'astrazione non risolve i problemi - li deferisce. Kanban è il momento in cui la comunità Agile/Lean raggiunge lo stesso livello di astrazione del management tradizionale: "se seguo queste tre regole, allora avrò successo, a prescindere da cosa sto producendo". Ora che abbiamo lo stesso livello di astrazione del management tradizionale, possiamo aspettarci la stessa percentuale di successo. Che culo.

Per rendersi conto di cosa sta succedendo basta osservare come noi consulenti Agili ci affanniamo a spiegare che Kanban/Scrum/eccetera non servono a fare software, ma a "organizzare il lavoro". Il cerchio si è chiuso: dopo aver detto per anni che scrivere software è un'attività con le proprie difficoltà specifiche, ora diciamo di avere un silver bullet che funziona per il software come per ogni altra attività, proprio come diceva il "management scientifico". Il motivo per argomentare queste puttanate è che così anche consulenti che non capiscono una straminchia di software possono vendere un metodo per fare software a manager che a loro volta non capiscono una straminchia di software. In effetti, Kanban non ha nessuna radice storica "comunitaria": è stato importato e adattato al software da un gruppo ristretto di persone allo scopo di venderlo in giro. Ha circa lo stesso valore filantropico di Scientology ("If you want to get rich, you start a religion." - L. Ron Hubbard).

Paolo "Nusco" Perrotta, Italy