Il nostro stile Agile: Kanban con backlog

Da scrum a kanban backlog

Essere un piccolo team di sviluppo, organizzato e molto efficiente, ha portato ad una rapida evoluzione del nostro modo di lavora e di organizzare i processi.

Applicare le metodologie Scrum, è sempre stata più una forzatura che un reale beneficio. Sprint bisettimanali e cerimonie mal si sposavano con il nostro approccio di continuous integration & delivery e con un continuo cambio di priorità dovuto all’ingerenza di clienti più o meno importanti che entravano a gamba tesa sul tempo utile dei programmatori.

Così siamo passati ad un modello incentrato sulla metodologia Kanban, molto più dinamica, dove tutte le fasi di avanzamento sono alla luce del giorno e tutti possono interagire operando correzioni in corso d’opera e riascoltando i propri  task.

Questo approccio, molto più funzionale, ha però creato un effetto collaterale, la colonna dei to-do ha iniziato ad esplodere.
Abbiamo provato più volte a riorganizzare il lavoro e aumentare i momenti di confronto ma con scarsi risultati.

La soluzione è arrivata stravolgendo ancora una volta il processo, e adattando a martellate i tools di gestione Agile per conformarsi alle nostre necessità.

Il risultato si è concretizzato in un modello Kanban con backlog, spostando di fatto i to-do in un backlog e applicando una metodologia mista.

L’organizzazione del lavoro ne ha subito beneficiato,e gli sviluppatori, qualora fossero a corto di task, possono alimentare i loro to-do facendo cherry picking dal backlog direttamente nella Kanban board.

E’ poi cura del PO far si che la colonna to-do del programmatore sia sempre popolata di task a lui più consoni, dove può rendere meglio per esperienza e competenza.

Vediamo in questa tabella quali sono i vantaggi di gesta metodologia ibrida.

Scrum Kanban Kanban con backlog
Cadenza Sprint bisettimanali Flusso continuo Flusso continuo
Rilasci Al termine di ogni sprnt Continui Continui
Ruoli Product owner,
scrum master,
sviluppatori
Nessun ruolo Product owner,
sviluppatori
change
management
alla fine di ogni sprintin ogni momentoin ogni momento
KPI Velocity WIP,
cycle time 
Velocity,
WIP

Devo ammettere che i KPI sono sempre stato il vero problema. Non avendo uno strumento espressamente pensato per questo ciclo, l’approccio è sempre stato un pò troppo empirico. Ma come dicevo siamo pochi ed è stato abbastanza semplice gestire le metriche.

Da qualche giorno per una riorganizzazione interna, abbiamo iniziato ad utilizzare JIRA, e con mio grande stupore ho scoperto che prevede questa modalità.
Ma la cosa che mi ha colpito ancora di più, è che lo hanno implementato perché la stessa Atlassian utilizza il Kanban con backlog per gli sviluppi interni. Nel loro gergo Kanplan.

Come dire: siamo in buona compagnia!