Scrum: in Italia, chiamiamolo Corner !

Il tema non è il calcio o il rugby, ma di comunicazione. Vorrei riportarvi alcune esperienze dirette che ho riscontrato parlando di Scrum con i team di sviluppo, ma non solo.

Quando introduci Scrum, la prima domanda che ti fanno è: cosa significa Scrum ?
La classica risposta è che si tratta della "mischia", una azione del rugby, in cui.... etc. etc.
In genere, si aggiunge che, in un team, non importa che tu sia difensore o attaccante. Se puoi, fai meta.

E fin qui tutto bene. Ma.... dopo un po', gli old-school manager sollevano le prime obiezioni: "Bello, ma chi fa cosa ? Chi ha in carico le azioni ? Qual è lo stato di avanzamento ? In una mischia, spesso non si capisce niente, lo dice la parola...".

E quindi si creano le prime diffidenze ed i primi scetticismi.
Durante una transizione verso l'adozione delle metodologie agili, questo è uno dei temi più delicati ed il middle-management vive un senso di smarrimento unito alla diffidenza.

Ma veniamo al titolo del post. La scorsa settimana sono stato a Palermo ed ho incontrato diversi team. Non sono nuovi a Scrum. Ci sono diversi Scrum Master certificati. Ma ho parlato di calcio, non di rugby. Ecco cosa gli ho detto.

Calcio d'angolo contro. Avete mai visto cosa succede in area di rigore ? Il portiere urla richiamando le posizioni. I difensori si auto-organizzano, si cercano con lo sguardo, valutano le posizioni, le marcature, le dinamiche, conoscono le indicazioni dell'allenatore, ma in campo ci sono loro.

Anche gli attaccanti, che in questa fase sono a difesa della loro porta, si strattonano con gli avversari. L'arbitro è costretto a rimandare la battuta del corner per sedare gli animi.
Uno degli attaccanti "difensori" rimane un po' più alto: potrebbe arrivare un rinvio e quindi una occasione per un contropiede. C'è un possibile schema provato e riprovato.

Spesso, in questa fase, ci sono colpi proibiti. Qualcuno esce con una maglietta strappata. Qualcuno addirittura tira i capelli all'avversario. L'allenatore (e l'esperienza) ti insegnano anche come fare fallo.

E se prendi un goal su palla inattiva... l'allenatore ne avrà per tutti quando si rientrerà negli spogliatoi.
Finisce il primo tempo: Inspect-Adapt. Se occorre, c'è spazio per i cambi. 
Finisce la partita, ci si ritrova il martedì per una sana retrospettiva e per preparare il prossimo incontro.

Ecco, questo è Scrum. Questa è una metafora che meglio descrive le dinamiche e lo spirito di Scrum agli italiani. In fin dei conti... quanti di noi sanno veramente cosa accade durante una mischia di rugby ? Noi, siamo cresciuti col pallone... La metafora del gioco del calcio è probabilmente più efficace per noi.
Non è un caso che se al lavoro trovi un "compagno di fede" (calcistica, ovviamente) hai un rapporto diverso.

Un team è una squadra. Esattamente come una squadra di calcio. Si gioca solo per vincere, anche se la nostra competizione è sul mercato.

Alla fine dei miei incontri con i team, leggevo negli occhi delle persone la voglia di giocare con uno spirito diverso, rinnovato.
Ma avevo parlato di calcio, del corner. Non della mischia del rugby.

E il middle-management ? Se gli parli di calcio, ti capiscono meglio. Capiscono che c'è una forte disciplina. Sparisce il  concetto della "mischia" come qualcosa fuori controllo. Del resto, un gol su mischia, è quasi un gol ottenuto per caso. Anche gli avversari tendono a sminuirne il valore parlando di "gollonzo".

Ed è per questo che a volte preferisco parlare di calcio e non di rugby. Usando questa metafora, ottengo un altro effetto. La mia comunicazione risulta più efficace.

Per questo, quando spiego Scrum, non parlo di "mischia" ma di "corner". 
Provateci !

13 Tips per un Daily Scrum efficace

Il Daily Scrum è un meeting quotidiano, della durata massima di 15 minuti. Rappresenta l'opportunità del team per sincronizzare il proprio lavoro e per evidenziare impedimenti / ostacoli.

Questo meeting avviene con una formula molto efficace, che prevede che ogni team member risponda a tre semplici domande:

1) cosa sono riuscito a conseguire dall'ultimo meeting ?
2) cosa riuscirò a completare prima del prossimo meeting ?
3) quali ostacoli / impedimenti ho nel percorso ?

Fin qui tutto bene. Questo è quanto recita lo scrum primer. Cerchiamo ora di capire cosa effettivamente vuole ottenere questo meeting.

In un mio vecchio post, parlai della matrice di Stacey, in cui veniva evidenziato che i progetti software sono tipicamente concentrati nella regione "Complex" del piano. Da qui, l'esigenza di un approccio basato sul concetto della retroazione (inspect-adapt) che scrum implementa.

I tre "scrum pillars" sono infatti "transparency-inspect-adapt". Questo meeting attua proprio questo concetto su una scala di tempi quotidiana. E' quindi importante che ci sia trasparenza quando si risponde alla prima domanda.
In molti team poco preparati a Scrum, questo meeting viene bistrattato e scambiato con uno status meeting in cui si fa un report delle attività allo scrum master. Grave errore, spesso dovuto ad uno scrum master che non riesce ad essere efficace nell'insegnamento dello scrum al proprio team.

Ecco qualche consiglio per un Daily Scrum più efficace.

1) Prima di tutto, lo scrum master deve insegnare al team cosa è un daily scrum, a cosa serve. Poi deve verificare che i team member abbiano effettivamente riscontrato che si tratta di un loro momento irrinunciabile di pianificazione e coordinamento

2) Lo scrum master dovrebbe evitare di suonare l'adunata per richiamare a sé i team member (finiranno per odiarlo). Tutti conoscono l'orario ed il luogo. Ci si reca al meeting point, tipicamente nel luogo in cui c'è la board, e si comincia. Se i team member non si alzano, lo scrum master si alza in silenzio ed attende l'arrivo del team. Ci sarà spazio, nella retrospettiva, per capire e per sottolineare ai team member la relazione causa-effetto tra un daily scrum insano e, appunto, gli effetti negativi sul coordinamento e sulla pianificazione delle attività.

3) Una volta che i team member cominciano, lo scrum master si allontana leggermente, facendo sì che il meeting sia condotto dal team.

4) Allo scadere del 15° minuto, lo scrum master scioglie l'incontro.

5) Quando un team è in fase di apprendimento, lo scrum master è presente e spiega le fasi, correggendo gli errori. Superata questa fase, lo scrum master fa un passo indietro: la sua presenza non è più necessaria. Un team sano ha poco bisogno dello scrum master. E' il meeting dei team member.

6) Ogni team member esprime il proprio daily commitment. Tutti sapranno cosa aspettarsi per il giorno dopo.

7) Nell'esprimere il commitment, è sempre importante minimizzare il numero di task in progress e massimizzare quello di task completi (nota: questo concetto proviene dal lean). Meglio avere 5 task completi anzichè 10 in progress.

8) Attenzione ai task "in progress" da tanto tempo. Sono indice di un "malfunzionamento".

9) Estrema attenzione alla domanda: "quali ostacoli / impedimenti ho nel percorso ?". Lo scrum master aiuta il team per la loro rimozione.

10) Quando un team member parla, tutti gli altri lo seguono con estrema attenzione, realizzando un contatto visivo con chi parla. 

11) Mike Cohn suggerisce: lo scrum master eviti di prendere appunti durante il meeting. I team member verrebbero distratti dalla curiosità.

12) Lo scrum master, dopo la fine del meeting può "offrire" al team le proprie impressioni per migliorare l'efficacia del team.

13) Evitare la presenza dei manager. Abbasserebbe il livello di trasparenza e lascerebbe esprimere commitment poco realistici.

Questi sono alcuni consigli, ma ogni team ha la possibilità di darsi un proprio stile, un proprio set di regole.

Agile vs Lean ? ...ma che differenza fa ? (Parte 2)

Nella prima parte di questo post, abbiamo affrontato i principi del Lean e ci siamo concentrati sui waste (gli sprechi).  In questa seconda parte entriamo nel mondo del software e vediamo come e se questi waste trovano un riscontro.

Mary e Tom Poppendieck, nel loro best seller "Implementing lean software development",  hanno proposto una utile corrispondenza tra i sette sprechi del manufactoring e quelli del software.

Manufactoring	Software Development
Inventory	Partially Done Work
Over Production	Extra Features
Over Processing	Relearning
Transportation	Handoffs
Motion	Task Switching
Waiting	Delays
Defects	Defects

La prima colonna di questa tabellina è proprio quella che abbiamo approfondito nella prima parte.
Qui ci concentriamo sulla seconda.

Partially Done Work. Nello sviluppo del software l'Inventory è tutto ciò che non è completo, non deployato dal cliente, ma non solo. Alcuni esempi: requisiti o design che non sono stati implementati, codice non sincronizzato (ovvero il codice che si trova nell'area privata dello sviluppatore, branch che devono essere portati in merge con gli altri), codice non testato o non documentato (anche se idealmente il codice migliore è quello che si auto-documenta !). 
E' interessante evidenziare che, in un progetto gestito con la classica metodologia waterfall, il work-in-progress (WIP)  aumenta pericolosamente con il tempo, esponendo, l'azienda che lo implementa, a rischi davvero importanti.
Il grafico che segue riassume una ricerca di SolutionsIQ.com , in cui è possibile osservare come il WIP aumenta con le classiche fasi, in un progetto waterfall.

Nelle metodologie agili, la riduzione del WIP viene indirizzata attraverso l'organizzazione del lavoro in iterazioni che rilasiciano progressivamente, incrementi di prodotto potenzialmente vendibili (PSPI). Gli effetti di questo approccio sono evidenziati nel seguente grafico.

Ma non lasciamoci ingannare dai cicli che possono somigliare a micro-waterfall. Sono solo indicativi. L'idea è che ogni iterazione si conclude con un rilascio (R1,...R7) di valore per il cliente.

Extra Features. Si tratta delle funzionalità disponibili ma mai (o raramente) usate dai clienti che, appunto, non ne hanno effettivo bisogno. Viste le implicazioni, si tratta di uno dei peggiori sprechi nel software. Autorevoli ricerche asseriscono che l' 80% dei benefici di un software vengono realizzati dal 20% delle sue feature. Jim Johnson, Chairman di Standish Group, riportò, alla Third International Conference on Extreme Programming, che il 64% delle feature del software sono raramente o mai usate.
Questo punto però merita una riflessione. Potremmo dire che le feature le chiede il cliente e quindi noi non possiamo farci nulla. In effetti, nelle nostre tipiche dinamiche di contrattazione cliente-fornitore accade che i contenuti vengano contrattualizzati all'inizio e, lasciatemi dire, "blindati" con tanto di penali.
Per un cliente, la fase iniziale di contrattazione è probabilmente l'unica finestra di opportunità che consente di chiedere feature a "costo ragionevole", a meno di non entrare, in futuro, in un tunnel di change management, dove una feature potrebbe implicare una serie di costi inattesi e non sostenibili. Un cliente, nel dubbio, ti chiede tutto ciò che gli viene in mente all'inizio, anche se non userà mai quelle feature.
Credo che un modo per indirizzare queste dinamiche sia quello di instaurare una diversa relazione contrattuale con il cliente.
Qui parlo di "cliente" in senso lato. Questa dinamica negativa si rinnova anche all'interno delle stesse aziende, tra i gruppi Sales / Marketing e la R&D. A tal proposito, il mio amico Craig Larman, nei suoi libri, parla della necessità di uno shift da Competitive Game a Collaborative Game. Vi invito a dare un'occhiata.

Relearning. Ultimamente, nel mio ambiente di lavoro, alcuni team hanno affrontato una serie di problematiche abbastanza complesse. Durante la retrospettiva, ho chiesto: "come avete fatto tesoro dell'esperienza accumulata ?".  Ecco... qui ho avuto le risposte più disparate. Ho osservato attentamente le persone ed ho trovato diversi modi di "knowledge management". Il sistemista ha, tipicamente, un suo file "txt" con i log dei comandi, lo sviluppatore "se lo ricorda" (e solo talvolta introduce un nuovo test case), l'hardwarista ha la lista di tutti gli interventi, etc. Ho inoltre osservato che, documentare tutte le scelte/azioni risolutive, crea un volume di documentazione che nessuno leggerà mai. Bene: il relearning è proprio l'effort che verrà nuovamente (e quindi è un waste) speso in futuro per riscoprire le cose che, in qualche modo, erano già noto.
In generale, consiglio sempre di anticipare e gestire i problemi via TDD. In caso di nuove anomalie, aggiungere casi di test. I Test Case custodiscono, documentano la conoscenza. Un buon set di test case garantisce che quel problema non accadrà più. 


Handoffs. All'interno dei vari "passaggi di consegne" tra persone che lavorano in gruppi diversi, si cela uno degli sprechi più evidenti. Ad esempio: il passaggio di un documento di requisiti dal gruppo di analisti a quello di sviluppatori. Oppure la consegna degli artifatti dagli sviluppatori ai tester.
Mi viene in mente una vignetta che trovo spesso negli uffici dei colleghi. Eccola:

Carina, no ? E' simpatica e rende l'idea. E se la troviamo in giro, vuol dire che ne siamo consapevoli. Peccato che le nostre aziende sono spesso organizzate in gruppi che - by design - contribuiscono ad alimentare questo fenomeno negativo. E' evidente che questo tipo di waste è legato alla gestione della conoscenza nelle varie fasi del progetto.
In generale l'handoff avviene con la consegna di artifatti (e responsabilità) che descrivono una rappresentazione solo parziale della realtà. Fatta 100 la quantità di informazioni da passare, esistono ricerche che dimostrano che, ad ogni passaggio, si perde almeno il 50% delle informazioni utili.
Se poi pensiamo che in un contesto waterfall ci possono essere 4 fasi: requirements, design, code, test, allora si capisce che nella fase di test si è perso oltre il 90% delle informazioni utili...

Per questa ragione, nelle metodologie agili, il tema viene indirizzato con la creazione di team cross-funzionali che seguono tutte le fasi (requirement-2-deploy), con feedback frequenti e miglioramento continuo (Kaizen).

Task Switching. E' probabilmente la cosa che gli sviluppatori, ma non solo, odiano di più. Essere interrotti e passare su un altro task, probabilmente (spero) a maggiore priorità. Il task switching introduce un tempo di cambio di contesto che, all'aumentare del numero di task, risulta essere superiore al tempo richiesto per la soluzione di un task. Per non parlare degli effetti collaterali, misurabili in termini di bug, che questa mancata focalizzazione e concentrazione comporta. E' curioso notare che spesso i project manager "tradizionali", spinti dal miraggio dell'ottimizzazione dell'uso delle risorse e relativa pianificazione, contribuiscono ad alimentare una dinamica negativa ed al tempo stesso così semplice da capire. Mi è capitato di leggere report che dicono che una persona segue un'attività al 30%, una al 10%, una al 50% ed un'altra con "priorità background". Cosa ci aspettiamo ? :)
Qualcuno dirà che a volte si tratta di emergenze provenienti dall'ambiente di produzione. Ebbene, ci sono veramente diversi modi per indirizzare e gestire questi fenomeni. Anche a tal proposito ho trovato molto utili i consigli che il mio caro amico Craig Larman riporta nei suoi 2 libri.

Delays. Le attese. Quelle tipiche sono: ho bisogno della disponibilità di una persona che lavora in un altro team. Sono in attesa di informazioni / indicazioni, etc. Cosa fa una persona in attesa ? Cerca di risolvere da sola, passa su un altro task (!), naviga :) .Nessuna di queste dinamiche è positiva. Ancora una volta, le attese vengono diminuite grazie ai team cross-funzionali e colocati. Un ruolo fondamentale è giocato dalla qualità del PBR (Product Backlog Refinement) che intercetta anche le necessità dei team in termini di competenze, impianti, materiali.

Defects. Questa è facile. E' naturale associare il concetto di spreco alla difettosità. Un team agile ha il focus proprio su questo tema. Il pane quotidiano di un team agile è il Test Driven Development. Per questa ragione, un team agile ha un numero di difettosità tipicamente basso. Ma può accadere che i difetti possano essere rilevati in produzione. Quando capita, il team reagisce creando un nuovo test case che, accoppiato agli sviluppi, scongiurerà il ripetersi di quel particolare evento. Un team agile progetta il prodotto software attraverso la progettazione dei test case di accettazione.

Abbiamo visto un parallelo tra il mondo del Lean e quello dell'Agile. Ci siamo limitati ai sette waste e potremmo già spingerci a concludere che la filosofia Agile è praticamente basata sugli stessi principi del Lean, che è nato prima.

Charlie Rudd, CEO di SolutionsIQ (azienda attiva nella formazione e consulenza in campo agile)  afferma: "[...] when one explains how iterative development reduces WIP, they are describing how the principle of (Lean) waste reduction is implemented in an Agile practice".

 

Ed ancora: "[...] Since Agile and Lean share many of the same principles, we can say they share a common philosophy regarding the management of people and investments and how best to thrive in today’s business environment."

Lean ed Agile condividono dunque gli stessi principi. Discorso a parte meritano le applicazioni dell'agile, intese come i vari framework che implementano tali princìpi (es. Scrum, XP, ...). Si tratta, appunto, applicazioni pratiche.

Spero di aver contributo a fare un po' di chiarezza su queste tematiche.

il (buon ?) senso comune

Spesso si dice che l'agile sia basato sul senso comune. Certe cose appaiono talmente ovvie che, di recente, in un seminario che trattava tematiche lean ed agili, ho sentito una interessante definizione: "l'agile è buon senso strutturato". Ma siamo sicuri ?

Vediamo allora che ne dice Einstein: "Il senso comune è una collezione di pregiudizi acquisiti a partire dai 18 anni di età".  Questo pensiero potrebbe non essere tanto "azzeccato" all'agile. Come dicono le Iene, "andiamo a controllare !"  :)

Partiamo da lontano. Andiamo a vedere cosa disse, a tal proposito, Taiichi Ohno, il padre del Toyota Production System, nel suo "Workplace Management".
"[...]  idee sbagliate spesso si trasformano in ciò che chiamiamo senso comune. E quando capita, si entra in dibattiti senza fine. Le parti cominciano a discutere senza mai compiere passi avanti.
Per questa ragione, ho passato un periodo in cui dicevo alle persone di fare un passo fuori dal senso comune e pensare andando oltre il senso comune.
Nel senso comune ci sono cose che riteniamo corrette grazie alle nostre idee ed ai nostri concetti sbagliati. Inoltre, probabilmente, un motivo per il quale noi facciamo qualcosa di comunemente sensato è che non vediamo particolari pro facendo le cose in un modo, ma neanche tanti contro..... noi siamo umani, quindi continuiamo ad agire in un modo, credendo che sia quello migliore. O, probabilmente, pensiamo che non sia il modo migliore ma facciamo ugualmente così perchè, appunto, guidati dal senso comune, pensiamo di  "non poter fare di più, le cose sono semplicemente così". 

Tornando al software, cito una frase di Craig Larman , a proposito dello sviluppo dei prodotti, secondo cui  "common sense is not so reliable when trying to understanding non linear systems- such as large-scale product development."

E' quindi interessante capire che ci sono ambiti in cui il nostro "senso comune" aumenta i problemi perché si basa sulla nostra percezione (cosiddetta locale) e quindi non sul SISTEMA GLOBALE complesso che è il nostro ambiente di lavoro. In altre parole le nostre decisioni conducono ad una ottimizzazione locale del sistema che vorremmo migliorare. Tali scelte non tengono conto di un effetto collaterale che provoca un degrado complessivo delle prestazioni del sistema stesso.

Queste considerazioni sono talmente evidenti da essere formalizzate in una legge:

Legge di Weinberg-Brooks: la causa predominante di problemi riscontrati nei progetti software è rappresentata dalle azioni sbagliate, prese da un management che ha basato le proprie decisioni su modelli di sistema ed assunzioni non corretti.

I modelli cui questa legge si riferisce sono proprio i nostri modelli mentali che rappresentano la realtà che ci circonda in un modo assolutamente personale.

La ricerca ha infatti mostrato che, assegnando ai decision maker modelli dinamici di business, e chiedendo ad essi di realizzare un improvement di performace, generalmente si peggiorano le cose. La maggior parte delle persone evidenzia una deblezza su come migliorare i sistemi. Generalmente si applica, in maniera scorretta, il "senso comune" ed un quick-fix che non realizza un improvement di sistema. 

Tutto quello che ho descritto va sotto il nome di System Thinking.  Peter Senge  ha scritto un classico (The Fifth Discipline) in cui evidenzia la necessità di una leadership che applichi il System Thinking.  Senge ha riassunto il suo pensiero nelle sue 11 leggi:

1. Today's problems come from yesterday's "solutions."
2. The harder you push, the harder the system pushes back.
3. Behavior grows better before it grows worse.
4. The easy way out usually leads back in.
5. The cure can be worse than the disease.
6. Faster is slower.
7. Cause and effect are not closely related in time and space.
8. Small changes can produce big results...but the areas of highest leverage are often the least obvious.
9. You can have your cake and eat it too ---but not all at once.
10. Dividing an elephant in half does not produce two small elephants.
11. There is no blame.

Parlando di System Thinking è doveroso citare  W.E.Deming  che è probabilmente il più famoso system thinker ed esperto di qualità. Nel suo "Out of the Crisis", suggerisce i famosi 14 punti, sui quali tornerò presto, in quanto meritano un discorso separato. Per questo non li anticipo qui.

Dopo la teoria, andiamo con la pratica.

... quando vogliamo fare una cosa basandoci sul senso comune... beh, pensiamoci prima un attimino. Rischiamo di degradare ulteriormente le cose. A proposito, capita spessissimo quando siamo nervosi, sotto stress, impulsivi !

Nella mia esperienza professionale, ho ahimé incontrato diversi manager dotati di "senso comune". Il tema è certamente culturale, ma anche di competenze.

Ho citato un po' di spunti e fonti autorevoli. Credo che in un momento di cambiamenti sempre più rapidi, come quello che stiamo vivendo, sia davvero necessario approfondire questi temi che consentono di sviluppare gli occhi per le dinamiche del nostro sistema.

Per gestire cambiamento non basta il senso comune.

Agile vs Lean ? ...ma che differenza fa ? (Parte 1)

Alcune persone (direi troppe) si pongono il problema della differenza tra Lean ed Agile.

Entriamo un po' dentro la questione e cerchiamo di capire cosa c'è dietro. In questa prima parte cerco di spiegare brevemente il Lean, con il suo significato e le sue origini.

Il termine "lean" è diventato popolare nei primi anni 90, grazie ad una pubblicazione che descrive l'approccio di Toyota alla fabbricazione delle automobili. Si tratta del famosissimo libro "The Machine That Changed the World" che descrive il Toyota Production System (TPS).

L'approccio manifatturiero di Toyota, noto come "Lean Production", ed implementato da Taiichi Ohno, esprimeva un modo di realizzare le autovetture in netta contrapposizione con quello della produzione di massa ("mass production").
L'obiettivo di Toyota era: ottenere la migliore qualità, abbassando i costi e di tempi di realizzazione delle autovetture attraverso l'eliminazione degli sprechi (waste).

Ma partiamo dall'inzio. Fine della seconda guerra mondiale. Kiichiro Toyoda lancia una importante sfida: raggiungere i livelli di produzione automobilitstica toccati in America. Ma senza adottare il modello di produzione di massa americano (introdotto da Ford), che consisteva nella produzione di migliaia di parti identiche per guadagnare sulle economie di scala. Purtroppo però, in Giappone, in quel periodo, c'era difficile reperibilità di materia prima accompagnata ad alta variabilità della domanda. Semplicemente, le economie di scala non erano disponibili.

La vision di Kiichiro Toyoda era quella del "just-in-time". Le parti dovevano essere realizzate immediatamente prima di giungere alla linea di assemblaggio che le richiedeva. Non si passava per magazzini di stoccaggio.  Fu necessario diverso tempo per realizzare questa vision ma, nel 1962, dieci anni dopo la morte di Kiichiro Toyoda, la sua azienda aveva adottato il Toyota Production System.

Taiichi Ohno manager della Toyota, raccolse la sfida lanciata da Kiichiro Toyoda e sviluppò quello che sarebbe stato conosciuto come il Toyota Production System.
Nel suo libro, Toyota Production System,  (inizialmente pubblicato nel 1978, poi tradotto in inglese solo nel 1988) Taiichi Ohno definisce il TPS come un "sistema per eliminare gli sprechi". Spiega inoltre che la filosofia si fonda su 2 pilastri:

1) Just-in-time: in accordo con la vision di Kiichiro Toyoda, tutti i pezzi necessari per realizzare le automobili dovevano essere realizzati immediatamente prima del momento in cui se ne avesse effettiva necessità alla linea di assemblaggio. Questo implicava da un lato l'assenza di magazzini in cui potessero conservare scorte di varie parti. Dall'altro, la necessità di partnership strategiche con i fornitori, in modo da ottimizzare i loro flussi produttivi in base agli ordini di autovetture.
Naturalmente, l'assenza di magazzini si traduceva in un enorme risparmio per Toyota. Ma è importante notare che questo concetto era complentamente contro tutti gli insegnamenti convenzionali dell'epoca.

2) Jidoka, anche noto come Autonomation. Il lavoro viene organizzato in modo che, in caso di qualsiasi anomalia,  la linea produttiva si blocca fino a quando non viene identificata e risolta la causa dell'anomalia. Per questo motivo, il "jidoka", noto anche come "stop-the-line", previene la produzione di prodotti difettosi, elimina la sovraproduzione e focalizza l'attenzione sul problema verificatosi, per assicurarsi che non accada più. 

Questi due pilastri vengnono spesso idealizzati come struttura portante di una casa, la TPS House, come nella seguente illustrazione presa in prestito dal Lean Lexicon:

Va detto che esistono diverse versioni di questa rappresentazione grafica (Google per credere). Naturalmente si equivalgono, ma io credo che la rappresentazione più felice sia quella riportata nel noto libro di Craig Larman e Bas Vodde, Scaling Lean & Agile Development. Si tratta infatti di una rappresentazione probabilmente più moderna ed esaustiva che riporto qui:

L'obiettivo (il Goal posto alla sommità)  si raggiunge attraverso l'implementazione di quanto riportato nel corpo della casa.
In particolare, eliminando i "waste".  Nel Lean, vengono identificati sette principali sorgenti di waste. Vediamoli:

1. Inventory. Include tutte le parti ed i materiali acquistati ed in attesa di essere utilizzati. Include anche il  work-in-process (WIP). WIP è qualsiasi cosa che, avendo richiesto una lavorazione, non è ancora pronta per la vendita.  Inventory e WIP generano sprechi per definizione in quanto richiedono risorse che non sono tuttavia in grado di generare un ritorno. Inoltre, maggiore è l'inventory, maggiore è il rischio di perdita (es. dovuta ad obsolescenza, deperimento,..).
2. Motion. Corrisponde al movimento di persone e/o sistemi in eccesso rispetto a quanto strettamente necessario e che non contribuisce alla generazione di valore.  
3. Waiting. L'attesa è un ritardo tra step successivi di produzione. Esempio:  se un prodotto viene assemblato, il tempo tra l'assemblaggio e l'imballaggio rappresenta il wase di waiting.
4. Over-production. E' la produzione che viene realizzata oltre la domanda. Ad esempio, prodotti vendibili, in attesa presso un magazzino, rappresentano una over-production. Come nel caso del WIP,  l'over-production aumenta il rischio di obsolescenza.
5. Over-processing. Rappresenta i processi in eccesso rispetto a quanto è effettivamente richiesto. Ad esempio, lucidare una superficie un minuto in più rispetto a quanto necessario, rappresenta un minuto di waste di processo.  Over-processing consuma tempo e risorse senza aggiungere alcun valore. Può danneggiare o rendere il prodotto finale meno valido. Inoltre può abbreviare la vita dei tool di processo.  Il waste di waiting spesso conduce al waste di over-processing.  Occupare il proprio tempo con "lavoro occupato" può ridurre il proprio disagio emotivo di attesa, favorendo l'illusione che almeno si stia facendo qualcosa di "produttivo". In realtà non si sta aggiungendo valore. Si stanno peggiorando le cose.
6. Transport. Tale waste è il movimento di beni che non è strettamente necessario per eseguire una lavorazione. Include il possibile danneggiamento che possono subire i beni trasportati. 
7. Defects. Il costo dei difetti si riferisce al costo della loro ricerca oltre al costo della riparazione.

Bene, non voglio dilungarmi ulteriormente sul TPS, non era questo lo scopo dell'articolo.
Il messaggio finale che voglio dare è: il pensiero lean (Lean Thinking) è stato inventato in Toyota ed basato prevalentemente sui principi esposti.

Nella seconda parte dell'articolo vedremo cosa c'è alla base dell'agile e tireremo le dovute somme....
A presto !

______________
riferimenti:
Mary and Tom Poppendieck - Implementing Lean Software Development
Charlie Rudd: White paper: When You're Agile, You Get Lean
Craig Larman, Bas Vodde - Scaling Lean & Agile Development.

The Scrum Office.... Reloaded !

Ufff.... volevo scrivere tante cose nel mio blog ed invece .... quasi un anno di silenzio totale !
Avevo chiuso il mio precedente post scrivendo "Per non dimenticare!". Peccato che ho dimenticato di scriverci qualcosa. E questo è poco agile :)

Oggi ho incontrato il mio amico Pasquale. Mi fa: "dovresti avere un tuo blog".
Ed io: "ce l'ho! .... ma non lo uso..."
E' rimasto un "vorrei ma non posso", non ho tempo.... il lavoro, gli impegni, insomma.... non ce la faccio :(

Ma poi mi sono detto... perché ? E rieccomi armato di buone intenzioni. E allora si ricomincia.

Audience: Italia. Il mondo è pieno di roba agile, ma il mio primo pensiero è: Agile in Italia.
Ho fondato una community italiana in ScrumAlliance.org proprio perché qui in Italia non è come altrove.  Le mie esperienze sono contestualizzate nella nostra cultura. Ciò che è vero qui potrebbe (si fa per dire) non funzionare altrove. E viceversa.

L'agile as-you-read è molto pericoloso.... Ho visto tanti falsi agili (!) in Italia. Cose veramente strane, danni spesso arrecati da persone che, in buona fede, leggono ed applicano. Poi mi sento dire che "qui da noi l'agile non funziona, ma ci abbiamo provato...".

Questo è il motivo che mi spinge a rimettere le mani in questo diario pieno di polvere e fermo alla copertina. Metto in comune un po' di esperienze e procediamo con un "agile-as-you-go" (mi ricorda un po' il pay-as-you-go del cloud !)

Ho aggiunto una serie di "task" alla mia board. Si chiamano Pasquale. Hanno un form factor riconoscibile ed un accento familiare.

Let's go !