Quando, prima di iniziare a lavorare con un Agile product team, una delle più comuni situazioni trovo è dove le squadre sono lunghe e frustranti Sprint planning meeting perché backlog elementi sono mal definiti e non ben compreso; hanno velocità lenta e cattiva progettazione, perché i dettagli sono ancora in fase di elaborazione durante lo Sprint; e la quantità di scarti e rilavorazioni è molto alta, perché backlog elementi non sono stati convalidati.

Ricorda che il nostro obiettivo di ordine superiore è quello di convalidare le nostre idee nel modo più veloce ed economico possibile. In realtà costruire e lanciare un’idea di prodotto è generalmente il modo più lento e costoso per convalidare l’idea.

Ecco perché sono un grande sostenitore di ciò che a volte viene definito Dual-Track Agile (aka Dual Track Scrum, Fingere prima di farlo, Costruire cose che non scalano / Costruire cose che fanno scala, muoversi velocemente / Non rompere le cose, Scoperta continua / Consegna continua, ecc.).

Mi riferivo a questo semplicemente come Sprint di scoperta, ma questo ha un’implicazione della scoperta in scatola temporale e anche della serializzazione delle fasi. Jeff Patton ha condiviso per la prima volta con me il termine “Dual-Track Scrum” e preferisco questo termine perché cattura meglio la natura parallela della scoperta e della consegna.

La pista di scoperta è tutto di generare rapidamente elementi convalidati product backlog, e la pista di consegna è tutto di generare software rilasciabile.

Un altro motivo per cui mi piace la metafora Agile a doppio binario è che trovo molte persone che essenzialmente fanno piccole mini-cascate all’interno del loro framework Scrum. Il product manager fa una sorta di “requisiti” di lavoro, e che viene passato a un designer che fa i suoi disegni e genera i suoi artefatti (di solito wireframe annotati), e poi che viene consegnato al team di consegna per costruire e testare.

Al contrario, in Dual-Track Agile, il flusso di lavoro non è caratterizzato da ciascun ruolo che consegna gli artefatti al passaggio successivo; piuttosto è collaborativo: product manager, designer e lead engineer stanno lavorando insieme, fianco a fianco, per creare e convalidare gli elementi del backlog.

I lettori di questi articoli sanno quanto sia importante considero il design dell’esperienza utente, ma una delle difficoltà per molti team Agile è che il ritmo e il ritmo di Agile possono essere molto difficili nei team UX tradizionali. Questo è il motivo per cui sono un fan di Lean UX. Lean UX e Dual-Track Agile sono fatti l’uno per l’altro. Piuttosto che concentrarsi sugli artefatti, ci concentriamo sui prototipi e sulla convalida di tali prototipi in Discovery, con l’ulteriore vantaggio che il prototipo funge da specifica per la consegna.

Soprattutto, a differenza di un processo a cascata in cui la convalida avviene dopo il rilascio, in Dual-Track Agile, stiamo convalidando durante il Discovery. Nel principio della convalida il più veloce ed economico possibile, gran parte del tempo possiamo infatti fare la nostra convalida prima di scrivere qualsiasi codice di produzione, nello spirito di “fake it before we make it.”

Quindi, se il tuo team di prodotto è frustrato dalla quantità di rifiuti e dal ritmo lento nel raggiungere risultati aziendali effettivi, considera di provare Agile Dual-Track. Scopri se questo può ispirare un livello di collaborazione, iterazione rapida e convalida che si traduce in un lavoro molto migliore.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.