E’ normale che un team che sviluppa abbia mediamente 2 esigenze da conciliare:
- quella di sviluppare un prodotto con nuove funzionalità
- quella di supportare i clienti
Come si può conciliare lo Scrum (che prevede iterazioni time-boxed di 2-4 settimane, con Sprint intoccabili e protetti) con il supporto che solitamente è composta da flussi di attività destrutturati e la cui priorità e dimensione può cambiare?
Condivido la mia esperienza.
In alcuni team mi è capitato di adottare la soluzione “fixed time” per citare “The Scrum Field Guide” di M. Lacey e funziona piuttosto bene. Questa soluzione è praticabile soltanto se il supporto si configura come un rumore di fondo (passatemi il termine) più o meno costante e che non ha particolari sbalzi di impatto sul lavoro del team. In questo modo il team, durante il planning, ha già la coscienza di quanto più o meno sarà il “rumore di fondo” del supporto e può prevedere di lavorare una certa quantità di cose per lo Sprint con un buon livello di sicurezza.
In altri contesti dove invece il supporto è molto variabile, ho trovato utilissimo dividere il team in 2 sottogruppi, un gruppo che fa Scrum (e quindi sviluppa con tutti i sacri crismi di Scrum) e un gruppo che fa supporto utilizzando Kanban, in modalità “fate pure Scrum che vi difendiamo noi”, ovviamente con una rotazione periodica fra le persone che fanno scrum e quelle che fanno Kanban per evitare che i “fire-fighters” si suicidino. Una nota per il gruppo che fa Kanban: al netto di emergenze catastrofiche o altro, il gruppo deve forzarsi a lavorare con un wip limit molto basso, al fine di avere tempi più bassi sulla singola richiesta di supporto ed avere alla lunga (nemmeno troppo) un’idea del cycle time.
In entrambi i casi comunque non si deve contravvenire ai dettami di Scrum e Kanban, per essere sicuri di massimizzare il risultato.