Introduzione

In questo articolo vorremmo condividere alcune tecniche e svariati suggerimenti frutto dell’esperienza diretta sul campo: tanto per fornire degli esempi, come si decide di condividere gli allineamenti o come si gestiscono le retrospettive.

Molte delle idee presenti in questo articolo sono il frutto di sperimentazioni e tentativi “sul campo” e, pertanto, non è detto che siano adatte a tutti i casi. Se, di fatto, è impossibile trovare “la soluzione” valida per tutte le situazioni operando in un mondo complesso, può comunque essere il caso di condividere quanto raccolto, con la consapevolezza che in alcuni casi potrebbe essere applicabile, in altri no.

Quando si mettono “le cose” nella kanban?

Una delle questioni più importanti nel processo di gestione di una Kanban board è il processo di alimentazione della stessa. In tal senso può essere utile considerare la lavagna come un sistema di “condotte” nei cui “tubi” le attività scorrono seguendo un flusso che in genere è diviso in due fasi:

• una prima fase di raccolta, alimentazione e relativa selezione di nuove attività;
• una seconda fase di effettiva lavorazione.

Commitment point

Il punto che separa queste due fasi viene in genere definito commitment point dato che rappresenta il passaggio dalla fase in cui le attività sono delle opzioni a quella in cui il team si impegna realmente a svolgerle (committed work).

Le attività che sono in fase di valutazione, alla sinistra del commitment point, sono delle opzioni che potrebbero non passare la selezione. David J. Anderson, autore di una pubblicazione su Kanban [1], descrive questa parte utilizzando la metafora di un concorso di bellezza, dove le storie fanno a gara per essere scelte: solo quando un item supera il commitment point prende importanza; prima di allora, è semplicemente una opzione.

Una volta messa in lavorazione, un’attività non dovrebbe mai essere abbandonata se non in casi eccezionali: per questo motivo si sceglie la parola commitment, che indica il “prendersi seriamente un impegno”. Dal punto di vista del cliente, la presa in carico di una attività che passa il commitment point rappresenta una promessa, più o meno esplicita, che tale attività verrà portata a completamento, prima o poi.

Up Stream e Down Stream

Il processo di selezione (prima) e di implementazione (poi) può essere considerato come un unico flusso di lavorazione (“work flowing like a stream”) che scorre da sinistra verso destra; per questo la zona a sinistra del commitment point viene chiamata Up Stream (il corso iniziale del flusso), mentre quella alla destra è detta Down Stream (la porzione finale del flusso).

Il lead time, di cui abbiamo già parlato in passato e di cui parleremo ancora, non dovrebbe tener conto del tempo in cui le attività sono in Up Stream: in questa fase, il tempo di attesa non dipende dal processo.

Per valutare e selezionare le attività presenti in Up Stream, si può ricorrere alle tecniche tipiche utilizzate in Product Management o Risk Management. La figura 1 spiega in modo piuttosto chiaro questo schema.

Spesso il commitment point è la prima colonna della board su cui si impone un WIP limit piuttosto basso; a volte si impone un WIP limit anche in Up Stream per evitare ingolfamenti: inutile prendere in esame nuove idee se il gruppo di lavoro non è in grado di valutare nemmeno quelle già presenti in Up Stream.

Queue replenishment

Al commitment point, avviene il cosiddetto queue replenishment, vale a dire Il rifornimento della coda: quando ci sono caselle vuote nella prima colonna bisogna scegliere quali storie meritano di essere tirate (pull) dentro il sistema. Il queue replenishment può avvenire just-in-time, cioè ogni volta che c’è uno slot vuoto, o essere cadenzato, qualora le persone necessarie per la valutazione/selezione non siano disponibili in modo continuativo e costante.

Il vantaggio della suddivisione in Up Stream e Down Stream

La separazione del processo in queste due fasi offre un interessante strumento di sense-making: il modo con cui le attività sono gestite cambia radicalmente se ci si trova a destra o a sinistra del commitment point.

Per esempio il tipo e il significato delle metriche cambia molto a seconda che si consideri l’Up Stream (cono delle opzioni) o il Down Stream (impegno a prendere in carico e completare il lavoro). Durante la fase di lavorazione, il lead time assume un significato più concreto e realistico, essendo eliminata ogni indecisione sul “lavorare o non lavorare” un determinato item; questo aiuta a formulare in modo più realistico ipotesi sulle tempistiche di termine dei lavori e di rilascio. In Up Stream, invece, si usano metriche differenti come la lunghezza delle code, il tempo di attesa in determinate sottofasi o addirittura il coefficiente di cancellazione degli item.

Quando si fanno gli standup?

Una delle colonne portanti di Kanban è certamente il modello dei feedback loops, dei quali lo stesso Anderson ha sottolineato l’importanza:

“Recently, I’ve taken a new approach to teaching The Kanban Method. The new Lean Kanban ‘Practicing the Kanban Method’ class is built around the 7 Kanban Cadences – the cyclical meetings that drive evolutionary change and ‘fit for purpose’ service delivery.” [1]

Anderson sottolinea che per implementare i vari feedback loops, non necessariamente si deve dar vita a 7 nuovi meeting, ma anzi si potranno interpretare in modo nuovo quelli già esistenti.

Feedback loops e daily standup

Fra i vari meeting possibili, certamente il daily standup preso in prestito da Scrum è uno dei più importanti dai quali si può trarre maggiori benefici proprio nell’ottica di creare dei feedback.

Il formato tipico di uno Scrum daily standup meeting prevede che ogni persona elenchi tre elementi fondamentali:

• cosa è stato fatto il giorno prima;
• quali impedimenti si sono incontrati il giorno precedente;
• cosa ci si appresta a fare il giorno stesso.

Questo approccio ricalca la filosofia tipica di Scrum, in cui ci si orienta fortemente all’analisi delle cose da fare: è un approccio task-oriented all’interno dello sprint. In Kanban invece tipicamente l’attenzione è rivolta verso la massimizzazione del flusso ed è per questo motivo che può essere utile modificare tale meeting in modo da privilegiare una analisi flow-oriented.

Dal task-oriented al flow-oriented

Un modo per ottenere questo risultato è quello di abbandonare il classico schema delle tre domande, per passare a una valutazione dei cartellini presenti sulla lavagna da destra a sinistra secondo quello che a volte viene detto stile walk the board (“camminare attraverso la lavagna”) in modo da implementare un approccio pull.

In questo caso, si segue lo schema riportato qui di seguito:

• Per prima cosa si analizzano gli eventuali elementi bloccati, cercando di individuare la causa che ne impedisce il completamento. Questi sono senza dubbio i problemi più importanti da risolvere prima possibile, per cui ha senso che vi si dedichi la maggior parte del tempo a disposizione.
• Secondariamente, conviene concentrare l’attenzione sulle attività presenti sulla expedite lane o più in generale sugli emergency items se presenti. È prioritario per il team velocizzare la lavorazione di tali attività, vale a dire risolvere il problema corrispondente, anche a costo di togliere tempo prezioso alla lavorazione di altre attività. In questo caso è utile marcare il cartellino corrispondente all’attività in analisi, per esempio utilizzando un simbolo visibile e comunicativo: un pallino rosso o un altro simbolo di allarme.
• A questo punto si può passare ad analizzare quelle attività che non si sono mosse dall’ultimo standup. Anche se probabilmente è ancora presto per considerarle bloccate, è probabile che siano a rischio. A volte, per il breve tempo intercorso dallo stand up precedente, può essere plausibile che non si siano spostate nella board: in tal caso la discussione non dovrebbe richiedere molto tempo. Qualora invece si dovesse sentire puzza di bruciato, potrà essere utile indagare un po’ meglio per capire se si tratta di una situazione normale o se si prefigura un blocco.
• Infine si può passare ad analizzare gli altri elementi rimanenti: in questo caso, se i cartellini sono ancora molti, si può seguire la priorità delle classi di servizio delle attività, partendo da quelle a priorità maggiore (bugs, critical features, altro); aiuta in questi casi la classificazione delle attività per classi di servizio su cui dovrebbe essere definita una priorità.

Durante questo processo di valutazione possono aiutare per decidere il piano di lavoro quotidiano alcuni dati e certe metriche, come l’età di cartellino (“Da quanto tempo è in lavorazione questa attività?”) o l’effort medio richiesto (“Quanto impiegano solitamente attività di questo tipo per essere completate?”).

Vantaggi del daily standup meeting in stile walk the board

Seguire la priorità delle attività — si parte dalle attività bloccate per arrivare a quelle delle classi di servizio meno prioritarie — rende il processo di analisi più efficace, perché si agevola la consegna di attività terminate, velocizzando il rilascio di valore all’utente finale. Ma è anche efficiente: se il tempo del meeting termina prima di essere riusciti ad analizzare tutti i cartellini, saranno state trascurate solamente le attività a priorità più bassa, non bloccate, che in definitiva non danno preoccupazioni e che non richiedono quindi particolari discussioni almeno per ora.

Inoltre, questo stile di conduzione del daily standup ha l’effetto di migliorare la collaborazione: alla domanda “Cosa dobbiamo fare oggi per spostare verso destra i cartellini?” in genere si ottiene un coinvolgimento e una partecipazione maggiore da parte di tutte le persone.

Per concludere è importante notare che il daily standup non è altro che uno strumento, per cui può valere la pena di sperimentare o comunque di fare modifiche: si possono sfruttare quei 10 minuti per fare qualcosa di diverso. Per esempio in Buffer [3] utilizzano lo standup non solo per misurare i miglioramenti del processo di lavorazione, ma anche per analizzare eventuali miglioramenti personali dei membri del team, sia per quello che concerne le conoscenze tecniche che interpersonali.

Flow manager, flow management

Nel paragrafo precedente si è visto come il cambio di approccio nello standup permette di spostare il focus dal fare la contabilità dei task da svolgere, per tenere occupate le persone del team, al miglioramento del flusso di lavorazione; a tal proposito risulta interessante l’introduzione del Flow Manager, un nuova figura che alcuni team stanno iniziando ad adottare, riuscendo a verificarne i benefici.

Il Flow Manager concentra il suo operato su tutte quelle iniziative volte a velocizzare lo scorrimento dei cartellini sulla board e fra queste rientra anche il guidare un daily standup come appena visto, in stile walk the board.

È un coach, per cui stimola la discussione all’interno del team, porta all’attenzione delle persone il rispetto o meno delle regole che il team si è date, prima fra tutte il rispetto dei WIP limit. Guida la valutazione delle eccezioni stimolando la creazione di idee innovative.

Il Flow Manager può essere visto come uno Scrum Master, con cui ci sono moltissime similitudini, il cui focus è principalmente sulla velocizzazione del flusso e meno sugli aspetti legati alla gestione del progetto [4].

Quando e come si fa la retrospettiva?

La retrospettiva rappresenta un altro dei feedback loop fondamentali: visto che il cuore di Kanban è il miglioramento continuo, fare regolarmente delle retrospettive è lo strumento indispensabile per abilitare questo miglioramento.

Retrospettive: differenze tra Scrum e Kanban

Rispetto a Scrum, in Kanban non vi è il concetto di iterazione che in qualche modo detta il ritmo per l’organizzazione del lavoro, collocando la retrospettiva al termine dell’iterazione. Per questo motivo, in Kanban anche la frequenza con cui effettuare le retrospettive è decisa dal team: può essere ogni due settimane, una volta al mese oppure quando si pensa che sia necessario. Spesso nei team molto maturi c’è la tendenza a non seguire una cadenza regolare, organizzando invece una retrospettiva non appena si presenta un problema.

Dal punto di vista degli strumenti utilizzabili si può far riferimento alle classiche tecniche di Agile Retrospective, utilizzate comunemente dai team agili [2]. A causa della popolarità di Scrum, dove la retrospettiva gioca un ruolo fondamentale, la maggior parte delle tecniche e dei formati utilizzati sono quelli adottati dai team che utilizzano Scrum come metodologia di lavoro.

Ciò nonostante, alcuni autori ritengono che passare a Kanban richieda almeno di provare a capire se sia utile cambiare il formato e le tecniche utilizzate per fare le retrospettive.

Stop the Line Retrospective

Un primo interessante esperimento che alcuni team hanno provato a effettuare prende spunto dal lavoro fatto da Taiichi Ohno in Toyota, introducendo il concetto di Stop the Line Retrospective (retrospettiva con interruzione della linea di produzione): non appena si verifica un problema “grave” — e va anche stabilito cosa sia un “problema grave” — il team interrompe il proprio lavoro e si riunisce per capire come risolverlo.

Purtroppo non sempre questo è un approccio praticabile: capita che il problema sia più complicato di quello che sembra e non basta una riunione di un’ora per trovare la soluzione. Alle volte può capitare che questo approccio non porti ad avere sufficiente coinvolgimento da parte di tutte le persone del team; il rischio, riportato da chi ha provato a realizzare questa tecnica, è che alcune persone si possano sentire prigioniere, aspettando impazientemente di tornare al proprio lavoro, cosa che di riflesso impatta negativamente anche su chi ha sollevato il problema.

Nella produzione lean messa a punto in Toyota questa politica funzionò probabilmente perché Ohno impose che tutti partecipassero in modo attivo, secondo un approccio “imperativo” che oggi valuteremmo poco in linea con i principi dell’agilità; ma bisogna considerare il periodo storico e il contesto sociale del Giappone post-bellico. Nel contesto attuale di un team di sviluppo, è ipotizzabile che la cosa possa funzionare meno bene.

Pull the Problem

Una variante meno intrusiva e forse più efficace è quella del Pull the Problem, dove il team appende su una lavagna i problemi incontrati: bug da risolvere, necessità di approfondire determinate tematiche o altro che possa impattare negativamente sul flusso della lavorazione.

Su tale board si impone tipicamente un WIP limit sul numero massimo di problemi: non appena tale limite viene superato, il team, al termine del primo standup disponibile, si ferma per un momento di riflessione — una retrospettiva appunto — in cui si cerca di risolvere il problema. Se il tempo non dovesse bastare, si stabilirà una strategia per approfondire meglio il punto, individuando, ad esempio, una porzione di tempo in un altro momento.

Questa tecnica può funzionare meglio rispetto alla Stop the Line Retrospective, perché il “tabellone dei problemi” è, a tutti gli effetti, una Kanban board: senza necessariamente arrivare al superamento del limite, tutto il team si impegna a prendere in lavorazione uno dei cartellini di problema appesi nella board non appena vi è un momento disponibile: per questo si usa il termine Pull the Problem.

Operations Review Meeting

Un’altra interessante evoluzione del concetto di retrospettiva è quella che Anderson chiama Operations Review Meeting, nota anche con il nome di Metrics Review, che tipicamente viene condotta una volta al mese.

Il team in questo caso si sofferma a rivedere lo stato delle metriche, cercando di evidenziare particolari trend o dati insoliti. Sulla base dell’analisi delle misurazioni effettuate, si discute di come stanno procedendo le cose e delle cause degli attuali trend. Utile in questo caso discutere degli esperimenti che sono in corso, valutando gli eventuali effetti che hanno sul lavoro, sempre tramite l’analisi delle metriche in uso.

Quando si pulisce la colonna del “done”

Questo è un aspetto molto interessante sopratutto perché molti lo considerano un dettaglio: si ripulisce la colonna con le attività “già fatte” quando capita, tanto sono attività terminate. In linea di principio può essere un concetto corretto, anche se forse potrebbe essere utile capire meglio cosa si intenda per done.

Alcuni considerano il nome done un po’ fuorviante; il team di sviluppo infatti tende a considerare terminata un’attività quando viene rilasciata in produzione o quando non c’è più alcun lavoro da fare; per il cliente invece l’attività è realmente terminata quando risolve il suo problema.

In tal senso potrebbe essere più corretto chiamare l’ultima colonna released, e non semplicemente “terminata”, e verificare di tanto in tanto se quella attività sta avendo l’effetto desiderato: “OK, è stata rilasciata, ma l’utente la sta utilizzando? È soddisfatto? I suoi problemi sono risolti? Sta avendo l’effetto desiderato in produzione? Sta dando il valore che avevamo stimato?”.

A volte è utile separare la colonna del done in due parti: quello che è arrivato oggi in done, e quello che era già in done. In questo modo, allo standup successivo, si può avere un’idea più precisa di cosa è stato completato, enfatizzando le attività effettivamente completate dall’ultima riunione. Un piccolo cambiamento di nome che ha un’importante implicazione nella product ownership della lavorazione delle attività.

Quante storie far entrare nel sistema

Questo riguarda un po’ il “quando” si mettono le cose nella kanban. Molti team che arrivano da Scrum fanno l’errore di selezionare molte più storie di quante finiranno prima del prossimo replenishment, e quindi sprecano tempo a discutere dettagli e priorità di storie che neanche inizieranno.

Una semplice tecnica per iniziare è guardare quante storie sono completate solitamente tra un replenishment e l’altro, e tirare dentro lo stesso numero di storie. Avremo modo di approfondire ulteriormente questo aspetto in uno dei prossimi articoli.

Conclusione

In questo articolo abbiamo brevemente provato a fornire alcuni suggerimenti pratici su come introdurre qualche miglioramento all’interno del proprio team di lavoro Kanban. Come detto all’inizio, si tratta di suggerimenti derivanti dall’esperienza sul campo e non abbiamo la pretesa di garantire che possano funzionare sempre.