Kanban: attenzione a non farsi prendere la mano…

Kanban è una metodologia basata sul modello organizzativo di tipo “pull” cioè deriva dall’idea che uno step di processo “tiri” quello precedente mediante l’invio di un segnale che si attende a valle della catena.

Questo modo di procedere è opposto al sistema “push” (spinto) dove ogni step di processo corre il più velocemente possibile senza limiti imposti dalle lavorazioni contemporanee.

Negli anni 50 Toyota introdusse questo il modello di produzione “pull” (in antitesi al modello push di Ford) in cui il processo produttivo si spingeva ad ottimizzare le fasi a monte del processo (come ad esempio analisi dei fabbisogni dei consumatori) in questo modo si evitano problemi di sovrapproduzione limitando all’osso le scorte in magazzino così da avere la quantità minima indispensabile di materie prime appena in tempo per produrre un determinato prodotto.

Kanban è un termine giapponese che significa Kan () “visuale”, Ban () “segnale”.

Questo modello produttivo che inizialmente nulla aveva a che fare con il mondo dello sviluppo software ha allargato i suoi confini quando nel 2010, David Anderson scrisse il libro “Kanban”.

In questo libro D.Anderson spiega come applicare, al mondo della tecnologia e del software, le caratteristiche della metodologia Kanban e del Lean Manufacturing in generale.

 

Secondo lui, questa metodologia di lavoro consente di:

  • visualizzare, misurare e gestire il flusso di lavoro;
  • limitare i lavori incompleti;
  • regole chiare per gli addetti ai lavori;
  • migliorarsi di continuo “aggiustando il tiro” mediante analisi dei risultati e mediante il monitoraggio di lead time (tempo trascorso tra richiesta e risultato) e del cycle of a process (il tempo necessario a completare un’attività)

Kanban in pratica

Una lavagna e qualche blocchetto di post-it sono gli elementi base per avviare Kanban. Si suddivide la lavagna in colonne dove ogni colonna è una singola fase del ciclo di lavoro. Ogni singolo post-it rappresenta un’attività. Quando qualcuno ha finito di compiere un’attività, guarda sulla lavagna cosa deve essere fatto e sposti l’attività che si prende in carico nella colonna apposita (ad esempio in quella “in corso“). Quell’attività diventa quindi una sua responsabilità fino a quando non viene portata a termine. La board Kanban permette di mostrare a tutto il team quali sono i task in essere, chi se ne occupa, a quale stadio di avanzamento si trovano e, data la complessità del task e il suo grado di avanzamento nel flusso, quanti altri lavori possono essere seguiti in contemporanea in quello stato.

 

Una volta rappresentato visivamente il processo, è facile controllare l’avanzamento delle singole attività e vedere subito dove si formano rallentamenti monitorando Lead Time e Cycle Time. La cosa positiva dell’utilizzo dei sistemi Kanban è che tutti possono vedere subito dove si forma un problema e che un’identificazione precoce della problematica porta ad una sua più semplice risoluzione.

Attenzione a non farsi prendere la mano

Il rischio di questa metodologia è quello di concentrarsi solo alle attività in ToDo ed Ongoing rischiando però di trascurare l’organizzazione del backlog ed il processo di miglioramento incrementale.

Perché il modello kanban sia veramente efficace serve fare attenzione a questi punti:

  1. Deve essere definito un modello per la selezione delle attività dal backlog
  2. Una volta messa in lavorazione, un’attività non deve mai essere abbandonata
  3. Organizzare con precisione i Meeting previsti dal modello con l’obiettivo di migliorare efficacia ed efficienza

1. Non confondiamo Kanban con Agile

Kanban può essere considerato aderente all’Agile Manifesto solo per quanto riguarda la voce “rispondere al cambiamento più che seguire un piano”.

Kanban è lontano dalle pratiche Agili per la mancanza di consegne fisse a tempi prestabiliti (time-boxed), vale a dire le cosiddette “iterazioni”.

2. Selezione delle attività

Il backlog non deve essere visto come un contenitore informe di attività, a monte del backlog devono essere attivati dei modelli di catalogazione e prioritizzazione. Possono quindi essere organizzate tre fasi a monte del backlog che sono:

  1. pool of task: questo è il primo stadio ed è il contenitore di tutte le attività raccolte in modo destrutturato
  2. selection and validation: in questa fase ricorrendo a tecniche tipiche utilizzate nel Product Management e nel Risk Management vengono attribuite priorità e dipendenze ad ogni singola attività. Questa è anche la fase demandata al perfezionamento del task per definire nel dettaglio obiettivi e dipendenze
  3. ready to backlog: è lo stadio che precede il backlog, queste attività vengono richiamate dal backlog stesso quando quest’ultimo arriva in soglia di “rifornimento”. Importante è che in questa fase di “pull” le attività che passano da ReadyToBacklog a Backlog si muovano in blocco per dipendenza

3. Mai abbandonare un’attività e non strappare

Su questo tema non c’è molto altro da aggiungere, sembra quasi banale soffermarsi a discuterne ma nella realtà invece sono molte le occasioni che ci “tentano” a sottovalutare questo vincolo. Spesso proprio nella gestione delle emergenze la tendenza è quella di abbandonare l’attività in corso per concentrarsi sull’imprevisto con il rischio di innescare un processo flip-flop che nel lungo ci porta ad accettare questa modalità operativa che ha come impatto il fatto di sfalsare le metriche di misurazione di performance.

Sul fronte invece del “non strappare” e cioè sul fatto di trovare e mantenere un ritmo regolare, ci viene in aiuto Mary Poppendieck con questa frase cristallina: “A regular cadence establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”

4. L’importanza dei Meeting

Molti di noi sono convinti che messa in piedi la Board e definito il meeting giornaliero tutto sia fatto e tutto sia sufficiente per sostenere che “stiamo usando il modello Kanban”. Invece così non è!

La rete di meeting e review nel modello Kanban sono ben 7 con diversi cicli temporali e interagiscono tra loro come riportato nell’immagine qui sotto:

Andiamo a vedere quali sono gli obiettivi di ogni singola review:

4.1 Standup meeting (daily): 

E’ solitamente l’incontro (preferibile farlo in piedi) più frequente (giornaliero) e serve a mantenere la squadra compatta verso l’obiettivo e condividere le informazioni utili a prendere le decisioni migliori su come utilizzare il tempo.

Le domande tipiche che ci si pone durante questo incontro sono: come stiamo lavorando? su cosa?, chi ha bisogno di aiuto? qualche attività è bloccata?

4.2 Replenishment Meeting (weekly)

Kanban è un sistema pull e quindi necessita di attività nella coda di input per evitare di rimanere “affamati”. Il Replenishment Meeting è l’incontro in cui decidiamo come organizzare il “rifornimento” della coda. Scrum chiama questa fase: Sprint Planning Meeting. Il primo esempio documentato di Replenishment Meeting risale a quando David Anderson organizzò regolari riunioni di rifornimento quando scoprì che una squadra aveva difficoltà a dare priorità al lavoro in arrivo da più manager, e così organizzò incontri bisettimanali per condividere insieme la priorità delle attività.

Il risultato atteso da questo incontro è raccogliere dagli stakeholder feedback e determinare qual’è l’insieme di compiti più importanti da svolgere. Fatto spesso e in modo trasparente, aiuta gli stakeholder a fidarsi di ciò che viene promesso.

Il Replenishment Meeting deve essere svolto coinvolgendo le persone “giuste” cioè coloro che possono prendere decisioni. La frequenza di questi incontri dipende dall’efficienza dei loop di feedback, della velocità di consegna e dalle dinamica dell’ambiente in cui il sistema sta operando. Indicativamente una frequenza settimanale è sufficiente ma questo meeting può anche non essere periodico ma essere attivato in base alle necessità come ad esempio innescato da un limite di attività minimo nella coda.

4.3 Service Delivery Review (bi-weekly)

Questo è il momento in cui il team si pone la seguente domanda: Come stiamo servendo i nostri clienti? Viene quindi effettuata una revisione del servizio dal punto di vista dei beneficiari.

E’ fondamentale questa riflessione perché l’efficienza del team viene sprecata se il cliente non è soddisfatto. La revisione della consegna del servizio, che coinvolge rappresentanti degli utenti finali, esplora la soddisfazione del cliente con tutti gli aspetti del processo, tra cui l’efficienza, la comunicazione, la consegna rispetto agli SLA e l’utilizzo delle risorse del team. L’obiettivo è migliorare la soddisfazione del cliente e creare fiducia attraverso la trasparenza.

La review viene fatta rivedendo l’ultimo lotto di lavoro consegnato analizzando qualità, SLA e qualsiasi altro criterio di successo con i clienti. Le domande da porsi in questa review sono: i clienti sono soddisfatti di ciò che viene consegnato? Sono soddisfatti di quanto frequentemente e di come viene consegnato? Sono contenti che stai facendo il miglior uso delle risorse disponibili per fornire valore? Quando le cose vanno male, sono contenti della tua reazione e comunicazione sui problemi emergenti e sono convinti che il tuo processo di valutazione del rischio sia sufficiente a minimizzare i danni a valle?

4.4 Operation Review (monthly)

L’Operation Review ha l’obiettivo di analizzare e rilevare come collaborano tra loro i vari team.

Non si può pensare di migliorare un sistema senza considerare tutte le altre parti. Un singolo team non può salvare un’organizzazione che ha una pipeline di consegne scadente. In questa review quindi i manager di diversi settori cercano modi per migliorare il sistema nel suo complesso.

Questa review viene fatta rispondendo alle domande: Quanto sono felici i clienti? Quanto è redditizia l’azienda? Ci sono stati cambiamenti nel turnover del personale? C’è e dov’è capacità sotto-utilizzata? Sulla base di questi dati, il team elabora esperimenti per migliorare l’efficienza del flusso di lavoro nell’intero sistema.

4.5 Risk Review (monthly)

Lo scopo della Risk Review è quello di valutare la probabilità di non riuscire a soddisfare le aspettative, sia per i componenti del sistema a valle che per gli utenti finali.

Identificare i rischi in anticipo e adottare misure per mitigare tali rischi migliora la prevedibilità del sistema, aumentando la fiducia e la redditività.

Il livello più elementare di revisione del rischio consiste nell’esaminare i fallimenti del passato, sotto forma di attività bloccate, rielaborare gli SLA, e identificare le cause alla base e trovare modi per evitare che tali eventi si ripetano. Una pianificazione dei rischi più completa include speculazioni su possibili rischi futuri basati sull’esperienza e sull’input da tutti i livelli. 

4.6 Delivery Planning Meeting (delivery cadence)

Partendo dal riconoscere che la maggior parte di noi non consegna direttamente al cliente finale questo incontro serve a migliorare i passaggi tra team.

Il tema valle del nostro potrebbe non apprezzare il fatto di trovare una pila di lavoro a intervalli casuali. Potrebbero quindi apprezzare il fatto di essere coinvolti nel decidere come, quando e cosa viene consegnato.

L’analisi viene fatta raccogliendo feedback dai team a valle del nostro, incrociando queste informazioni con gli output dei meeting giornalieri, con la board e con il risk review il tutto per valutare i flussi di ciò che è pronto in consegna e ciò che sarà pronto a breve.

L’obiettivo è assicurare un trasferimento fluido dei WIP (i WIP sono i deliverable prodotti dal TeamA e consegnati al TeamB ricevente). Come risultato di questa riunione, alcune attività in corso potrebbero cambiare priorità. 

4.7 Strategy Review (quarterly)

La Strategy Review esamina i cambiamenti del mercato e si chiede se i nostri attuali obiettivi operativi siano ottimizzati per soddisfare le esigenze emergenti.

La domande che ci dobbiamo porre sono: siamo davvero efficienti? Ma stiamo facendo la cosa giusta? La cosa giusta è cambiata a causa delle condizioni di mercato? Questo incontro è quello quindi in cui rivedere la strategia aziendale e garantire che i nostri processi stiano offrendo il valore che meglio serve alla nostra strategia di business.

Durante lo Strategy Review si devono confrontare le consegne recenti con le tendenze del mercato e porsi la domanda: siamo abbastanza flessibili per adattarci alle richieste di mercato? Se c’è una discrepanza tra la nostra capacità di apportare modifiche significative alle nostre offerte e il ritmo delle nuove richieste del mercato, dobbiamo prendere in considerazione la possibilità di cambiare mercato o di trovare modi per ottimizzare i nostri processi. Le persone da coinvolgere ed a cui porre tali domande sono i dirigenti aziendali con input da parte di unità di marketing e clienti e che si occupano di business come vendite e assistenza clienti. Il risultato di questo incontro potrebbe essere nuove linee guida per la valutazione di idee di prodotto o indicatori KPI che siano meglio allineati con le aspettative del mercato.

La periodicità dei meeting

La periodicità di questi meeting è una proposta che vi ho fatto io ma non è scritto da nessuna parte che tutte queste cadenze devono avvenire a intervalli regolari. Potrebbe essere sensato collegarne alcuni agli eventi. Ad esempio, le revisioni dei rischi potrebbero essere effettuate mensilmente, ma potrebbero anche essere innescate da errori critici. Le revisioni sulle consegne potrebbero anche essere biennali quando tutto sta andando bene e potrebbero essere attivate automaticamente dal mancato nel momento in cui gli SLA vanno in area critica. Le riunioni di rifornimento potrebbero verificarsi settimanalmente oppure potrebbero essere attivate da un determinato numero minimo di elementi in una coda di input. Le cadenze temporali sono utile per le situazioni in cui vi è un valore negli aggiornamenti frequenti come gli standup meeting o per quelle cose importanti ma non urgenti che potrebbero non innescarsi mai come ad esempio la revisioni della strategia.

Agile Scrum e Kaizen un’accoppiata vincente

Kaizen è la composizione di due termini giapponesi, KAI (cambiamento) e ZEN (migliore), e significa cambiamento migliore. È stato coniato da Masaaki Imai nel 1986 per descrivere la filosofia di business che supportava i successi dell’industria nipponica negli anni ‘80.

Il Kaizen come strategia comportamentale si riferisce ad una pratica diretta al miglioramento costante. L’enfasi del Kaizen sulla gestione logistica ha radici profonde legate alla strategia militare con particolare riferimento all’arte della guerra di Sun-Tsu. La vision della strategia Kaizen è quella del rinnovamento a piccoli passi, da farsi giorno dopo giorno, con continuità. Questa strategia è in radicale contrapposizione con concetti quali innovazione, rivoluzione e conflittualità di matrice squisitamente occidentale. La base del rinnovamento è quella di incoraggiare ogni persona ad apportare ogni giorno piccoli cambiamenti il cui effetto complessivo diventa un processo di selezione e miglioramento dell’intera Organizzazione.

Continue reading “Agile Scrum e Kaizen un’accoppiata vincente”

DevOps: che fine ha fatto la QA?

In merita alla relazione tra DevOps e QA (quality assurance) si trovano in rete inquietanti slogan del tipo: If you work in software quality assurance (QA), it’s time to find a new job.

L’affermazione è in parte vera ma nel senso che il modello DevOps elimina la necessità del controllo qualità come entità separata, fondendo la responsabilità per la qualità all’interno dei diversi team.

Una tale evoluzione è molto radicale, personalmente consiglio di procedere sempre per buon senso e quindi per gradi, mantenendo questa disciplina ancora in capo a strutture preposte portando però queste strutture alla partecipazione attiva negli sprint.

Continue reading “DevOps: che fine ha fatto la QA?”

Agile – The Chicken and the Pig

Il racconto The Chicken and the Pig (“Il Pollo ed il Maiale”) è una storiella sull’impegno per un progetto. Il testo della storiella è circa questo:

-Un Maiale ed un Pollo camminavano per strada.

-Il Pollo disse: “Ehi Maiale, mi è venuta una bella idea, potremmo aprire un ristorante!”

-Il Maiale replicò: “Hm, non so, come potremmo chiamarlo?”

-Il Pollo rispose: “Che dici di ‘uova e pancetta’?”

-Il Maiale pensò un momento e disse: “No grazie. Io sarei completamente coinvolto mentre tu saresti solo interessato!”

Continue reading “Agile – The Chicken and the Pig”

Introduzione al DevOps

DevOps: cos’è?

Il termine «DevOps» è stato coniato da Patrick Debois all’inizio del 2009 in Belgio.

DevOps è un insieme di processi, metodi e strumenti indirizzati alla (1) comunicazione ed alla collaborazione e punta ad aiutare un’organizzazione a (2) sviluppare in modo più rapido ed efficiente prodotti e servizi software. Quindi uno dei primari obiettivi del DevOps è quello di costituire un ecosistema di strumenti e processi operativi che permettano di abbattere quello che comunemente viene chiamato “Wall of Confusion” e che nei modelli “tradizionali” separa il mondo Development dal mondo delle Operations.

Continue reading “Introduzione al DevOps”

Manifesto Agile e SCRUM

Manifesto for Agile Software Development

Nell’ingegneria del software, l’espressione metodologia agile si riferisce a un insieme di metodi di sviluppo del software emersi a partire dai primi anni 2000 e fondati su un insieme di principi comuni, direttamente o indirettamente derivati dai princìpi del “Manifesto per lo sviluppo agile del software” (Manifesto for Agile Software Development, chiamato anche “Manifesto Agile”) pubblicato nel 2001 da Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.. I metodi agili si contrappongono al modello a cascata e altri processi software tradizionali, proponendo un approccio meno strutturato e focalizzato sull’obiettivo di consegnare al cliente, in tempi brevi e frequentemente (early delivery/frequent delivery), software funzionante e di qualità.

Il Manifesto Agile tradotto in italiano recita:

Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti:

  1. Gli individui e le interazioni più che i processi e gli strumenti
  2. Il software funzionante più che la documentazione esaustiva
  3. La collaborazione col cliente più che la negoziazione dei contratti
  4. Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.

Andando più a fondo possiamo aggiungere che:

  1. Gli individui e le interazioni più che i processi e gli strumenti: il fattore chiave sono le persone; processi e strumenti sono importanti ma non compensano persone poco competenti
  2. Il software funzionante più che la documentazione esaustiva:  la documentazione è utile ed è necessaria in un progetto ma il valore reale è dato da un software funzionante. La metodologia Agile prevede il rilascio di software funzionante attraverso incrementi successivi.
  3. La collaborazione col cliente più che la negoziazione dei contratti: l’approccio Agile si basa sulla “condivisione di valore” e il cliente viene visto come un collaboratore.
  4. Rispondere al cambiamento più che seguire un piano: tecnologie e modelli di business sono in continuo cambiamento; è quindi essenziale un approccio allo sviluppo in grado di adattarsi alle circostanze. Una “pianificazione statica” diventa obsoleta in breve tempo.

I dodici principi del Manifesto:

  1. La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito
    e in maniera continua.
  2. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
  3. Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
  4. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
  5. Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
  6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.
  7. Il software funzionante è il principale metro di misura di progresso.
  8. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
  9. La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.
  10. La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.
  11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
  12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

Che cos’è SCRUM?

Scrum è il metodo Agile più diffuso, si tratta di un framework, un particolare insieme di pratiche, che divide il processo di gestione di un progetto in sprint. Un processo iterativo in cui gli sprint durano da 2 a 4 settimane.

La teoria alla base di questo metodo è quella del controllo empirico dei processi, secondo la quale, la conoscenza deriva dall’esperienza e le decisioni si basano su ciò che si conosce. Per questo motivo si prevede un processo iterativo con un approccio incrementale che ottimizza, passo dopo passo (sprint dopo sprint), la prevedibilità ed il controllo del rischio.

Un metodo che si basa sui principi della trasparenza, dell’ispezione e dell’adattamento.

Le componenti principali di SCRUM si dividono in: ruoli, artefatti ed eventi.

Ruoli

PRODUCT OWNER (r1): colui che conosce tutti i requisiti del prodotto è l’interfaccia tra il business, i clienti e i requisiti del prodotto da un lato e il team dall’altro.

SCRUM MASTER (r2): il responsabile del processo, colui che deve garantire che la metodologia Scrum venga compresa ed eseguita con successo.

TEAM DI SVILUPPO (r3): il gruppo di professionisti cross-funzionali ed auto-organizzato, il cui numero di solito si mantiene da 5 a 9. Si occupa dello sviluppo del prodotto e del testing delle funzionalità e ha la responsabilità di organizzare requisiti in task da completare in un determinato sprint.

Artefatti

PRODUCT BACKLOG (a1): la lista di tutti requisiti necessari per la realizzazione del progetto. Il Product Owner è responsabile del suo contenuto, della sua disponibilità e dell’ordinamento dei suoi elementi in base alla rispettiva priorità di svolgimento.

SPRINT BACKLOG (a2): definisce tutti i task da completare nei singoli sprint. È una previsione fatta dal Team di Sviluppo in relazione alle priorità indicate nel Product Backlog e al lavoro necessario per raggiungere gli obiettivi dello sprint.

INCREMENTO (a3): la somma di tutti gli elementi del Product Backlog completati durante uno sprint e durante gli sprint precedenti. Al termine dello sprint l’incremento dovrà garantire un prodotto utilizzabile.

Eventi

SPRINT PLANNING (e1): la riunione in cui il Product Owner ha stilato il Product Backlog e, in presenza del Team di Sviluppo e dello Scrum Master, descrive gli item più importanti e l’obiettivo da raggiungere nello sprint seguente. Al termine della riunione lo Scrum Master può compilare lo Sprint Backlog.

DAILY SCRUM (e2): un breve confronto giornaliero (della durata di 15 min) fra Team di Sviluppo e lo Scrum Master, il quale annota il lavoro svolto il giorno precedente e crea un piano per le prossime 24 ore (fino al prossimo Daily Scrum) per prevedere e sincronizzare le attività. Si preoccupa inoltre di rilevare eventuali impedimenti ed attuare possibili rimedi così da salvaguardare il buon esito dello sprint in corso. E’ a carico dello Scrum Master dichiarare il fallimento dello sprint in caso di impedimento critico, imprevisto e non risolvibile. Il fallimento dello sprint si traduce nella chiusura dello sprint in corso e nell’avio di un nuovo Sprint Planning.

SPRINT RETROSPECTIVE (e3): una retrospettiva effettuata con la partecipazione di tutto lo Scrum Team per valutare cosa continuare a fare, cosa smettere di fare e cosa migliorare nello sprint successivo per ottenere performance ancora più efficienti.

SPRINT REVIEW (e4): una revisione alla fine di ogni sprint per valutare se l’obiettivo prefissato è stato raggiunto e con quali risultati. Partecipa tutto lo Scrum Team e anche il committente del prodotto, al quale verrà mostrato il lavoro svolto fino a quello sprint.

 

 


Collegamenti Esterni

Agile Manifesto: http://agilemanifesto.org/iso/it/manifesto.html