Lean e Kanban

Venerdì scorso ho partecipato all’Italian Agile Day che si è svolto a Genova. Sono stati toccati molti argomenti: agile, scrum, xp, lean, kanban, complessità, soft-skills.

Nel viaggio di ritorno verso Monza, ho cercato di mettere assieme le tessere del puzzle, sparse quà e là nella testa. Questo post è la prima tessera.

---

La conferenza di Genova sulle tematiche agili è stata una gran giornata.

Otto ore immerso nel mondo dell’agilità e del project management: avete presente quando sentite di trovarvi nel posto giusto, al momento giusto! Beh, professionalmente parlando, ho provato qualcosa di molto simile.

Ho partecipato a diverse sessioni, tutte interessanti. Ecco la prima che ha stuzzicato la mia curiosità: “Lean e Kanban: La nuova rivoluzione Agile di Claudio Perrone”.

Lean

Questo è un approccio sviluppato in Toyota a partire dal 1948 (http://en.wikipedia.org/wiki/Lean_manufacturing), ma con ottimi riscontri anche in diversi altri settori come i servizi, il marketing e perché no nello sviluppo software (http://en.wikipedia.org/wiki/Lean_software_development).

Punta tutto sul concetto di ottimizzazione, miglioramento continuo ed eliminazione degli sprechi.

I concetti fondamentali possono essere così riassunti:

• Sistemi Just-In-Time (JIT): in campo industriale riferisce il modo di organizzare la filiera produttiva. Non più un approccio di produzione e di stoccaggio dei prodotti in attesa di essere posti sul mercato (PUSH), quanto piuttosto calibrare l’intera catena produttiva sulla regola “Use one, make one” che significa che un prodotto è stato richiesto/usato ed uno nuovo viene prodotto.
• Approccio PULL: questo approccio punta alla soddisfazione della regola “Use one, make one”, creando un sistema produttivo che viene letterarmente “tirato” dal mercato. Lean attraverso Kanban, rende possibile questa “magia”.
• Eliminazione delle inefficienze: i processi sono sottoposti a revisioni cicliche che puntano al migliramento in termini di aumento della velocità di produzione, diminuzione dei tempi di attesa, eliminazione di eventuali sprechi di risorse.
• Miglioramento della qualità: in ambito di miglioramento continuo, la qualità è un fattore tenuto in grossissima considerazione, certificata da processi Six-Sigma (http://it.wikipedia.org/wiki/Six_Sigma).

Kanban

Kanban deriva dalla lingua giapponese e significa cartellino. In ambito lean è il cartellino che identifica un determinato lotto che viene lavorato in un determinato ciclo produttivo.

Ogni linea produttiva riceve in ingresso un lotto da lavorare, a quel lotto verrà assegnato uno dei cartellini disponibili. A fine lavorazione, quel cartellino verrà rimosso e reso disponibile per il prossimo lotto in coda all’entrata.

Il settore successivo, quindi, tirerà verso di sé il lotto appena uscito per procedere alla sua lavorazione, sempre assegnando un nuovo cartellino all’entrata e rimuovendolo all’uscita.

L’intero ciclo di produzione termina con l’uscita del prodotto, anch’esso, guarda il caso, pronto per essere nuovamente tirato, ma questa volta direttamente dal mercato.

Il numero di cartellini disponibili per ogni linea produttiva, rappresenta la sua capacità di lavorazione.

Questo modo di organizzare la produzione ha il pregio di evidenziare sin da subito eventuali inefficienze a carico di singoli settori, di fatto evidenziandoli come colli di bottiglia e sui quali rivolgere immediatamente le analisi di continuo migliramento del processo.

In ambito agile, Kanban viene utilizzato per raggiungere gli obiettivi primari espressi sopra: ridurre gli sprechi, aumentare la qualità, ridurre i tempi di produzione, eliminare i problemi. Ma come si fa?

Ecco le regole fondamentali:

• visualizza il flusso di lavoro necessario per arrivare alla produzione del prodotto/servizio richiesto
• suddividi quel flusso, in fasi produttive
• assegna un tempo di esecuzione ad ogni fase
• limita il work in process (WIP) di ogni fase: elimina il superfluo, esegui solo il lavoro necessario, ottimizza i tempi di esecuzione, affina il processo e facilita le interazioni tra sistemi e persone
• quota il numero di cartellini gestiti dalla singola fase. In sostanza: in base al tempo assegnato, al tipo di lavoro eseguito, all’efficienza del ciclo produttivo dell’area interessata, assegna il numero di “lotti” lavorabili da quell’area in quella parte di tempo

Ora inizia a “nutrire” la catena passando alla prima “linea produttiva” il numero di lotti da lavorare e stai guardare cosa accade.

Come è andata? Qualcosa si è inceppato?  Dove? In quel linea produttiva?

E’ stato sovra-stimato il numero di cartellini/lotti lavorabili?

E’ stato sotto-stimato il tempo assegnato per la lavorazione?

Si procede a rilento per difetti riscontrati a carico di altre linee di produzione precedenti?

Bene, le risposte alle domande sopra vi aiuteranno nel vostro lavoro di miglioramento continuo dei processi.

Ah, dimenticavo: i giapponesi ci dicono che sebbene processo sia stato appena migliorato, dovreste ripensarlo, nuovamente, in ottica di riduzione di tempi, costi, problemi e inefficienze…continuos process improvement!

Agile day is coming

Venerdì e l’Agile Day finalmente si avvicinano!

I lavori si apriranno alle 9.30 e poi via, fino alle 18 a parlare di tematiche agili (ma a che ora dovrò partire da Monza….boh!). Ecco quanto ho scelto tra le diverse sessioni disponibili.

11:00 12:00: Sala 1

Note to managers: IT is different, get over it – Andrea Provaglio

 12:10 12:55: Sala 2

Complexity vs Lean, the Big Showdown – Jurgen Appelo

 14:30 15:15: Sala 4

Pronti… partenza… Sprint! Bootstrap di un team Scrum – Giuseppe De Simone e Mauro Bagnato

 15:25 16:25: Sala 1

Lean e Kanban: La nuova rivoluzione Agile  – Claudio Perrone

 16:35 17:35: Sala 2

Agilità come evoluzione sistemica – Pierluigi Pugliese

SCRUM & Large Projects

Come conciliare SCRUM e grossi progetti?

---

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

---

SCRUM? Let’s do it! (4^ parte)

Nei precedenti tre post abbiamo toccato tutte le tappe del tour di SCRUM. Certo non abbiamo raggiunto un livello di dettaglio eccessivo, per quello dovremmo organizzare sessioni di formazione specifiche però gli ingredienti per cominciare a “sporcarci le mani” ci sono tutti e sono sul tavolo.
E allora, cosa aspettate!

---

Portare SCRUM in azienda laddove SCRUM non fosse mai stato neanche nominato, non è cosa semplice. Però, con un pò di perseveranza, pazienza e “fede” si può fare (mi sento un pò Obama)!

Da dove cominciare? Da chi e con quali persone? Con quali strumenti e in che modo?

Beh, ecco cosa farei io se fossi nei vostri panni…

Innanzitutto riguardatevi tutti i precedenti post, connettetevi a http://www.scrumalliance.org/ e scaricatevi qualche guida da internet (ne troverete tante e parecchie sono fatte da persone certificate) e, soprattutto, studiate.

Non fermatevi alle solite guide “SCRUM for dummies”, una volta presa confidenza cercate anche informazioni estese e dettagliate sulla metodologie e, perché no, anche riguardo ad eventuali problemi o difficoltà che il metodo potrebbe portare con sé.

Vi aiuterà a farvi un’opinione critica e equilibrata.

Fatto questo è necessario prepararsi alla negoziazione.

Avrete bisogno di grosse doti di persuasione e di comunicazione perché diverse persone in azienda saranno restie a cambiare il loro modo di lavorare ormai “conclamato”.

SWOT Analysis

Uno degli strumenti più versatili che conosca, anche per casi come questo, è proprio la SWOT Analysis.

La si può usare per qualsiasi tematica: valutazione delle caratteristiche dei membri del team, come strumento di confronto e verifica tra progetti quando si deve decidere quale fare partire o ancora quando stiamo valutando una caratteristica del prodotto/servizio in fase di sviluppo e vogliamo ragionare sui rischi e benefici.

Come detto, dobbiamo prepararci alla negoziazione e, a tale scopo, è necessario procedere allo sviluppo di una strategia. Strategia, che potrebbe magicamente prendere corpo dopo aver svolto un’approfondita SWOT analysis sull’agomento.

Ricordate i quattro quadranti Strenght, Weakness, Opportunities and Threats?

Strenght: elencate quali caratteristiche innovative, punti di forza in genere, avete riscontrato nel framework. Concentratevi su quelli che avrebbero maggiore valore/impatto nel vostro contesto aziendale (ricordate Pareto e la legge 80/20?).

Weakness: ora tocca ai punti deboli. Elencate tutte quelle situazioni o caratteristiche, che difficilmente si sposano con il contesto aziendale in cui vi trovate.

Opportunities: qui elencate i vantaggi, le soluzioni, le opportunità che potrebbero aprirsi in caso riusciate a instaurare SCRUM. Un consiglio: quando parlerete con il management non dovrete perdere tempo eccessivo sui dettagli tecnici i metodologici; preparatevi piuttosto un’analisi che riguardi il ROI che vi aspettate sui prossimi progetti….questo aiuterà non poco a convincerli.

Threats: siamo arrivati alle note dolenti. Partite, innanzitutto, con l’essere onesti con voi stessi: fate un brainstorming ed elencatele tutte (le note dolenti o minacce) e cercate di dare loro una priorità in termini di impatti negativi sui progetti. Dato che stiamo parlando appunto di minacce, ossia di eventi che potrebbero presentarsi (rischi), dovreste anche procedere ad una vera e propria analisi dei rischi, con tanto di analisi qualitativa e studio degli eventuali impatti sul progetto (su costi, tempi, qualità e obiettivi).

Ottimo!

Ora passate al prossimo punto, che vi ricorda quanto segue: non cedete alla tentazione di applicare solo alcune delle componenti di SCRUM e di accantonare quelle “difficili”.
Ricordate quanto detto nel 3° post? SCRUM non potrà darvi i benefici promessi se lo applicherete solo parzialmente.

Andate dal capo

Con queste convinzioni, forti della vostra cultura in materia e con una fiammante strategia architettata grazie alla SWOT, potrete indossate il vestito migliore e, facendo tesoro di eventuali insegnamenti PNL, andate dal capo.

 

La riunione dovrebbe essere suddivisa in due parti.

Nella prima parte puntate tutto sull’aspetto persuasivo. Nella seconda, potreste elencare come intendete procedere.

Ora tocca a voi: dovrete essere convincenti.

Raccontate quanto può fare SCRUM per la vostra azienda, fate in modo che la vostra passione sia contagiosa.

Mostrate i calcoli fatti intorno al ritorno degli investimenti e allo scenario temporale relativo.

Poi passate ad elencare i rischi ma, da bravi project manager, non mancate di elencarne anche le risposte in caso di accadimento. Se tra le vostre risposte avete previsto dei fondi da accantonare (contengency reserve) assicuratevi che questi siano comunque in qualche modo coperti, anche se parzialmente, dal ROI del progetto corrente o che andrete ad accumulare anche sugli altri.

Come e cosa fare?

Nella seconda parte mostrate come e cosa vorrete fare per arrivare a governare i progetti attraverso SCRUM.

Tenete in considerazione questi piccoli suggerimenti:

• Scelta di un progetto abbordabile
• Selezione delle persone “adatte” (Product Owner e team members)
• Sessioni di formazione mirate sull’argomento
• Scelta di un tool agile di project management
• Predisposizione della war room
• Sponsorship attiva del management
• Pieno commitment dei membri del team

 

(1) Il progetto selezionato non deve essere troppo rischioso; punta su: tecnologie conosciute, finestre temporali richieste non troppo stringenti, obiettivi e requirements chiari.

(2) Se possibile, scegli i membri del team più curiosi, meno “statici” e problematici: evita quelli che alla macchinetta del caffé si lamentano del capo che troppo pretende, dei colleghi che nulla capiscono, del lavoro che troppo annoia.

(3) Ora hai un team, lo devi formare…come fare? Dai un’occhiata agli spunti di formazione sotto riportati.

(4) Non è necessario avere a disposizione tool troppo complessi; ricorda che SCRUM è agile per sua stessa natura. Avrai solo a che fare con piani analitici snelli, fogli di excel, calendari di outlook, tabelle in Access. Ma se proprio vuoi meglio organizzarti, esistono diversi tool gratuiti o opensource. Oppure perché non usare  sharepoint services 3.0?

(5) Ora il team lo devi collocare nella stessa stanza/ufficio. Questa stanza dovrà essere isolata dagli altri uffici, avere spazio sufficiente sui muri, per appenderci alcune lavagne, la burndown chart e la sprint task board.

(6) Assicurati che lo sponsor del progetto che stai per fare partire sia completamente coinvolto e percepisca l’importanza dell’esperimento che state compiendo.

(7) Lavora molto sul team, crea una vision di team, di prodotto, di progetto e poi una vision anche per ciascuno sprint: che sia allo stesso momento sfidante e accattivante. Sfidante perché le persone danno il meglio di sé quando il loro talento e le loro energie sono ben impiegate, stimolate e occupate (attenzione però a instaurare ritmi lavorativi sostenibili!). Accattivante, non tanto in termini economici, quanto come valore personale di ritorno dall’esperienza e perché no, universalmente riconosciuto tra i colleghi, in azienda.

Spunti Formativi

Ecco alcuni degli argomenti formativi che affronto in casi come questo:

• Agile values
• Agile team values
• Team self organization
• Colocation
• Emersione dei problemi
• SCRUM artifacts
• SCRUM time boxes
• SCRUM roles
• SCRUM rules
• Agile estimations (planning poker e affinity estimating)
• Definizione di lavoro terminato (DONE) e come comportarsi in presenza di lavoro non terminato (WORK NOT DONE ACTIVITIES)

 

Evasi i punti sopra non rimane che cominciare.

Prova a partire con questa checklist.

• Verifica delle info analitiche di progetto a supporto
• Fissare l’orizzonte temporale analitico, questo scandirà i tempi dello sprint
• Fissare la durata degli sprint
• Stabilire le vision
• Scrivere le user stories
• Creare il product backlog
• Analizzare i rischi
• Assegnare le priorità alle feature del backlog
• Creare la release backlog
• Cominciare lo sprint
• Procedere allo sprint planning meeting
• Verificare le stime dei task a seguito della scomposizione
• Verificare tempistiche e decidere eventuali IN/OUT delle features
• Cominciare il lavoro
• Eseguire i daly meeting
• Aggiornare burndown chart e la sprint task board
• A chiusura dello sprint, effettuare review e retrospective meeting

 

Qualche annotazione finale

I lavori di preparazione allo SCRUM potrebbero anch’essi essere implementati con SCRUM.

Prevedi per quelle attività sprint corti, da 2 settimane; questo permette frequente controllo, possibilità ravvicinate di revisione dei processi e permette al team di farsi le ossa.

Esegui la prima volta almeno tre sprint prima di fare qualsiasi revisione al processo.

Con questo termino la saga “SCRUM”.

Spero vi abbia appassionato e convinto di praticarlo anche nelle vostre aziende.

Qualora voleste essere affiancati da un formatore o da un coach per fare lo start-up, non avete che da chiedere!

A presto e in bocca al lupo!

SCRUM (3^ parte)

Ci ho davvero preso gusto…..e ora vi tocca sciropparvi il terzo post consecutivo riguardante il più popolare framework di gestione agile dei progetti: SCRUM.

Vi siete persi le puntate precedenti? Ecco la prima ed ecco la seconda!

Oggi presenterò un riassunto di quanto detto precedentemente e poi via, testa bassa sulle regole,  ferree e importantissime, sulla comunicazione e sulle vision da istituire.

E allora, forza, registratevi e via di neuroni!

---

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

---

SCRUM (2^ parte)

Ecco la seconda parte della saga “SCRUM”.

Avevamo iniziato qui (http://www.emilianosoldipmp.info/2010/11/08/scrum-1-parte/) parlando in generale di SCRUM e di una delle sue componenti principali: gli artefatti.
Oggi parleremo di altre due componenti: time boxes e ruoli.

---

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

SCRUM (1^ parte)

In un post precedente, raccontavo di come poter conciliare realtà aziendali lontane da un modello di business prevalentemente orientato ai progetti (matrice debole), con le tematiche agili, tanto in voga in questi periodi.
Questo è il primo post di una piccola serie, in cui fornisco indicazioni rispetto a SCRUM: uno dei più utilizzati framework agili.  

---

Vorrei cominciare enunciando i diversi “perché” potresti, o dovresti,  decidere di utilizzare SCRUM per gestire i progetti nella tua azienda.  

• Perché non esiste un’analisi dettagliata del lavoro da eseguire
• Perché è necessario fornire al più presto al committente, valore di business, anche parziale, attraverso il prodotto rilasciato
• Perché i change di progetto potrebbero essere frequenti in rapporto alla volatilità del mercato di riferimento in cui si opera
• Perché la tecnologia utilizzata è innovativa o poco sperimentata
• Perché i rischi sono molto alti
• Perché è necessario ricevere feedback dagli utenti con buona frequenza

Ti ritrovi in qulcuno dei punti sopraccitati?  

Bene!  SCRUM potrebbe aiutarti a trovare le risposte giuste…SEGUIMIIIIIII!!  

 

Come funziona?

SCRUM suddivide il lavoro in tempi precisi, dà loro il nome di sprint e identifica una durata media di 2/4 settimane ognuno.  

Quando terminato, lo sprint permette di rilasciare in produzione un “pezzo di prodotto” funzionante, sin da subito utilizzabile dal committente.  Identifica ruoli che hanno perimetri di responsabilità ben definiti, chiari a tutti e regolamentati.

 Non necessita di analisi e piani di progetto “ultra-dettagliatissimi“. Solitamente SCRUM dedica a tali attività solo il 20% del tempo impiegato dalla normale attività di project management. 

Solo lo sprint corrente si giova di analisi sufficientemente approfondite, cosa non obbligatoria per i successivi sprint.
Questi ultimi, infatti, verranno particolareggiati quando arriverà il loro turno.  

Prevede infine, regole ben definite che scandiscono rapporti, tempistiche, modalità e strumenti, permettendo agli appartenenti al team, di essere efficienti, efficaci, focalizzati.  

Quali i principi ispiratori?

I principi ispiratori sono ovviamente mutuati dal manifesto agile. 

1. Soddisfare le esigenze del cliente
2. Accettazione dei change di progetto come normali accadimenti
3. Rilasciare prodotti funzionanti, anche parziali, frequentemente
4. Far lavorare a strettissimo contatto i tecnici, gli ingegneri e le persone più vicine al business
5. Puntare all’eccellenza tecnica, di design e di qualità
6. Essere motivati e motivare il team
7. Preferire comunicazioni dirette (face-to-face)
8. Ritmi lavorativi sostenibili
9. Semplicità a 360°
10. Retrospezione dell’operato

Cos’è esattamente SCRUM

SCRUM è un framework che permette il governo agile dei progetti. Riguarda essenzialmente il processo, gli strumenti, le persone, le modalità; non detta leggi inerenti le tecnicalità o le modalità in cui svolgere il lavoro che produce il prodotto, bensì ne governa l’avanzamento.  

E’ un approccio facilmente adattabile a progetti software, ma portabile anche a progetti di tipo hardware, marketing, operation (solo per citare alcuni esempi).  

Sono diverse le dimensioni dello SCRUM:  

• Strumenti e artefatti (Artifacts)
• Tempistiche precise (Time boxes)
• Ruoli (Roles)
• Regole (Rules)

Artifacts

   

Product Backlog

E’ il registro delle funzionalità necessarie, ordinate per importanza.  

Il Product Owner è il responsabile unico di tale registro.  

Egli, con l’aiuto degli altri stakeholder, comincia con la compilazione delle user stories: casi d’uso dell’applicazione descritte per singola tipologia d’utente.  

Dalle user stories vengono derivate le diverse funzionalità che le compongono e queste vengono elencate.  

In base alle priorità dello sponsor/committente, ai rischi identificati, al grado di dettaglio disponibile, alle funzionalità vengono assegnate priorità.  

E’ proprio da quelle in cima a quella lista che si comincerà a lavorare.  

Release Backlog

E’ un sottoinsieme del product backlog: identifica le funzionalità da implementare, raggruppate per versioni di prodotto che verranno rilasciate in produzione.  

Sprint Backlog

Rappresenta l’insieme delle funzionalità in ordine di priorità, che dovranno essere implementate nello sprint corrente.  

Queste vengono analizzate, scomposte in task, stimate dal team e prese in carico dai singoli componenti.  

Burndown chart

   

E’ un grafico che rappresenta il totale del lavoro mancante (ore o punti) suddiviso per giorno.  

Via via che il team evaderà lavoro, il trend della linea sarà discendente. E’ una rappresentazione che restituisce immediatezza rispetto alla resa e alle performance del team.  

Impediments Backlog

Lista degli impedimenti o dei problemi identificati, che risultano essere ostacoli al libero svolgimento del lavoro.  

Tale registro è gestito dallo Scrum Master, il quale dovrebbe affrontare e risolvere, nella teoria, i problemi emersi entro 24h dalla loro nascita.  

Bene per questa sera può bastare….nel prossimo post ripartiamo da qui: time boxes, ruoli e regole. 

Have a nice evening