Kanban: il metodo dietro la board

Che confusione….. facciamo un po di chiarezza…. Si sente tanto parlare di agilità, metodologie.. filosofie, strumenti ... concetti che si sovrappongono e si incrociano… Pensiamo a chi sostiene di utilizzare metodologie agili, semplicemente facendo uso delle sole kanban board.

   *** Filosofie**: correnti di pensiero che si basano su principi di carattere generale (Agile, Lean…) 
   * **Metodologie**: framework (Scrum, Kanban..), che fanno uso di tecniche e strumenti specifici (board, sprint etc..) 

Scrum è solo una delle metodologie Agile, come Kanban è solo una delle metodologie Lean. In realtà è sempre aperto il dibattito (tra agilisti ortodossi e non),secondo cui Kanban sia da considerarsi come un framework Agile oppure no…. vedremo in seguito il perché….

Prima di definire cosa sia Kanban, vediamo da dove proviene….. (fondamenta, pilastri e tetto della TPS house)

La parola kanban veniva utilizzata già dagli anni ‘60, nell’ ambito di applicazione di un metodo di gestione dei flussi di produzione ideato dall’ ing. Taiichi Ohno ed i suoi collaboratori presso Toyota, denominato TPS (Toyota production system). Nella quasi totalità delle catene di montaggio dell’ epoca (vedi FORD), era allora implementata la logica "push" secondo cui l’ attività viene spinta da monte verso valle mediante i classici «approvvigionamenti continui di materiali» e «flusso continuo di lavoro» tra i reparti, causando scorte di magazzino se in sovraproduzione, tempi morti in caso di colli di bottiglia e sprechi in caso di minor richiesta del prodotto. Il TPS si basava (e si basa ancora oggi), sulla logica "pull", ovvero del «trascinamento da valle a monte», secondo cui l’approvvigionamento viene richiesto solo quando le scorte stanno terminando, avvalendosi dell’ utilizzo di cartellini (kanban in giapponese significa cartellino visivo, da non confondere con Kanban con la K maiuscola che si riferisce al metodo) per segnalare la necessità di determinate materie o oggetti indispensabili alla linea produttiva per proseguire con il lavoro. Si partiva non piu quindi dalla produzione continua, ma da una produzione relativa alla sola effettiva richiesta ricevuta. Tale richiesta determinava anche gli approvvigionamenti necessari, migliorando la rapidità di consegna, riducendo le scorte a magazzino e rispondendo meglio alle variazioni della domanda. Tutto questo fu possibile solo grazie ad una adeguata catena di fornitura logistica dei materiali, di tipo JIT (Just in time). Toyota voleva infatti evitare carenze ma anche eccessi di scorte di materiali di produzione. Il risultato oggi viene chiamato anche metodo pull, poiché l’approvvigionamento viene richiesto solo quando le scorte stanno terminando.

-Per JIT si intende una gestione delle scorte a ripristino, ovvero si cerca di avere tutti i i materiali necessari, nelle quantità necessarie, solo appena prima di quando serviranno per l’ inizio della produzione, evitando scorte di magazzino preventive, che potrebbero essere inutili in caso di variazione della domanda (come per i semilavorati).

Il VSM (Value stream mapping) è la rappresentazione di tutti i processi e di tutte le attività che venguono eseguite durante il ciclo di realizzazione di un prodotto E' un metodo di visualizzazione grafica che fonda le proprie radici nella filosofia produttiva del sistema Toyota (TPS) sin dagli anni ’80, quando ai vertici della casa automobilistica giapponese si decise di attuare una politica di abbattimento degli sprechi nei processi produttivi. Nacque così il Value Stream Mapping la cui traduzione letterale è Mappatura del flusso del Valore: questo strumento permise di prevenire ogni tipo di spreco, con la conseguenza di non togliere valore al prodotto finito aumentando in modo esponenziale l’efficienza. VSM rappresenta quindi la rappresentazione di tutti i processi e di tutte le attività che realizzano un prodotto a partire dalla materia prima e dai fornitori, passando per tutta la catena di montaggio, fino alla consegna al Cliente. Il VSM è un punto chiave del processo di Lean Manufacturing inserito e perfettamente integrato. Il presupposto sul quale basare l’analisi della catena del valore non è il miglioramento del singolo processo, ma un’ottimizzazione globale e continua.

Il Takt Time è il ritmo della produzione. Si tratta del tempo necessario a produrre un singolo componente o l' intero prodotto.

Jidoka: "Ferma la produzione in modo che la produzione non si fermi mai” (Proverbio di Toyota). La parola , utilizzata nel TPS significa dotare ogni macchina di un sistema e formare ogni lavoratore in modo da poter fermare il processo produttivo al primo segnale di una qualche condizione anomala (ad esempio in una catena di montaggio, un semplice bottone di arresto). Se si scopre un difetto o un malfunzionamento, il macchinario si deve fermare in automatico e i singoli operatori devono immediatamente correggere il problema, interrompendo il flusso produttivo. Questo modo di fare, permette di "costruire la qualità" (build-in quality) ad ogni stadio del nostro processo separando uomini e macchine per ottenere un lavoro più efficiente da parte di entrambi.

Poka-Yoke è una tecnica per evitare semplici errori umani (parte del pilastro Jidoka). Dietro al Poka-Yoke vi è la convinzione che non è accettabile produrre anche un solo pezzo difettoso. Un livello di SCARTO del 0,1% indica che un cliente su mille riceverà un prodotto difettoso. Per tale cliente, però, il prodotto è difettoso al 100%!

Stop amd Notify of abnormality è la possibilità di stoppare la produzione in qualsiasi momento al fine di evitare difetti e necessità di rilavorazione

Ad abitare la TPS house, persone rispettate che concorrono a migliorare il proprio e l’ altrui lavoro!!

Nel TPS, il kanban è proprio il cartellino di segnalazione visuale che rappresenta un segnale identificativo che serve per rifornire di materiale una determinata stazione di lavoro rimastane carente. Il cartellino kanban permette quindi di gestire il flusso dei materiali dalla stazione a monte a quella a valle! In una stazione di lavoro, si puo procedere con la produzione solo se tutto ciò che serve è disponibile, evitando la creazione di semilavorati che potrebbero diventare inutili in caso di variazione della richiesta. Con l’ utilizzo dei cartellini kanban, si notò anche uno spirito di responsabilizzazione degli operai che non dovevano meramente ed indiscriminatamente occuparsi della produzione in serie, ma avevano anche la responsabilità degli approvvigionamenti (maggior coinvolgimento, responsabilizzazione e spirito di partecipazione)!

A proposito di filosofia LEAN: dall'analisi del sistema Toyota, gli autori del libro "La macchina che ha cambiato il mondo«, James Womack and Daniel Jones, [1] negli anni ‘90 hanno coniato il termine "produzione snella". Il lean manufacturing è appunto l'applicazione di tali principi alla produzione industriale. LEAN: metodo di razionalizzazione dei processi attraverso l’ eliminazione degli sprechi: aumento ricavi, riduzione costi, soddisfazione cliente. Gli sprechi sono 8 (MUDA), andateli a vedere…. (acronimo TIM WOODS)

Agile è più giovane di Lean, nato infatti nel 2001, quando un pool di esperti diede vita all’ agile manifesto che ne definisce valori e principi portanti.

I principi del “pensiero snello” sono applicati da anni con successo nelle Operations (in particolare nel settore automobilistico), ma gli stessi principi sono applicati con successo anche in altri ambiti, quali il project management (lean project management) e le start-up (lean startup).

Agile e Lean sono applicabili in diversi settori produttivi perché sono molto flessibili e possono essere strutturati in base alle specifiche esigenze delle aziende. Entrambi sono focalizzati sulle persone e sulla collaborazione: è importante la formazione, per rendere i team di lavori maggiormente performanti, ed è necessario il lavoro di squadra per riuscire a implementare davvero un processo. Infine, entrambi, puntano ad ottenere il risultato migliore nel minor tempo e impiegando il minor numero di risorse possibile (dove per risorse si intende tempo e denaro).

Il kanban, si rifà ai principi della filosofia Lean (ricordate Agile, Lean… della prima diapositiva…sono filosofie) Molti principi lean sono entrati oramai a far parte del bagaglio culturale di chi gestisce i processi di sviluppo software, tant'è che in certi casi, almeno fra coloro che non approfondiscono certe tematiche, i concetti di lean e agile finiscono, erroneamente, per confondersi.

La filosofia LEAN mette il cliente al centro ed attenua con l’ obiettivo di eliminare completamente, tutto ciò che non porta valore al cliente! Il Kanban è quindi una metodologia Lean che puo anche essere usata semplicemente per migliorare altre metodologie come SCRUM!

I 5 principi della Lean Production sono riportati nella diapositiva:

1- Definisco il valore

2- elimino gli sprechi (esempio di movimentazione materiali inutili in ufficio, che non portano valore al cliente e sprecano spazio, tempo, forza etc..)

3- creo il flusso (aiutati con WIP etc)

4- faccio tirare il valore dal cliente (PULL, produzione su richiesta)

5- miglioro continuamente perseguendo la perfezione (Kaizen)

Basandosi sull’ idea del TPS e del sistema kanban, il metodo Kanban si è affermato anche nello sviluppo dei software. Sia alla Microsoft che alla Corbis (un’altra azienda di Bill Gates) negli anni 2000 l’idea dello sviluppo snello proveniente dall’industria automobilistica è stata reinterpretata e adattata da parte di David J. Anderson, che in una conferenza del 2007 presentò tale approccio di gestione.

Non si trattava più di gestire i materiali di produzione, ma di assegnare compiti secondo il metodo pull: non appena un team porta a termine un compito, ne vengono “tirati” altri dal backlog. In questo modo il flusso di lavoro può essere migliorato anche in tanti altri campi. Da li si formarono comunità attorno a tali idee ed ad idee simili. Non si trattava più di work items fisici passati tra i reparti, ma di passaggio di lavoro di conoscenze tra team di lavoro.

Quindi da non confondere:

• Kanban or Kanban method: a method for the definition, management and improvement of services that deliver knowledge work.

• kanban: visual signal that ois used in Kanban systems to limit WIP

• Kanban system: is a flow system with defined commitment and delivery points, and with kanbans that limits WIP

• Kaizen: miglioramento continuo delle operazioni di business, sempre trainante, per l'innovazione e l'evoluzione

I principi lean hanno, come detto, trovato ottimo terreno di sviluppo nel mondo della gestione dei processi di sviluppo software, tanto che l'autore David Anderson ha scritto un libro dedicato proprio a proporre il metodo nell'ambito delle aziende tecnologiche: da questa esperienza si è diffuso l'uso della parola Kanban in ambito IT. In questo testo viene messo in luce come sia possibile ispirarsi a certi principi e certe pratiche della "produzione snella" anche per quel che riguarda la produzione di software.

Quindi come potremmo definire il metodo Kanban (la metodologia di sviluppo sw Kanban?)

Iniziamo con dire cosa non è:

Non è un metodo di project management o un processo di gestione del ciclo di vita dello sviluppo sw……

Il metodo Kanban è definibile quindi come un metodo di gestione per:

• Migliorare l’ erogazione del servizio
• Catalizzare i miglioramenti
• Far evolvere una azienda per essere adatta allo scopo «fit for purpose»

“Kanban is an evolutionary change mehod that utilizes kanban pullsystem, visualization, and other tool to catlyze the introduction of Lean ideas into technology development and IT operations. The process is incremental and permit to obtain process optimization with minimal resistance to change, maintaining a sustainable pace for the workers involved”.

L’impiego di Kanban, incrementa la produttività, prevedibilità e la soddisfazione del cliente riducendo il delivery time. La cultura diviene piu collaborativa!!

Kanban è usato per definire, gestire e migliorare sistemi che distribuiscono servizi di valore al cliente. Come per la produzione di items fisici, viene applicato anche laddove non ci siano items fisici ma lavori di conoscenza, dove i deliveres sono informazioni in varia forma anziché items fisici. Il processo in questo caso può essere definito come una serie di step di passaggio della conoscenza e delle loro policy.

Kanban è quindi un metodo per definire, gestire e migliorare i servizi che forniscono lavoro di conoscenza, come servizi professionali, o progettazione di prodotti fisici e software. Il metodo si basa sul concetto di un sistema kanban, un sistema che regola il flusso di consegna controllando la quantità di lavori in corso (WIP) mediante l’utilizzo di schede di segnale (in giapponese, appunto, kan-ban con k minuscola (signal-cards)!, notare che spesso vedrete scritto «kanbans» al plurale inglesizzato, per indicare i cartellini, anche se in giapponese il plurale è sempre «kanban» senza «s».)

Kanban in breve:

• Limited Work In Progress (WIP). The Reason to put WIP limit in Kanban system is, if there are more items in a queue that don’t proceed, it can risk halting the whole system. Queuing system, nothing moves further unless an existing piece of work is delivered or pulled by a downstream function. The kanban produces a visual signal to indicated that new work can be pulled. Kanban is an approach to introduce change management to an existing software development lifecycle or project management methodology. The principle of Kanban is to introduce change by mapping the value stream and agreeing to WIP limits for each stage in that process. The main focus in kanban is to solve problems, removing waste by unblocking the item and restoring flow.

Come in Scrum, anche Kanban persenta principi (6), pratiche (6), valori (9 fondati sul rispetto delle persone) cadenze (7 meeting) e 3 agendas, non oggetto della presentazione.

Kanban è fondamentalmente un metodo di miglioramento differente dagli altri tradizionali, in quanto altri programmi di trasformazione hanno come scopo il cambiamento dei processi verso un nuovo approccio predefinito (non per Kanban).

Sono due i problemi comuni che portano all’ introduzione di un pull system (leggi Kanban), e non all’ utilizzo di altre metodologie ( che possono anche essere utilizzate e semplicemente migliorate tramite l’ introduzione di Kanban, vedi es. Scrum):

  1- Ricerca di ritmo sostenibile dei team di lavoro nonostante la costante eccessiva richiesta di produttività: Molte aziende hanno puntato su incrementi salariali, cura, psicologi etc. come pagliativo per affrontare I ritmi non sostenibili imposti ai team di lavoro, senza cercare la root cause: limitare il work in progress…. Il multitasking è infatti riconosciuto come non essere produttivo per il cervello quano invece è lavorare su un singolo task per volta, a causa dei continui stacca/attacca che fanno perdere info durante i passaggi)… Bisogna che i dipendenti abbiano la giusta vita sociale, non rovinino famiglie e lavorino ad un “sustainable pace” per un periodo indefinito….

  2- Ricerca di un approccio per introdurre un processo di cambiamento che possa essere introdotto con minima resistenza. Assenza di potere (posizione) necessario a proporre il cambiamento ai team (se funziona nel mio team non necessariamente funzionerà negli altri)

Uno dei 6 principi di kanban (nel change management) è proprio «start with what you do now»……. Che ha questo scopo

Se imponi pratiche e metodi che in realtà non portano ai risultati sperati, viene alimentata la naturale resistenza al cambiamento nei team (perché cambiare se noi abbiamo sempre fatto così??) E’ meglio quindi arrivare a nuovi processi tramite l’ eliminazione dei colli di bottiglia, uno dopo l’ altro… e questa è la teoria dei constraint di Goldratt !! L’ approccio di Goldratt, cerca di identificare i colli di bottiglia e cerca strade per alleviarli sino a che non costituiscano più constraint per le performance nel processo. Quando accade, emerge un nuovo collo di bottiglia da affrontare e cosi via…il ciclo si ripete…. E’ un approccio iterativo per incrementare le performance sistematicamente identificando e rimuovendo i colli di bottiglia. E’ possibile scovare i colli di bottiglia, modellando il work flow del ciclo di vita dello sviluppo del sw, come “value stream”, e creando, tracciando e VISUALIZZANDO il sistema per tracciare i cambiamenti di stato del lavoro mentre percorre il sistema stesso. Goldratt ha gia sviluppato una applicazione della teoria per i problemi di flusso, chiamata “Drum-Buffer-Rope” (un esempio di classe di soluzione conosciuta come PULL SYSTEM, il kanban system è un esempio di pull system…) Un interessante “side effect” del pull system, è che esso limita il wip a valori concordati pe prevenire overload dei lavoratori. Mediante i pull system, è possibile implementare il cambiamento ai processi in maniera incrementale, mitigando la resistenza al cambiamento tramite il ritmo sostenibile…

• Accetto di perseguire il miglioramento attraverso il cambiamento evolutivo
• Controllo delle politiche: riflettere regolarmente sulla loro efficacia e migliorarle

Tutti i valori si basano sul valore del Rispetto!

Kanban defines seven specific feedback opportunities, or cadences.

«Cadences are the cyclical meetings and reviews that drive evolution-ary change and effective service delivery. “Cadence” may also refer to the time period between reviews—one workday or one month, for example. Choosing the right cadence is context dependent and it is crucial to good outcomes. Too-frequent reviews may compel changing things before seeing the effect of previous changes, but if they are not frequent enough, poor performance may persist longer than necessary».

A scheme of seven cadences, depicted in the previous picture, shows suggested frequencies for the reviews in a typical enterprise or multiple-service context.  

Strategy Review : This is for selection of the services to be pro-vided and to define for this set of services the concept of “fit for purpose”; also for sensing how the external environment is chang-ing in order to provide direction to the services.  

Operations Review: This is to understand the balance between and across services, deploying resources to maximize the delivery of value aligned with customers’ expectations.  

Risk Review: This review is to understand and respond to the risks to effective delivery of services; for example, through blocker clustering.  

Service Delivery Review: This is to examine and improve the effectiveness of a service (this and subsequent cadences apply to a single service).  

Replenishment Meeting:  This meeting is for moving items over the commitment point (and into the system) and to oversee the preparation of options for future selection (on demand, non fixed cadence)  

Kanban Meeting: This is the (usually) daily coordination, self-organization, and planning review for those collaborating to deliver the service. It often uses a “stand-up” format to encourage a short, energetic meeting with the focus on completing work items and unblocking issues.  

Delivery Planning Meeting:  This is to monitor and plan deliv-eries to customers.   Implementing the seven cadences does not imply adding seven new meetings to an organization’s overhead, although the Replenishment and Kanban Meetings are considered a baseline in nearly all Kanban implementations. Initially, the agenda of each cadence should be part of existing meetings and adapted in context to fulfill their goals. On a smaller scale, a single meeting may cover more than one cadence.   The feedback loops in the cadence network diagram, show example information flow and requests for change between the reviews. These facilitate decision making at each level.

Replenishment : The act of populating the input queue for a service

The Kanban agendas:

Kanban considers three agendas for change necessary to organization success:

• Sustainability Agenda
• Service Orientation Agenda
• Survivability Agenda

The Sustainability Agenda is about finding a sustainable pace of work and optimizing the focus on the inside of the organization. Its goal is to create services that balance demand with existing performance. When demand exceeds performance, employees are overloaded with work. Introduce transparency about the workload and bring it into balance with the performance of the employees. You create thus a basis empowering all employees to complete their work in a regular rhythm and not to overwork themselves.

The Service Orientation Agenda deals with the performance of the company and customer satisfaction. It focuses on the customers and starts from the actual purpose of the company. Kanban is about providing services and continuously improving them. The goal of the Service Orientation Agenda is to provide customers with the services which meet the company's purpose. On the other hand, they should meet or exceed the needs and expectations of the customers. When all people involved in the company focus on this, it achieves excellent results.

The Survivability Agenda is about staying competitive and adaptable. It deals with the future of the company. Its aim is to ensure that it continues and is successful in times of significant change. Technologies and processes that are currently sufficient must be adapted to constant change. With its evolutionary approach to change, Kanban is well suited to meet these challenges.

Non semplicemente visualizzazione del workflow, ma gestione in tutto!!!! L’ importanza di questo strumento al centro del metodo! Il METODO Kanban usa le kanban boards per visualizzare il lavoro invisibile, il workflow, i rischi del business, insieme al SISTEMA kanban che limita il WIP (work in progress). Le kanban board devono essere semplici-visibili atutti-accessibili-aggiornate-standardizzate!! Aiutano a misurare e analizzare i progressi fatti dal progetto, rendono il processo trasparente e aiutano ad ottimizzare il workflow, rendono oltretutto le policy (come le class of services, esplicite a tutti) Esempio di policies, sono le regole imposte dal codice stradale che tutti conoscono, che ha delle regole esplicite a tutti……. pensa se non vi fossero, quale caos verrebbe generato per strada…… (l’ importanza di renderle visibili, sono i cartelli stradali).

Le kanban boards RAFFIGURANO un flusso di lavoro in cui i work items scorrono attraverso varie fasi di un processo, ordinati da sx a dx!!
Non muovere gli items da dx a sx…. (quindi, nel caso ad esempio di un bug rilevato su un item già deliverato e che dovrebbe quindi tornare indietro nella kanban board,lasciarlo fermo nello step in cui si trova, ed assegnarlo ad un avatar rappresentante la persona che lo prenderà in carico per risolvere la issue).

Affinchè tale flow system sia un «kanban system» devono sussistere diverse condizioni:

• Presenza di segnali visuali per limitare il WIP (nella figura i segnali derivano dalla combinazione dei cartellini, il numero del WIP nella colonna, e la colonna stessa che rappresenta la fase.
• Presenza del commitment point e delivery point dove il commitment è un tacito o esplicito accordo tra cliente e servizio, circa l’inizio della lavorazione dell’ item che il servizio produrrà, mentre il delivery point è dove l’ item sarà considerato completo.
  Si noti che è presente una colonna per la creazione e una per l’ arrivo della richiesta, questo per il «deferred commitment»

E’ profondamente importante rendere visuale l' andamento del flusso di lavoro tramite le kanban board che permetteranno, grazie alla presenza del commitment e delivery point, le swim lanes e le classi di servizio, di calcolare il delivery rate, lead time etc. anche tramite l’ utilizzo della «legge di Little»:

Lead time (o flow-time o cycle time o tempo di attraversamento dell’ intero processo): the elapsed time it takes for a work item to move from the commitment poit to the delivery point (measured in units of time). Questo è il System Lead Time e si riferisce al period che il work-item impiega per passare da commitment a delivery point, mentre il Customer Lead Time è calcolato da prima del commitment.

Flow efficiency: quanto tempo ho lavorato ad un item rispetto a quanto sia stato il lead time (es. Se ci ho lavorato per 7gg su 10, sarà 7/10= 70% di flow efficency   Legge di Little: Formula che mostra la relazione tra lead time, lavori in corso, e tasso di completamento:
quindi la legge di Little calcola il delivery rate, la media di distribuzione ovvero la media di completamento dei work items dato un determinate lasso di tempo e invertendola puo essere usata per calcolare wip ottimali e lead time.  

Delivery rate = WIP/Lead time (The number of work-items emerging complete from the system per unit of time). (quanti work-items rilasci in un dato periodo di tempo, LEGGE DI LITTLE)

Oppure:

Throughput = WIP/Tip (where Tip=time in process)
NB: the system must be statically stationary for the period, or betwee two consecutive points of zero “WIP” , it is the number of work items exiting a system or subsystem per unit of time, whether completed or discarded

Time in Process (TiP): The total time that a work item remains in a state under consideration. More specific terms may be derived by replacing “Process” with a particular part of the process of interest, for example, Time in Development, Time in Test, or Time in Queue.

Forecasting: prevedere accuratamente quando un servizio verrà deliverato al cliente, è sempre stato un problema di difficile gestione.

Due metodi di previsione sono considerati:

1- Effort-plus risk estimating (dividere il progetto in tanti piccoli items, calcolarne le stime di effort necessarie e sommarle (questo ha creato insuccessi epici riportati nella letteratura dell’ ambito progettuale)

2- Probabilistic forecasting basato sul flusso di valore (incapsulato in più piccoli work items rispetto ai progetti tipici), deliverati attraverso team stabiliti. Il «Probabilistic forecasting» lavora usando semplici modelli già esistenti, elaborando alcuni dati (quali variabilità degli item size, lead time e delivery rates), raccolti durante progetti simili condotti in passato. Molto utilizzato in tal senso, è il metodo MonteCarlo che ripete lo scenario piu volte e genera percentuali relative a possibili date di rilascio del work-item (percentuali… non impossibili certezze!!). Quindi il «Probabilistic Forecasting» lavora bene quando dati storici riguardo le performance dei team sono già disponibili.

Altri termini:

Monte Carlo methods = A broad class of computational algorithms that rely on repeated random sampling to obtain numerical results.

Metrics: per concordare degli SLA con il cliente, è quindi necessario collezionare dati di performance del kanban system implementato. Per farlo, si usano metriche di flusso (grafici) che evidenziano l’ andamento del lavoro dei team (bisogna quantomeno collezionare i dati sul lead time, delivery rate, wip e cost……..

I grafici piu utilizzati x le metriche in Kanban sono:

Run Chart showing scatter plot (Realization time scatterplot, throughput scatterplot

CFD (Cumulative flow diagrams), grafico che riporta la quantità di lavoro in un determinato stato

Frequency distribution

I percentili,sono utilizzati con gli scatterplot per stabilire gli SLA; 85simo percentile significa che l’ 85%dei task sullo scatterplot è sotto la riga prestabilita (quello sarebbe lo SLA)

Alcune rappresentazioni grafiche delle metriche (lead time rappresentato da uno scatterplot come nell’ esempio), CFD e Run chart….. Gli SLA da concordare derivano da queste metriche…. Queste metriche sono fondamentali per disegnare, bilanciare un flusso.

Se ad esempio all’ interno di uno step (colonna) della kanban board ho un throughput troppo basso rispetto agli step nell’ intorno dello stesso, si crea un collo di bottiglia e quindi devo agire proprio in quello step di modo che il il suo Throughput venga alzato e permetta un allineamento con il throughput degli step precedente e successivo (cosicchè il flusso scorra senza rallentamenti). Come fare? Potremmo aggiungere una risorsa in quello stadio del processo e, modificando il WIP dello stesso secondo la formula throughput=wip/tip, aumenteremo anche il throughput eliminando il collo di bottiglia!

Vediamolo numericamente applicato ad un ciclo produttivo composto da 3 fasi con i seguenti Throughput orari, per la creazione di pezzi semilavorati (nel nostro ambito parleremmo di uno step di trasferimento di lavoro di conoscenza nel ciclo progettuale):

Fase1  Throughput=3

Fase2  Throughput=2,5 (con WIP=5)

Fase3  Throughput=3

Significa che la Fase2 rappresenta un collo di bottiglia che impedisce lo scorrimento regolare del flusso di produzione lungo le tre fasi, e che quindi proprio in questa fase bisognerà agire affinchè venga allineato il Throughput alla Fase1 e Fase3.

Situazione attuale della Fase2 considerando la legge di Little (TP=WIP/TIP): 2,5=5/2

Per raggiungere il nostro scopo, modificheremo il WIP da 5 a 6 affinche il Throughput sia uguale a 3: 3=6/2

Swimlane : linee orizzontali sulla Kanban board, che attraversano due o più colonne ed organizzano i work-items in categorie come il tipo, la classe di servizio etc… Le swimlanes possono essere x persone, urgenze, prodotti….

Classes of service: set di policies che descrivono come un work item dovrebbe essere trattato usate per classificare I tipi di work items e raggrupparli in base a differenti customer expectation, valore relativo, rischio o cost of delay. Creano flussi paralleli sulla kanban board I Workitems vengono divisi in base a determinate esigenze, caratteristiche etc, dando vita anche alla prioritizzazione degli stessi (ogni class of service puo avere il suo WIP orizzontale e verticale)

Utilizzando le class of service, I team sono in grado di prioritizzare il lavoro per urgenza e valore in base al cost of delay.

Vengono raccomandati 4 tipi di “Class of service”:

Standard (non cè senso di urgenza, in genere gli standard work items scorrono come first-in-first-out)

Fixed delivery date (significante cost of delay se non deliverato a quella data fissata, es. una future per il portale di un negozio on line in occasione dei saldi!). Se in data prossima a quella prestabilita non si riesce a deliverare, l’ item passa ad “expedite” (successivamente ai saldi non sarebbe infatti più utile deliverarla).

Expedite (work items che richiedono gestione immediate, critici e di massima priorità (WIP Limit settato a 1 per I work items di questa class of services)

Altri termini comuni:

Intangible (work items utili ma con basso cost of delay (a lungo andare, I work items intangibili potrebbero diventare critici, allora verrebbero promossi ad expedite)

Il “Cost of delay”, che rappresenta il principale parametro per la classificazione e prioritizzazione dei work items, è basato sulle policy e sulla definizione delle 4 class of services.

• “Swift Kanban” : tool per la gestione di progetti mediante metodo Kanban, migliore per creazione boards con classes of services, wip, swimlanes etc… e calcolo delle metriche e simulazione Montecarlo x analisi predittiva dei commitments.

Alcuni cenni relativi all’ introduzione di Kanban in una organizzazione:

Kanban può essere introdotto tramite STATIK (acronimo di «system thinking approach to introduce kanban»), secondo cui il sistema viene visto come un «ecosistema» e non come un unico blocco.

• Il «System thinking» è un modo di comprendere come un sistema si comporta nel suo insieme, piuttosto che analizzare singolarmente le parti che lo compongono. E’ importante comprendere questo, per l’introduzione di Kanban in una organizzazione attraverso gli 8 steps di statik (non necessariamente sequenziali ma anche iterativi), usando gli insegnamenti di uno step, per gli step successivi in un ambiente COLLABORATIVO.
  • Non copiare semplicemente da un’ altro systema kanban!!!!! Non funzionerebbe, ogni sistema deve essere progettato usando STATIK, studiando il flusso di valore e i rischi del business, la capacità, il tutto al fine di bilanciare domanda e capacità….

  • E' importante quindi capire che una organizzazione possa essere vista come in insieme di servizi interdipendenti, con policy che ne determinano il comportamento.

Lo stato di maturazione ed avanzamento del sistema verso l' ottimizzazione mediante Kanban, viene monitorato tramite il Litmus test eseguito periodicamente, che pone alcune domande per classificarne lo stato di avanzamento verso il completamento della transizione.

• Un sistema intermedio durante la transizione kanban, viene detto protokanban, ed è misurabile lungo il percorso proprio tramite il LITMUS test.

Per stabilire se Kanban sia agile o no, bisogna innanzitutto definire l’ agilità… Gli agilisti ortodossi dicono che, non essendoci rilasci programmati (time boxed) e le iterazioni (sprint), nonostante vengano rispettati i principi del manifesto, non lo riconoscono come agile e se non lo è lo definiscono quindi waterfall.....

Spesso vengono utilizzate solo le kanban board all' interno di altre metodologie considerate agili dagli agilisti ortodossi (vedi es. scrum), ma c’è da considerare che addirittura le primissime implementazioni di Kanban, non includevano l' uso delle kanban boards stesse.....

In realtà l' introduzione di Kanban dal 2007-2008 ha ragioni ben precise identificabili nella necessita di trovare un metodo che avesse un impatto minore su una riorganizzazione aziendale, rispetto ad alle altre metodologie tradizionali agili. Infatti, a differenza delle altre metodologie ritenute oggettivamente agili in quanto perfettamente aderenti ai principi del manifesto, qui non viene richiesta una riassegnazione di ruoli ed una introduzione specifica e stretta di riti e cicli di iterazione, ma avviene una introduzione graduale con un minore impatto sull' organizzazione (ricordiamo l' assenza di ruoli ad esempio).

Uno dei principi è infatti "start from what you do now", nel senso che non tutto della tua organizzazione è da buttare, quindi inizia la transizione da ciò che già fai..... Si introducono piccole modifiche al ciclo produttivo che facciano fede alle pratiche di tipo pull, responsabilizzando i lavoratori e dando visione a tutti, di ciò che avviene in azienda. A tal proposito, si pensi alle kanban board che vengono poste nelle aree ristoro, vicino alle macchine del caffe di modo che tutti possano vedere lo stato di avanzamento dei lavori, portando anche suggerimenti a chi ad esempio è bloccato su un task, e dando responsabilizzazione alle persone che se vedono il loro task fermo da tempo, sotto gli occhi di tutti, si prenderanno a cuore la sua chiusura.....

In definitiva.... cosa importa se Kanban sia agile o no? L' importante è capire se le pratiche e i principi del Kanban possano avere o meno un impatto positivo sull' organizzazione, al fine di erogare valore continuo alla stessa..... Quindi sarebbe preferibile domandarsi: << Kanban migliora il processo produttivo nelle aziene tecnologiche?>

La risposta è <<SI!>>

La comodità di ritenerla una metodologia agile stà nel fatto di poterla proporre ad aziende che vogliano scalare ad agile senza tentare di spiegare loro che, nonostante non aderisca a tutto ciò che richiede l' agilità, porterà a migliorare i processi produttivi.....

Alcune differenze tra le due metodologie:

• In scrum, il team determina il task da eseguire e ne stima la durata nei planning meeting, mentre in kanban non viene eseguita la stima dei task, infatti il team semplicemente lo preleva ed inizia a lavorarci (continuously)

• Scrum traccia la velocità (quanto lavoro viene eseguito tra due incrementi), mentre Kanban traccia il flusso

• In Scrum, il processo è gestito dallo scrum master, in kanban dal team

• Scrum è piu prescrittivo (più ruoli da seguire), mentre kanban è piu adattivo (meno ruoli da seguire)

Quale sia meglio dipende dal contesto…..

Per concludere:

• Il ciclo di implementazione di Kanban si basa sull' introduzione di piccole modifiche al flusso di lavoro esistente, cicliche, accompagnate da feedback, per un processo di miglioramento continuo (Kaizen), in definitiva "Improve collaboratively, evolve experimentally«, oltretutto:
• Si basa sul lean da cui prende i principi e la logica pull.
• Introduzione più morbida rispetto alle tradizionali agili
• Crea spirito collaborativo e responsabilizza
• Utilizza tool (come le kanban board) per condivisione dello stato di avanzamento lavori, impegno, wip etc....