Che cos’è, ruoli e metriche della metodologia Scrumban

Scrumban: Scrum e Kanban

La metodologia Scrumban è stata introdotta da Corey Ladas nel suo libro “Scrumban: Essays on Kanban Systems for Lean Software Development”; in questo testo l’autore afferma di aver pensato Scrumban come un percorso evolutivo per permettere a un team di sviluppatori di cambiare il proprio metodo da Scrum a Kanban, o più in generale ai metodi Lean. Il passaggio ad una nuova metodologia non è mai semplice e questi cambiamenti avvengono meglio se non vengono effettuati in modo drastico, ma introdotti gradualmente. In questo contesto Scrumban si propone come una valida via di mezzo tra i due metodi per poter abbandonare gli strumenti di Scrum e adottare quelli di Kanban prendendo dunque il meglio di Scrum e Kanban.

Scrumban privilegia lo sviluppo just-in-time e riduce i tempi di rilascio, queste caratteristiche lo rendono vantaggioso in alcune situazioni in cui il team trova Scrum troppo rigido rispetto alla flessibilità richiesta dai compiti da svolgere.

Nel caso di progetti che hanno già terminato la fase di sviluppo e sono ormai in fase di manutenzione, Scrumban può essere usato per gestire una situazione dove gli interventi richiesti sono di tipo event-driven (come la risoluzione di bug) oppure se è necessario fornire un supporto ai clienti; ricordando che la fase di manutenzione corrisponde a circa metà del processo di sviluppo del progetto. Questo avviene perchè il software richiede cambiamenti dovuti all’evoluzione dell’ambiente in cui opera (aggiornamento del sistema operativo o delle librerie o del database sono tra i motivi più comuni); quando il software non viene più aggiornato può essere considerato deprecato, se questo avviene perchè il software è troppo difficile da modificare allora sono state sprecate delle risorse.

Un altro caso in cui Scrumban può risultare vantaggioso è quando un progetto è nelle fasi di hardening e packaging, poichè in questi stadi dello sviluppo non avviene l’introduzione di nuove feature.

Esistono, però, anche casi in cui un progetto è in fase di sviluppo, ma un metodo meno rigido e con una gestione più lasca dei tempi di sviluppo può aiutare il team a recuperare la situazione e riportare il progetto sui binari: per esempio quando un progetto riscontra molti più errori rispetto a quanto preventivato o ha la necessità di introdurre continuamente nuove User Story nel processo di sviluppo; oppure quando uno Scrum Team ha problemi a gestire il flusso di lavoro o a sfruttare correttamente le risorse disponibili, oppure il processo di sviluppo riscontra spesso degli stalli.

Un’altra situazione in cui è possibile applicare Scrumban è quello di gestire le fasi che precedono e seguono uno Sprint con questo metodo, mentre durante lo Sprint si continua a usare Scrum.

Per capire se l’adozione di un metodo meno rigido sia utile al progetto è possibile osservare dove avvengono più spesso dei cambiamenti all’interno uno sviluppo iterativo, questo è un valido punto di partenza per capire dove il sistema richieda maggiore flessibilità. Inoltre, se alcune aree del software richiedono continue modifiche nel corso dello sviluppo, molto probabilmente le stesse aree saranno oggetto di interventi in fase di manutenzione.

Ruoli di Scrumban

Così come per il processo Scrumban, anche per quanto riguarda i ruoli dei membri del team è possibile effettuare una transizione da Scrum a Kanban. Partendo dagli incarichi già presenti in Scrum si può effettuare una transizione verso Kanban riassegnando le mansioni, cercando il più possibile di mantenere una linearità delle responsabilità nel passaggio.

Per quanto riguarda il Development Team non ci sono modifiche da effettuare, anche se Kanban permette di integrare più Team Scrum in un team di dimensioni maggiori. Questa scelta può essere conveniente per ridurre i costi di di gestione.

Il Product Owner può diventare il Service Request Manager nella nuova conformazione del team, infatti la sua capacità di comunicare con il cliente e di comprendere quale sia la priorità da assegnare a ogni feature sono qualità utili in entrambi i ruoli.

Lo Scrum Master è la figura probabilmente più indicata per prendere il ruolo di Service Delivery Manager. Infatti la sua abilità di gestire uno Scrum Team può essere sfruttata anche nel nuovo organigramma per indirizzare le attività del team.

Il ruolo del Kanban Coach può richiedere l’introduzione di una nuova persona all’interno dell’organizzazione se nessun membro del team ha già avuto esperienze nel mondo Lean o Kanban. Con il passare del tempo, quando il team ha preso dimestichezza con il nuovo metodo, questo ruolo può essere assegnato al Service Delivery Manager.

Metriche di Scrumban

Come appena detto per i ruoli, anche per le metriche della metodologia Scrumban si può effettuare una transizione da quelle maggiormente legate a Scrum a quelle introdotte da Kanban. Sarà compito del Kanban Coach quello di introdurre le metriche Kanban e abbandonare quelle Scrum in base alle varie fasi del processo di transizione da un metodo all’altro.