In Overflo stiamo attraversando una fase di cambiamento importante. Per anni abbiamo lavorato adottando le tecniche agile, ma anche adattandoci di volta in volta alle esigenze dei progetti. Era un modello che ci ha permesso di essere flessibili e reattivi, ma che col tempo ha mostrato i suoi limiti: troppa frammentazione, poca visione d’insieme e un flusso di lavoro che a volte si inceppava proprio nei momenti più delicati. 

Ognuno di noi si concentrava sui propri compiti, senza sempre avere chiaro come quel compito si incastrasse nel resto del progetto. Il risultato erano rallentamenti, disallineamenti tra chi lavorava a monte e chi a valle e una certa perdita di coerenza nel prodotto finale. Anche la gestione della qualità risentiva di questa struttura. Il flusso finiva spesso per dover testare tutto alla fine, passando molto tempo in verifica manuali di funzionalità che, idealmente, avrebbero dovuto essere già solide. Con il pensiero Lean abbiamo deciso di distribuire le responsabilità in modo più equilibrato. Oggi gli sviluppatori si occupano dei test tecnici e funzionali preliminari, mentre i PO si concentrano solo sulle verifiche di business, rapide e mirate. È stata introdotto la logica dello shift-left, che in pratica nel nostro contesto ha significato anticipare i controlli di qualità e sicurezza nelle prime fasi dello sviluppo. Questo ci permette di individuare un problema subito senza dover lasciare trascorre giorni e non permettendo l'attività di passare altre fasi successive. Il Lean ci ha aiutato anche a riconoscere e tagliare diversi tipi di sprechi. Ci siamo resi conto, ad esempio, che avevamo troppo lavoro “a metà”, codice scritto ma non testato o funzionalità aggiuntive che nessuno aveva davvero chiesto (es. sviluppato per rendere il prodotto più compatibile con altri sistemi), che finivano solo per complicare le cose e rendere difficile la consegna al cliente. Anche il continuo cambio di contesto, il dover saltare da un progetto all’altro, portava via concentrazione. 

Per riuscire a eliminare questi sprechi e costruire un sistema più snello dove il valore si vede lungo tutto il percorso, abbiamo scelto un approccio ibrido: lo Scrumban. Il motivo è perchè unisce la visualizzazione dei flussi tipica di Kanban con la ciclicità e la riflessione continua di Scrum. In pratica, abbiamo mantenuto la libertà di adattarci, ma dentro un quadro più ordinato. Abbiamo alleggerito la pianificazione rigida, aumentato l’autonomia dei team e introdotto momenti regolari di revisione, per capire insieme dove possiamo migliorare. In fondo, quello che stiamo facendo non è solo cambiare metodo. Stiamo imparando a guardare il nostro lavoro in modo diverso: come un flusso continuo di valore, dove ogni parte conta e tutto è collegato. È un cambio di mentalità, più che di processo. 

🤓 Nerd corner - Un po’ di teoria: da dove nascono Lean e Kanban?

Lean affonda le sue radici nella Lean Manufacturing giapponese, sviluppata principalmente da Toyota a partire dagli anni 50.  L’idea di base era semplice ma rivoluzionaria: eliminare ogni spreco (muda) e concentrarsi solo sulle attività che generano valore per il cliente. Questo approccio ha dato origine al Toyota Production System, che ha poi ispirato anche il mondo IT e dei servizi.

Kanban, invece, nasce sempre in Toyota come metodo visivo per controllare il flusso di lavoro nella produzione. “Kanban” in giapponese significa cartellino o segnale visivo.  Ogni fase del processo aveva un cartellino che segnalava quando serviva più materiale o quando un’attività poteva procedere.  Nel mondo del software, Kanban è stato adattato come board digitale, con colonne (To Do, Doing, Done) che rendono visibile lo stato delle attività in tempo reale.