Capire davvero il lean thinking.

Il buon Gianandrea, attivo e paziente compare di riflessioni sui problemi dell’organizzazione del lavoro, sottopone alla mia attenzione questo articolo di Alessandro Cravera sul lean thinking. Un articolo rivelatorio delle distorsioni costantemente in agguato e in atto sempre più nel contesto manageriale che adotta metodologie agili per poi tradirne l’essenza. Lascia che ti spieghi come mai la pensi così.

Il pensiero di assunto da Cravera nella sua critica è quello di Womack per cui

Per usare le parole dello stesso Womack, il lean thinking è “un modo per fare sempre di più consumando sempre di meno”.

e da questa considerazione Cravera fa conseguire una riflessione sui rischi che il lean thinking comporta quando eventuali ridondanze vengono eliminate in nome della riduzione degli sprechi. Riflessione, questa, legittima perché effettivamente la riduzione tout court di ogni ridondanza è effettivamente a rischio di subottimizzazione, quella condizione in cui un ottimo locale può inficiare la prestazione globale di un sistema. Effettivamente lo scenario dello sviluppo di prodotti può fare tesoro di alcune ridondanze – basti pensare alla creazione di più ipotesi di interfaccia utente,  per fare un esempio banalissimo.  Quello che della riflessione non va, se vogliamo legarla ad una critica sana del lean, è l’assunto che il lean thinking sia devoto e prono alla subottimizzazione quando è assolutamente il contrario!

Nel Lean Primer di Craig Larman e Bas Vodde, la cui lettura consiglio a tutti gli interessati al pensiero lean, gli autori liquidano il punto di vista di Cravera già nella prima pagina (!) con questa considerazione che io riporto,  tradotta da me:

L’immagine e la metafora con cui vorremmo porre l’accento su un errore – ed un’opportunità – chiave è la staffetta.

Considera i podisti di una staffetta in attesa del testimone da parte dei loro compagni di squadra. L’account manager, inorridito da questo spreco da sottoimpiego indicato in qualche report, probabilmente definirebbe una nuova policy con l’obiettivo “dell’impiego al 95% delle risorse” per assicurare che tutti gli staffettisti abbiano da fare e siano produttivi. Forse – suggerirebbe – gli staffettisti potrebbero correre tre staffette contemporaneamente per incrementare l’occupazione delle risorse. [...]

Divertente… ma questo tipo di ragionamento è più tipico del management e dei processi tradizionali nello sviluppo e in altri domini. Invece, per contrasto, ecco l’idea alla base del lean thinking:

Tieni d’occhio il testimone, non gli staffettisti

Già traspare quindi il grave vizio di sostanza dell’ emerso – non capisco se solo per citazione o per effettivo sposalizio – nell’articolo di Cravera: guarda all’approccio lean attraverso le lenti dei processi classici e ne analizza l’eventuale risultato, ormai però distorto. Non mi dilungo oltre: se ti interessa il pensiero lean leggi l’articolo di Cravera con attenzione. Poi leggi quello di Larman e Vodde per capirlo davvero.

June 22 2011 | Base | 7 Comments »

Il sorriso in viso

Certo, ideato è la realtà in cui da anni passo la maggior parte del mio tempo come coach agile, ma se hai letto anche solo saltuariamente questo blog saprai che e-xtrategy è un’altra azienda che da qualche anno mi regala grandi soddisfazioni. Pochi giorni fa Michele ‘Miki’ Focanti, da qualche mese responsabile delle priorità di user story e task, mi ha scritto in vista dei nostri prossimi incontri.

[...]

Ad occhio mi sembra che “ci siamo”; abbiamo fatto la retrospettiva di gennaio ed abbiamo identificato le cose da migliorare che verificheremo a fine febbraio.
In questi giorni sta cambiando tutto “in tempo reale” (entrano progetti che devono essere consegnati dopo 2 giorni) e, incredibilmente, le persone continuano ad avere il sorriso in viso!

Il cambiamento epocale è stato questo:

prima qualsiasi evento (il cliente è contento, il cliente rompe le palle, c’è una cosa da modificare, etc) era legata all’e-xer [membro del team e-xtrategy, n.d.r.] responsabile del progetto (neanche al team). oggi qualsiasi evento diventa una “cosa di e-xtrategy” a cui dare una priorità e tutti si sbatteranno per portarla avanti prendendosi oneri ed onori.

in passato la telefonata al cliente era una delle cose più critiche. oggi è diventato: “Non riesci a chiamare Tizio? ok, allora lo chiamo io per te!”.

A presto

Miki

Capisci che fare il coach agile e parlare di lean development con persone così coraggiose è il lavoro più bello del mondo?

Miki, ci vediamo presto! ;-)

February 23 2011 | Dalle trincee | 1 Comment »

Lean e-xtrategy

e-xers

Sono di ritorno da una splendida due giorni passata lavorando con i ragazzi di e-xtrategy pensata per svolgere una retrospettiva su un progetto appena concluso, che ho avuto modo di seguire sin dall’inizio. Inutile dire che l’esperienza è stata formativa per me almeno quanto lo è stata per loro, che mi offrono sempre grande fiducia e libertà di svolgere le nostre analisi, senza sovrastrutture inutili, senza pregiudizi e senza la pretesa di dover nascere imparati, né io né loro.

I topic emersi e sviscerati sono stati diversi e purtroppo qui in questa sede posso solo riassumere i maggiori: kanban, value stream map, automatizzazione dei test e agile ux.

Kanban

Il problema immediatamente emerso dalla retrospettiva è stato quello di gestire le attività dell’azienda che non producono valore diretto per il cliente ma che vanno in ogni caso raccolte, valutate, inserite in una coda di priorità. Per tutti questi task la necessità di un punto di gestione concorrente e la possibilità per lo staff di e-xtrategy di lavorare in uno spazio di aperto e condiviso (elegantissimo peraltro n.d.r.) ha fatto emergere in pochi brevi passaggi l’adozione del kanban. Il kanban, lo scrivo brevemente a beneficio dei neofiti, è sostanzialmente una lavagna dove viene tracciato secondo poche ma ben determinate regole lo stato dei diversi task, abilitando il team ad una modalità di lavoro

  1. concorrente, dove sono ridotti al minimo gli stati di attesa per svolgere il proprio lavoro
  2. pull, dove si annulla la necessità di una figura responsabile dell’erogazione del lavoro da svolgere
  3. trasparente, dove ognuno sa e può sapere cosa sta facendo l’azienda nel suo insieme in un dato momento.

Abbattimento della burocrazia, trasferimento del controllo verso il basso e tracciamento di tutte le attività sono il cuore di questa soluzione.

Kanban in salsa marchigiana

'Porta' può essere tradotto dal marchigiano in questo contesto come 'Done' :-)

Value stream map

Sempre nell’ottica di individuare con precisione le attività che producono valore diretto per il cliente e distinguerle dalle attività accessorie abbiamo fatto ricorso alla mappatura del flusso del valore, che permette di individuare quali punti del processo ostruiscano la consegna del valore stesso al cliente. Come attività complementare abbiamo stabilito un ranking delle attività interne all’azienda secondo l’importanza percepita dal cliente rispetto al valore consegnato. Questo ranking è stato utile per capire in maniera più oggettiva quali siano le attività su cui cercare di tagliare i costi.

Interessante a dir poco, in un’azienda che passa la gran parte del tempo a scrivere codice PHP per consegnare siti web più o meno complessi, l’attività di scrivere PHP risulta essere fra le meno rilevanti per il cliente finale, quindi fra le meno dense dal punto di vista del valore consegnato. In sostanza una prova a posteriori di quanto sostengo da un bel po’: il codice è un mezzo, mai l’obiettivo.

Automatizzazione dei test

Per stabilire un punto di incontro oggettivo che stabilisca l’impalcatura di lavoro per il maggior numero di persone possibile all’interno dell’azienda si è stabilito di far attecchire i test funzionali una volta per tutte, incarnati da Selenium – nelle sue nuance Selenium RC per PHP e Selenium IDE. Il workflow per ora ipotizzato – perché solo dopo qualche settimana o mese di riscontri se ne potrà stabilire la bontà assoluta e relativa ad e-xtrategy – vede lo specialista XHTML/CSS produrre test funzionali di alto livello basati sui prototipi scritti in XHTML (vedi sotto) usando Selenium IDE – che permette di scrivere i test semplicemente usando il browser -  e poi una serie successiva di raffinamenti nelle fasi di sviluppo in cui i programmatori PHP con Selenium RC possono integrare gli stessi test in PHPUnit.

Interaction design (più) agile

Ale inizia a scrivere l'html del wireframe
Le intraprendenti decisioni prese dal team e-xtrategy in quei due giorni sono state argomento di discussione anche al di fuori delle mura e-xtrategy con commenti dei soliti noti ad un post di Alberto – Ilaria Mauric compresa, interaction designer di e-xtrategy. L’obiettivo che condivido con il team e-xtrategy in questo frangente è quello di mitigare, se non risolvere, il problema posto dall’integrazione di un team UX con un team di sviluppo. Dopo i primi esperimenti negli anni scorsi, infatti, i principali interaction designer con cui ho collaborato hanno rivisto al ribasso il loro entusiasmo per i metodi agili e si sono arroccati dietro un “per la progettazione il waterfall è inevitabile”, nonostante i pochi esperimenti fatti avessero lasciato soddisfatti tutti i team coinvolti – intesi nel loro senso più eterogeneo. Ovviamente, poi ho capito, per le aziende specializzate in interaction design il discorso ha senso: perché impelagarsi ad integrare il mio metodo con quello di chi sviluppa se il mio business è esclusivamente basato sulla progettazione?

E-xtrategy però presenta una situazione diversa in cui la multidisciplinarietà del team interno è elevata e in cui quindi una metodologia agile integrata ritorna immediatamente di altissimo interesse. Interaction designer, visual designer, sviluppatore XHTML/CSS e sviluppatori PHP, poiché a stretto contatto, possono condividere molto spesso i loro semilavorati e perfino lavorarli in pair cross-funzionali!

Il succo insomma sta nel ridurre al minimo l’approccio fornitore-cliente che vuole – per fare un mero esempio – che l’interaction designer sviluppi un wireframe che poi venga traformato in prototipo che poi venga passato al visual designer che poi passi il template al programmatore XHTML/CSS che poi passerà il lavoro finale alla gente del PHP, in una lunga serie di piccoli waterfall. Con alcuni accorgimenti è possibile circoscrivere molto la necessità di una progettazione upfront: sviluppato un prototipo XHTML molto simile al wireframe, si comincia a scrivere test funzionali per garantire che quel wireframe-ormai-prototipo sia la base di tutto il lavoro successivo per tutto il team. Si fa in modo insomma che il wireframe venga sugellato dai test automatici come il codice eseguibile, con un immenso guadagno sia in termini di formalismi e oggettività – il wireframe esaltato dai test nel suo giusto ruolo di contratto – sia in termini di organizzazione del lavoro – gli sviluppatori e i grafici possono in questo modo lavorare in parallelo sin dalle prime fasi dello sviluppo.

Non mi rimane che ringraziare e-xtrategy per la rinnovata esperienza di coaching e promettere a te di riportare qui la cronaca dei prossimi sviluppi più rilevanti relativamente a tutti questi temi .

July 31 2010 | Dalle trincee | 8 Comments »

Lean. Da generazioni.

Più volte si è reso necessario ribadire che molte delle soluzioni proposte dai metodi agili, sebbene spesso controintuitive, sono sempre derivate dall’esperienza e mai dalla mera speculazione. Una forma di saggezza insomma, ampiamente condivisa, distillata e raccolta nella letteratura di settore.

Oggi in Liguria mia nonna riguardo al mio imminente trasloco:

Devi tenere solo quello che ti serve, butterai quasi tutto. Tanto si usano sempre solo poche cose e sempre quelle.

Lo avresti detto? La saggezza popolare è lean. :-)

April 03 2010 | Humor | 2 Comments »

ITDevCon 2009: One approach to rule them all

Ringraziando la simpatica compagine di bit Time per la simpatia e l’accoglienza durante lo svolgimento di ITDevCon 2009, pubblico – stavolta entro i 6 mesi! :) – le slide che hanno accompagnato il mio intervento.

p.s. finalmente il blog è di nuovo up...

November 14 2009 | Eventi | No Comments »