23. Cosa ci dice?
Kanban non richiede ruoli predeterminati
(Scrum Master o Product Owner)
Non prevede iterazioni
Enfatizza il visual management ...con
qualche variazione
avanscoper
ta
And that’s the company I started one year ago.\n
Questa è la Romagna, la terra da cui provengo.\n
Terra di pregiate uve sangiovese.\n
E di fantastiche razze suine (se non conoscete la Mora Romagnola ...mi dispiace per voi).\n
Ma c’è qualcos’altro che rende questa terra speciale: l’incredibile concentrazione di piloti di Moto GP.\n(... si, lo so che Tavullia è nelle Marche... ;-)\n
Ma c’è qualcos’altro che rende questa terra speciale: l’incredibile concentrazione di piloti di Moto GP.\n(... si, lo so che Tavullia è nelle Marche... ;-)\n
Ma c’è qualcos’altro che rende questa terra speciale: l’incredibile concentrazione di piloti di Moto GP.\n(... si, lo so che Tavullia è nelle Marche... ;-)\n
Ma c’è qualcos’altro che rende questa terra speciale: l’incredibile concentrazione di piloti di Moto GP.\n(... si, lo so che Tavullia è nelle Marche... ;-)\n
Ma c’è qualcos’altro che rende questa terra speciale: l’incredibile concentrazione di piloti di Moto GP.\n(... si, lo so che Tavullia è nelle Marche... ;-)\n
Questo alimenta una serie di chiacchiere che avvengono nei luoghi deputati\n
E che hanno come protagonista fondamentalmente una sola persona.\n
Ma che hanno come protagonista una sola persona\n
Queste confidenze da bar, alimentate dal fatto che o di riffa o di raffa tutti abbiamo un amico nel mondo delle corse, mi ha fatto capire cosa rende Valentino Rossi speciale: un pilota normale si lamenta, un pilota bravo individua i problemi, un fuoriclasse individua la via d’uscita.\n
Queste confidenze da bar, alimentate dal fatto che o di riffa o di raffa tutti abbiamo un amico nel mondo delle corse, mi ha fatto capire cosa rende Valentino Rossi speciale: un pilota normale si lamenta, un pilota bravo individua i problemi, un fuoriclasse individua la via d’uscita.\n
Queste confidenze da bar, alimentate dal fatto che o di riffa o di raffa tutti abbiamo un amico nel mondo delle corse, mi ha fatto capire cosa rende Valentino Rossi speciale: un pilota normale si lamenta, un pilota bravo individua i problemi, un fuoriclasse individua la via d’uscita.\n
Queste confidenze da bar, alimentate dal fatto che o di riffa o di raffa tutti abbiamo un amico nel mondo delle corse, mi ha fatto capire cosa rende Valentino Rossi speciale: un pilota normale si lamenta, un pilota bravo individua i problemi, un fuoriclasse individua la via d’uscita.\n
Queste confidenze da bar, alimentate dal fatto che o di riffa o di raffa tutti abbiamo un amico nel mondo delle corse, mi ha fatto capire cosa rende Valentino Rossi speciale: un pilota normale si lamenta, un pilota bravo individua i problemi, un fuoriclasse individua la via d’uscita.\n
Si fa un gran parlare di Kanban, da dove possiamo cominciare a sperimentare?\n
Un’ottimo punto d’inizio è il libro di Kniberg e Skarin, che ha il pregio di essere incredibilmente chiaro. Ed anche sottile :-)\n
I punti salienti sono abbastanza semplici, no iterazioni, no discussioni sull’individuazione del Product Owner, e l’uso avanzato della board come strumento di management per il team.\n
La kanban board, di base, nasce come una variazione sul tema della Scrum Board, con l’idea di rappresentare tutti gli stati effettivi dello sviluppo. Non importa quale processo abbiate.\n
Al completamento dell’Item #2 lo spostiamo in Done.\n
Normalmente lo sviluppatore libero prenderebbe l’Item #5 ed inizierebbe a lavorarci. In Kanban questo non è ammesso...\n
Normalmente lo sviluppatore libero prenderebbe l’Item #5 ed inizierebbe a lavorarci. In Kanban questo non è ammesso...\n
Normalmente lo sviluppatore libero prenderebbe l’Item #5 ed inizierebbe a lavorarci. In Kanban questo non è ammesso...\n
Perché violerebbe il limite al Work in Progress. Il numero che contraddistingue ogni stato della board.\n
Per poter cominciare a lavorare su Item #5 è necessario che ci sia un posto libero nella colonna Development. Kanban fornza quindi gli sviluppatori a darsi da fare perché gli item vengano rilasciati in produzione, attivandosi per rimuovere il blocco.\n
Il limite al Work in Progress è il meccanismo che permette a Kanban di essere un sistema PULL: sono gli stadi successivi, che “tirano dentro” gli Item dagli stadi precedenti.\n
Un primo benefico effetto è quello di eliminare gli intasamenti, le feature bloccate o in attesa (e le relative chiamate: “Allora?”)\n
Ma alla fine è tutta una questione di soldi. Non di board e post-it.\nFacciamo un po’ di conti: ipotizziamo che una feature ci costi 1000€ alla settimana in fase di sviluppo. E che una volta rilasciata ci permetta di guadagnare 800€ alla settimana.\n
Se per qualche motivo aspettiamo a rilasciare in produzione la feature che abbiamo completato, il ritorno economico non è allo stesso livello: nelle 2 settimane di attesa non guadagniamo.\n
Quindi, la prima questione è: “perché aspettare?”, se una feature è pronta, per quale motivo non la stiamo mettendo in produzione.\n\nOvvio che la questione non è sempre così semplice, e ci possono essere buone ragioni per non farlo, ma il punto è “Sono veramente così buone queste ragioni?”, se per esempio stiamo aspettando che qualcuno testi la nostra applicazione, non poteva farli prima? O non potevamo cominciare a lavorare dopo e dedicarci ad altro nel frattempo?\n
Ok, qui c’è bisogno di un volontario.\n
Il gioco è semplice, alla lavagna. Ma dobbiamo cronometrare quanto tempo ci si mette a completare ciascuna delle tre parti.\n
Grosso modo questo è quello che ci aspettiamo.\n
Ora proviamo a fare la stessa cosa, rilasciando gli stessi prodotti, ma in maniera un po’ diversa. Prendete i tempi\n
E questo è grosso modo quello che succede quando lavoriamo in condizioni di multitasking spinto.\nNotiamo che il tempo necessario al completamento di tutti i prodotti è significativamente maggiore di prima (e con nomi lunghi è anche peggio). Il ciclo finisce con circa il 66% di ritardo. Ma sul primo progetto il ritardo è del 400%\n
Vediamo ora che succede nel caso di sviluppo di più features. In questo caso prima una e poi l’altra.\n
Se invece come spesso accade le portiamo avanti in parallelo, dividendo idealmente l’allocazione al 50% il risultato economico è significativamente peggiore.\n
Ma si trattava di un caso ideale, che non calcolava l’effetto devastante del multitasking. Se aggiungiamo un po’ dell’overhead relativo al multitasking (in questo caso ipotizziamo un 33%) il risultato diventa imbarazzante.\n
In contesti organizzativamente complessi le features che si pestano i piedi non sono 2: sono molte di più, io posso continuare :-)\n
C’è un’altro pezzo fondamentale che sta dietro a Kanban e che Kniberg non considera appieno: la teoria dei vincoli\n
Qualcosa che non viene dal mondo dello sviluppo software ma da uno dei testi sacri del mondo della produzione manifatturiera.\n
E che sta alla base della formazione di David J. Anderson, l’autore di quello che è il testo di riferimento su Kanban. \n
Qualcosa che anche una delle menti più raffinate del panorama scientifico e divulgativo ha contribuito a scoprire.\n
Che il problema è un ‘mbuto.\n
Ovvero, anche il sistema produttivo più complesso, in realtà può essere ricondotto alla capacità produttiva del suo collo di bottiglia.\n
La Teoria dei Vincoli ci dice fondamentalmente questo: ogni sistema ha un collo di bottiglia. Miglioralo e migliorerai la capacità produttiva dell’intero sistema.\n
Questa è una buona notizia: se sappiamo qual è il collo di bottiglia.\n
Questa non è una buona notizia, se ci stiamo sforzando di migliorare una situazione nel posto sbagliato.\n
Questa è un’altra conseguenza non indifferente: se stiamo lavorando per impiegare il nostro tempo, finendo per accumulare semilavorati prima del collo di bottiglia, faremmo meglio a smettere di intasare il collo di bottiglia, smettendo di alimentarlo.\n
Come affrontare i colli di bottiglia? Goldratt enuncia i 5 Focusing Steps, ripresi poi da Anderson nel suo testo.\n
Identificare i colli di bottiglia, sfruttarli al massimo della loro capacità, organizzare il flusso produttivo in modo che il collo di bottiglia non sia mai “fermo”, aumentare la capacità del collo di bottiglia, quindi riesaminare il sistema per scoprire il nuovo collo di bottiglia.\n
E che c’entra la board?\n
C’entra perché è un formidabile strumento di diagnostica per scoprire i colli di bottiglia!\n
\n
Fantastico! Quindi Kanban è la soluzione! Tutti su Kanban!!\n
Un attimo, lo strumento è potente. Ma è sempre meglio leggere attentamente le avvertenze e le modalità d’uso.\n
Perché potrebbero esserci controindicazioni alle quali non siamo preparati.\n(e qui c’era una battutaccia a sfondo politico che solo i presenti hanno potuto apprezzare)\n
La prima avvertenza è che il limite al Work in Progress in fondo è solo un numerino su una lavagna... per questa volta possiamo fare un’eccezione.\nE’ necessario un livello di disciplina e di coinvolgimento da parte del team non indifferente, senza il quale non abbiamo effetti.\n
Kanban ci porta ad individuare il bottleneck, o meglio ...i suoi effetti. Capire qual è la causa scatenante e come affrontarla è affar nostro. Non è comunque un caso che il modo di pensare della comunità Kanban sia fortemente orientato al System Thinking, che lo stesso Goldratt abbia poi approfondito l’argomento dei Thinking Processes e che gli strumenti di Root Cause Analysis siano il pane quotidiano.\n
In genere si parte dal team di sviluppo, perché lì c’è la prima percezione di un problema (o perché lo sviluppo è a valle dei problemi e ne subisce gli effetti). Prima o poi, però il collo di bottiglia evidenziato punterà a cause che stanno fuori dallo sviluppo. Possiamo affrontarle politicamente? C’è il corretto commitment da parte del management? \n
Siamo in grado come gruppo di lavoro di gestire la quantità di informazioni che Kanban può darci? \n
Perché se individuiamo il problema e non lo affrontiamo, allora tanto vale ...non fare nulla!\n
Ok, if that’s the answer... If you really like that and think that’s the best possible world... then I don’t have so much to tell you.\n