Dual-Track Scrum

Quando incontro per la prima volta team di prodotto agili, i membri del team si trovano solitamente in una situazione in cui sono afflitti da lunghi e frustranti Sprint Planning Meeting, poiché i Backlog Item sono mal definiti e non sono stati compresi correttamente. La Velocity è lenta e il design è scadente, perché i dettagli vengono ancora elaborati durante lo Sprint. Inoltre, c'è molto spreco e molte rilavorazioni da fare, perché i Backlog Item non erano stati validati.

Ricorda che il nostro obiettivo principale è validare le nostre idee nel modo più rapido ed economico possibile. Implementare effettivamente un'idea di prodotto e lanciarla sul mercato è fondamentalmente il modo più lento e costoso per farlo.

Cos'è il Dual-Track Scrum?

Per questo motivo sono un grande fan di qualcosa che viene chiamato, tra le altre cose, Dual-Track Scrum. In passato usavo il termine "Discovery Sprint", ma questo dava l'impressione di una Discovery limitata nel tempo e della serializzazione delle fasi.

La prima volta che sentii parlare di "Dual-Track Scrum" fu da Jeff Patton. Preferisco questo termine perché evidenzia meglio il parallelismo tra Discovery e Delivery.

Il Product Discovery Track riguarda la generazione di Product Backlog Item validati il più rapidamente possibile. Il Product Delivery Track riguarda la generazione di software rilasciabile.

Un altro motivo per cui mi piace così tanto la metafora dei due "binari" nel Dual-Track Scrum è il fatto che vedo spesso persone che inseriscono sostanzialmente dei mini-waterfall nel loro framework Scrum. Il product manager svolge un qualche "lavoro sui requisiti", che poi passa a un designer. Questo crea un design e genera i suoi artefatti (solitamente wireframe annotati) e poi tutto viene consegnato al Delivery Team per lo sviluppo e il testing.

Al contrario, il flusso di lavoro nel Dual-Track Scrum non è caratterizzato dal passaggio di artefatti da un ruolo al successivo. Invece, il Dual-Track Scrum è collaborativo – product manager, designer e lead developer lavorano fianco a fianco per creare e validare i Backlog Item.

I lettori dei miei articoli sanno quanto sia importante la User Experience Design ai miei occhi. Tuttavia, il ritmo e la velocità di Scrum possono rappresentare un problema per molti team UX tradizionali. Per questo sono un grande fan del Lean UX. Lean UX e Dual-Track Scrum sono fatti l'uno per l'altro. Invece di concentrarci sugli artefatti, nella Discovery ci concentriamo sui prototipi e sulla validazione di questi prototipi. Un ulteriore vantaggio è che questi prototipi fungono da specifiche per la Delivery.

Il punto più importante, però, è che la validazione non avviene dopo il rilascio come in un processo waterfall, ma nel Dual-Track Scrum effettuiamo la validazione già durante la Discovery. Per quanto riguarda il principio di validare qualcosa nel modo più rapido ed economico possibile, spesso possiamo effettivamente eseguire la validazione prima ancora che venga scritto del codice – in perfetto stile "fake it before we make it", ovvero fingere finché non funziona davvero.

Conclusione sul Dual-Track Scrum

Se il tuo team è quindi frustrato perché c'è troppo spreco e perché i risultati concreti di business vengono raggiunti solo lentamente, dovresti prendere in considerazione il Dual-Track Scrum. Forse può portare a una migliore collaborazione, un'iterazione e validazione più rapide e quindi a un lavoro migliore.

Questo testo proviene dal blog di Marty Cagan ed è stato tradotto in italiano.

Strategia aziendale vs. Strategia di prodotto

Scopri di più sui potenziali conflitti strategici nel nostro articolo sulla differenza tra strategia aziendale e strategia di prodotto.