I Kanban sono Agili?

12 September, 2010 (17:10) | agile, lean

Leggendo un commento di Piergiorgio e un post di Tony entrambi riferiti al mio ultimo post, ho capito che probabilmente non mi sono spiegato bene sulla faccenda del “poco Agile”, termine che suona molto vicino all’offesa :-)

Parto quotanto la parte incriminata

Per ogni fase ci possono essere un numero limitato di user stories, in questo modo si possono facilmente identificare eventuali stalli, fasi problematiche, sprechi di vario genere ecc…, peccato che tutto questo sia molto lontano dall’essere Agile… perchè? Semplice il limite è imposto sulle fasi, si presuppone quindi che ogni fase sia un sottosistema dimensionabile a piacere per equilibrare il flusso delle user stories fino al loro completamento, una fabbrica insomma, alla fine siamo tornati al waterfall (il cravattato ci prova sempre, non c’è niente da fare)

Molto più Agile e sensato sarebbe limitare la capacità produttiva del team sulle dimensioni del team stesso, banalmente una user story per sviluppatore, al limite per coppia di sviluppatori. Ad ogni sviluppatore assegnamo una calamita, le user story appese alla lavagna sono in lavorazione, una user story può essere appesa usando solo una di quelle calamite, una calamita può essere usata solo con una user story alla volta ed il gioco è fatto. Le fasi possono essere ancora conservate, possono essere utili per stanare certi problemi, ma l’enfasi dovrebbe essere sugli sviluppatori e non sulle fasi (“Individuals and interactions over processes and tools” vi ricorda qualcosa?)

Premettendo che ognuno può fare quello che vuole (ammesso che ne paghi direttamente le conseguenze), sarebbe meglio che lo facesse sapendo quello che sta facendo e perchè lo fa. Quello che ho notato è che chi ha adottato le Kanban Board lo ha fatto senza porsi delle domande fondamentali: qual’è l’oggetto della limitazione? Qual’è la misura del miglioramento? Come misuro la capacità produttiva del mio sistema? Ecc…

Ok lo ammetto, è una mia supposizione il fatto che la maggior parte non si ponga queste domande. Questa supposizione derivata dal fatto che mi sembra applicata troppo “by the book”, dove il “book” non riguarda affatto la produzione del software ma una catena produttiva manifatturiera.

Le Kanban Board nel mondo del software generalmente sono divise per fasi e la limitazione è applicata appunto su queste fasi, perchè? Partendo dal presupposto che lo scopo è quello di stabilizzare e velocizzare il flusso delle user story nelle varie fasi, stiamo dicendo che è possibile “dimensionare” ogni fase a piacere? Quindi, per esempio, chi sviluppa non fa deploy di quello che ha sviluppato? Evidentemente, altrimenti non si spiega perchè la fase dello sviluppo è dimensionato a 5 user story e il deployment a 1

Sempre a proposito delle fasi, negli impianti manifatturieri il fatto che ogni fase sia limitata è una coseguenza banale del fatto che le linee produttive sono per loro natura limitate, ma vale la stessa cosa nel software? Nel nostro team siamo in 5, non possiamo essere nella fase di test tutti e 5? O non possiamo fare deploy tutti e 5? Perchè? A meno che non ci siano 3 analisti che si occupano della fase di analisi, 5 sviluppatori che si occupano della fase di sviluppo, 2 persone che si occupano dei test, ecc… Allora sarebbe un’altra storia, ma trattare il team a dipartimenti specializzati e ridimensionabili a piacere è quello che vogliamo? Personalmente mi fa venire la nausea, ma basta esserne consapevoli

Domanda ancora più importante: il total flow in questo caso come lo si immagina? O meglio, qualcuno misura il Lead Time? Domanda lecita visto che non ne sento molto parlare, almeno non tanto quanto sento parlare di Kanban Board, e visto che la riduzione del Lead Time dovrebbe essere l’obiettivo finale…

Insomma, non vorrei che il seguire una moda possa fare più male che bene, sopratutto quando non ci si prende la briga di studiarla, di comprenderne il funzionamento e sopratutto senza domandarsi come misurare il miglioramento secondo i propri obiettivi. In particolare l’applicazione classica per fasi mi sembra pericolosa da questo punto di vista e suggerivo un’alternativa che mi sembrava meno rischiosa. Dato che l’approccio è di tipo sistemico, una volta messa in campo una Kanban Board “storta” si corre il rischio di stortare tutto :-)

Comments

Comment from Luca Minudel
Date: September 12, 2010, 6:43 pm

trovo queste riflessioni e quelle dell’altro post utili.

ho praticato judo per diversi anni e uno esercizio degli esercizi consisteva nel provare una tecnica ripetutamente e in velocitá.
questo ci obbligava a migliorare: eliminando i molti movimenti inutili e migliorando e velociaando quelli utili.
un lavoro di semplificazione ch richiede una maggiore maestria e una migliore tecnica.

kanban é simile nei confronti di scrum: meno regole prescritte, 3 invece di 9 !!!
quando gia con scrum si ha una code-base che fa piangere, un team che non é auto-organizzante, un cliente che é scontento, prima di lanciarsi su kanban (dimenticandosi del lead time e con sistematici sfondamenti dei limiti sul WIP) che richiede ancora piu maestria sarebbe meglio riflettere e provare a far funzionare scrum che é relativamente piu semplice

Comment from Tonino
Date: September 13, 2010, 3:29 pm

Giusto per dire che il mio post non conteneva nessuna critica, ma spostava il focus dal tool alle persone. Ciao.

Comment from Alberto Brandolini
Date: March 7, 2011, 10:44 pm

Quando dici “by the book” dipende anche molto dal book :-)

Kniberg e Skarin fanno un ottimo lavoro nel sintetizzare le basi di Kanban in un bignamino. Ma è un bignamino, se usiamo solo la board, senza capire cosa ci sta dietro (ad esempio che la board è la proiezione del value stream, che il Wip Limit è un modo per forzare un funzionamento PULL del sistema) si va abbastanza poco avanti.

Nel libro di David J Anderson c’è un intero capitolo dedicato al fatto che “Se non riesci a rilasciare roba di qualità, lascia perdere il flusso” I bug sono rework, e se non sei in grado di rilasciare roba buona al primo colpo (facendo TDD, Continuous Integration etc.) non ha senso proseguire nella lettura del libro. Non so quanto sia chiaro a chi sperimenta Kanban… ma lo dice!!

Comment from Gabriele Lana
Date: March 8, 2011, 7:32 am

@brando Con “by the book” non mi riferisco ad un libro in particolare, ma mi riferisco all’applicazione di un concetto senza averlo approfondito, rischiando di mettere in campo una soluzione “standard” in un ambiente che non lo è :-) È sempre la solita storia, il cargo cult non funziona, anche se lo strumento sembra estremamente semplice il mio invito è quello di approfondire (che di roba ce n’è)

Comment from Gaetano Mazzanti
Date: March 8, 2011, 1:45 pm

Ciao Gabriele,

ti segnalo questo intervento http://agileandbeyond.blogspot.com/2011/03/in-difesa-di-kanban.html (il primo del mio nuovo blog) in cui cito questo tuo post e il precedente sempre su kanban.

Ho provato a discutere (approfondire come dici tu), spero in modo corretto (nel senso di onesto e aperto), alcuni dei punti qui sostenuti e discussi.

Ho visto il video di una tua lunga presentazione sul Lean, più recente rispetto a questi post.
Ecco, credo che kanban (come descritto da Anderson) fornisca una buona sintesi dei principi Lean & Agile.

Poi è chiaro che se non hai basi solide, buone e giuste (unit tests/TDD, continuous integration, ecc.) non funziona nè kanban, nè Scrum, nè nulla.

Write a comment