I Kanban non sono una metodologia

25 August, 2010 (18:21) | agile, lean, programming | 5 comments

E’ noto che nel nostro campo ogni nome viene sovraccaricato di significati, l’ultimo esempio riguarda i Kanban

Prima si è iniziato a parlare di Lean, poi qualcuno ha iniziato ad usare e a parlare di Kanban Board, infine adesso Kanban è diventato quasi il nome di una metodologia. Adesso quando uno parla di Kanban non so a cosa pensare:

  • Starà parlando di Kanban come sinonimo di Lean? Si ma Lean come sinonimo di Lean Thinking, ovvero la filosofia Lean o Lean Development, ovvero l’applicazione della filosofia Lean allo sviluppo del software?
  • Starà parlando di Kanban come sinonimo delle board che adesso vanno tanto di moda negli Agile shop?
  • Starà parlando di Kanban come di una non meglio precisata metodologia? Come lo ScrumBan, ovvero uno Scrum che fa uso di Kanban Board o come Kanban, ovvero l’uso delle Kanban Board misto a qualche pratica presa da XP?

Insomma un delirio, la salvezza come al solito sta nella conoscenza: bisogna tornare alle origini della parola, studiarne l’evoluzione per capirne le implicazioni ed un eventuale contesto d’uso

Kanban si traduce in cartellino: I giardini imperiali giapponesi sono curati all’ossessione e sono considerati un patrimonio del giappone, per questo solo poche (supponiamo 100) persone alla volta sono autorizzate ad entrare, per garantirlo vengono usate delle tessere di plastica bianche, ne esistono solo 100, una persona può entrare solo se possiede una di queste tessere che possono essere prelevate da un contenitore all’ingresso, quando il contenitore è vuoto nessuno può entrare, quando una persona esce deposita la sua tessera che verrà automaticamente trasferita nel contenitore all’ingresso consentendo a qualcuno di prelevarla ed entrare. Le tessere di plastica sono Kanban

Quindi i Kanban sono la rappresentazione sistemica del vincolo sulla capacità produttiva dell’impianto. Cosa significa quesa frase e come può tornare utile allo sviluppo del software lo spiego subito

L’applicazione del pensiero Lean porta ad eliminare una classe di problemi e/o di sprechi nell’attività produttiva attraverso un approccio sistemico ovvero creando un ambiente di lavoro che rende difficile commettere errori. Un esempio tipico sono i connettori la cui forma impedisce fisicamente di sbagliare verso. Un altro bell’esempio ce lo forniscono gli ospedali in cui si applica il pensiero Lean, nei quali tutte le attrezzature hanno un posto dedicato che solitamente viene marcato con un’immagine stilizzata del tipo di attrezzo che dovrebbe occupare quello spazio, in questo modo

  • E’ molto semplice accorgersi se uno strumento è fuori posto perchè ci sarebbe l’immagine dello strumento senza lo strumento stesso
  • Nei momenti d’emergenza non devi metterti a pensare dove si trova uno strumento perchè sta sempre nello stesso posto
  • L’ordine non è più una questione di gusto personale :-)
  • Essendo la distribuzione degli strumenti così rigorosa è possibile fare esperimenti per capire se un’eventuale riorganizzazione (che è quasi sempre microscopica seguendo il principio del Kayzen) produce un miglioramento o meno

Quando si ha a che fare con dei sistemi complessi è molto più efficiente ed efficace applicare un controllo indiretto invece che tentare di forzare le singole parti al proprio volere, basta pensare all’acqua, le singole particelle costituiscono un sistema complesso con proprietà emergenti, come fai a trasportare l’acqua? tenti di convincere le singole particelle? La sposti fisicamente? O crei un canale e lasci che felicemente scorra seguendo le proprie leggi ma finendo esattamente dove vogliamo Quest’ultimo può essere definito un approccio sistemico

Ahhhh se solo la maggior parte dei manager sapesse… il mondo girerebbe diversamente, ma la resa dei conti arriverà presto caro cravattato dall’ignoranza bovina… ma sto divagando

Le Kanban Board creano un ambiente di lavoro dove è difficile commettere una serie di errori classici della produzione: avere molte user stories in lavorazione (semilavorati) che non portano valore al sistema, evitare il sovraccarico di lavoro del team, individuare molto velocemente eventuali parti critiche dello sviluppo di una user story, ecc… Bene, ma dove sono i Kanban nelle Kanban Board che si usano nella produzione di software? Non sono le carte delle user stories (come banalmente si potrebbe pensare), i kanban rappresentano i limiti della produttività del sistema, in questo caso il limite è sul numero delle user stories che possono essere in lavorazione ovvero i kanban sono i singoli “posti” che possono essere occupati dalle carte delle user stories.

Per ogni fase ci possono essere un numero limitato di user stories, in questo modo si possono facilmente identificare eventuali stalli, fasi problematiche, sprechi di vario genere ecc…, peccato che tutto questo sia molto lontano dall’essere Agile… perchè? Semplice il limite è imposto sulle fasi, si presuppone quindi che ogni fase sia un sottosistema dimensionabile a piacere per equilibrare il flusso delle user stories fino al loro completamento, una fabbrica insomma, alla fine siamo tornati al waterfall (il cravattato ci prova sempre, non c’è niente da fare)

Molto più Agile e sensato sarebbe limitare la capacità produttiva del team sulle dimensioni del team stesso, banalmente una user story per sviluppatore, al limite per coppia di sviluppatori. Ad ogni sviluppatore assegnamo una calamita, le user story appese alla lavagna sono in lavorazione, una user story può essere appesa usando solo una di quelle calamite, una calamita può essere usata solo con una user story alla volta ed il gioco è fatto. Le fasi possono essere ancora conservate, possono essere utili per stanare certi problemi, ma l’enfasi dovrebbe essere sugli sviluppatori e non sulle fasi (“Individuals and interactions over processes and tools” vi ricorda qualcosa?)

Concludo dicendo una cosa ovvia: più si studia uno strumento/pratica/tecnica e più è facile utilizzarlo saggiamente nel contesto in cui ci si trova per raggiungere i nostri obiettivi, il pericolo è quello di abusarne o peggio essrne abusati :-)

“Ma quanto vuoi guadagnare?”

7 May, 2010 (08:47) | agile, human, rant | 5 comments

Un bel giorno un uomo si presenta da un costruttore mostrandogli il disegno di una casa e gli chiede

Vorrei costruire una casa fatta esattamente in questo modo. Quanto ci metti a costruirmela? Quanto mi costerebbe?

Il costruttore stoicamente risponde

Tre mesi e 100.000 euro

L’uomo, guarda il costruttore con uno sguardo diretto… semplice… come se stesse parlando delle condizioni metereologiche

Ti do una settimana e 5.000 euro

Il costruttore rimane sbigottito… non sa se lo stanno prendendo per il culo o se fanno sul serio: se lo stanno prendendo per il culo è il momento d’incazzarsi, se fanno sul serio è il momento di mettersi a piangere; decide in buona fede di cercare di capire meglio

Scusami, ammesso e non concesso che umanamente sia possibile farlo in una settimana, significherebbe utilizzare molte più risorse di quelle spese per farcela in tre mesi… quindi al limite ti costerà di più di 100.000 euro, perchè dovrebbero bastarne 5.000???

L’uomo, sempre con la stessa faccia risponde

Accidenti, ma quanto vorresti guadagnare in una settimana?!?!?!

… Ve lo dico io, non c’è dubbio, ci stanno prendendo per il culo

A questo proposito faccio un appello a chiunque può essere interessato, secondo me c’è (e crescerà sempre di più) un oceano blu, ovvero un mercato di opportunità non ancora esplorato, che è quello del “Procuratore per sviluppatori”

Il procuratore dovrebbe trovare il cliente (anche se non è necessario, potrebbe trovarlo direttamente lo sviluppatore) e trattare gli aspetti economici e burocratici del progetto per conto dello sviluppatore, in cambio il procuratore si becca il 20% del fatturato, gli aspetti tecnici vengono gestiti direttamente dallo sviluppatore, esattamente come succede per i calciatori/sportivi (anche se ammetto di non saperne molto ;-P)

Ci sono molti dettagli che devono essere definiti, ma potrebbe funzionare, da gennaio/febbraio sto lavorando in questo modo e sono abbastanza soddisfatto, se qualcuno è interessato, mi contatti direttamente :-)

Una metrica per i professionisti

8 March, 2010 (11:38) | agile, communication, human | 4 comments

Parto da un assunto fondamentale

Il desiderio di controllo nasce dalla paura di non averlo

Da cui una metrica molto semplice da misurare per colui che si definisce professionista

Tutte le volte che un cliente ti chiede a che punto sei in merito ad un lavoro che stai facendo per lui, hai perso 10 punti. Se non rispondi in tempo reale, hai perso 1000 punti

Inutile dire che perdere punti è molto più semplice che guadagnarli… Quello che penso è che il “command & control” non lo voglia spontaneamente nessuno, neanche il cliente, ci si arriva quando costretti, sopratutto per la mentalità italiana dove il 90% della popolazione vorrebbe fare “l’intermediario” nullafacente

Analizziamo il processo mentale del cliente

  • Gli ho chiesto di fare questa “piccola” cosa due giorni fa e non ho più saputo niente, cosa starà facendo? Starà lavorando? E’ una cosa importante, deve essere pronta per questa sera… Forse è meglio lasciarlo lavorare, fra poco si farà sentire…
  • Sono le 16:00 e non si è ancora sentito nessuno… eh no, adesso basta, gli faccio il culo, non è possibile, aveva detto che avrebbe consegnato prima di sera e sono due giorni che non si fa sentire, gli mando una e-mail
  • Non risponde neanche alle e-mail!!! Lo sapevo, non ha fatto niente!!! Per questa sera non sarà pronto niente e sarò nella merda!!! La prossima volta non ci casco più!!!

Ora, poco importa se il nostro “professionista” era in meditazione per riuscire a finire in tempo, poco importa se effettivamente la consegna è avvenuta in tempo, l’ansia e il dubbio sono comunque entrati nella mente del cliente che vorrà avere sempre più “controllo”, anche se la sua forma di “controllo” sarà letale per il progetto :-)

Ogni volta che un vostro cliente vi chiede informazioni su qualcosa, lo fa perchè si sente obbligato a farlo, se potesse eviterebbe, confrontatevi immediatamente con lui per capire come fornigli in anticipo le risposte ai suoi dubbi, siate veri professionisti, non ve ne pentirete

Agilecamp2010 e Code Katas

1 March, 2010 (13:23) | agile, kata, milano-codingdojo, milano-xpug | 2 comments

Non dirò che è un bel po’ di tempo che non scrivo e non dirò che nel frattempo sono successe troppe cose, dirò solo che sabato scorso sono stato in quel di Lugano al AgileCamp ospitato da Sketchin è stata veramente una bella giornata, a formare la “spedizione del milano-xpug” con me c’erano Giordano, Indrit (Selimi) e Andrea (Francia)

L’atmosfera e il clima sono stati perfetti per un barcamp: bel posto (tra l’altro ero in poltrona in prima fila, l’unica cosa difficile è stata mantenere la lucidità dopo pranzo), bella gente, Luca è stato un ottimo padrone di casa e sopratutto le competenze dei presenti erano molto eterogenee (programmatori, designer e product manager/owner)

Personalmente mi sono giocato la presentazione sui kata della programmazione

La stessa che ho portato al javaday

Se siete interessati al tema vi consiglio di iscrivervi alla ml del milano-xpug e/o a quella del milano-codingdojo, stiamo organizzando alcune attività anche non strettamente legate all’area di Milano :-)

P.S. Alla fine del talk dico di aver seguito la scuola di Martin Fowler del Clean Code, imperdonabile errore, ovviamente stavo parlando di Robert C. Martin :-)