Tutti gli approcci Agile/Lean based spostano il focus dalle fasi al bouquet di funzionalità da realizzare per soddisfare un’esigenza del cliente. Ciò si traduce praticamente in un Product Backlog che contiene i work item su cui concentrare le nostre attività.
Tali work item vanno ordinati (priorizzati) per Valore… ma qui sorge una domanda fondamentale: “cos’è il Valore nel nostro contesto?”.
Il desiderata dell’utente? Una iniziativa mirata a ridurre il rischio per il progetto? Una serie di storie pensate per chiarire gli aspetti UX/UI?
Tutte queste declinazioni sono una valida interpretazione del concetto di Valore, per cui può diventare estremamente difficile ordinare il nostro backlog, visto che le variabili in gioco potrebbero aumentare in modo considerevole.
Un interessante framework che può essere utilizzato per dare una prima connotazione di Valore ai nostri work item è rappresentato dal Time Management Matrix (TMM) di Stephen Coveys, a sua volta formalizzazione di un sistema di supporto strategico utilizzato dal generale Dwight D. Eisenhower, successivamente presidente degli USA.
Time Management Matrix
Lo scopo è quello di inquadrare le attività in funzione di due assi di rilevanza specifica: Urgenza e Importanza. Questa scelta è decisamente ovvia, se si pensa che spesso, ogni richiesta del business è Urgente ed Importante allo stesso modo, e il tentativo è quello di porre sempre le nuove attività in cima a quelle in essere, andando a causare una saturazione di gestire efficacemente il loro completamento. Questo perché, spesso, si discute in termini di capacità (Capacity) totale del team e non di un efficace gestione del flusso (Throughput) operativo.
L’esempio classico per spiegare questa differenza è dato dalla similitudine con l’autostrada:
se la richiesta è inferiore alla capacità, allora le autovetture hanno lo spazio (slack) per avere un flusso sostenibile senza creare traffico. Viceversa, se la richiesta è uguale o addirittura maggiore alla capacità viaria, le autovetture resteranno incolonnate causando una congestione del traffico.
La TMM è uno strumento che consente di inquadrare i diversi work item in quattro fasce specifiche:
- Urgente e Importante, sono i task più rilevanti nel breve periodo;
- Importante ma non Urgente, sono i task più rilevanti nel medio-lungo periodo;
- Urgente ma non Importante, sono i task che vanno fatti ma possono essere delegati;
- Non Urgente e non Importante, sono i task da eliminare.
TMM Actions
Se da un punto di vista operativo, il primo quadrante cattura subito la nostra attenzione, il secondo quadrante è invece quello strategico, poiché contiene i task più importanti per la continuità del nostro business.
In pratica il primo quadrante è riconducibile all’Iteration/Sprint backlog, mentre il secondo appartiene a quello che è il Program Backlog e il Product Backlog, che trasformano le iniziative di business in azioni concrete.
Chiaramente il focus di interesse è proprio sul secondo quadrante, in quanto gestendo opportunamente le relative attività è possibile evitare che esse si spostino al primo trasformandosi in “urgenze” che vanno a minare la stabilità e il ritmo di lavoro raggiunto.
Il terzo e quarto rappresentano genericamente uno spreco da ridurre (terzo) e da eliminare (quarto). Le relative attività vanno però tenute in costante considerazione perché incidono sulla pianificazione generale. Facciamo un esempio: se non si riesce a sfoltirli, parte della giornata lavorativa, anche se minima, sarà chiaramente dedicata ad essi, per cui non sarà possibile stimare il tempo di una iterazione basandosi sulle canoniche 8ore lavorative, ma bisognerà ragionare sulle 7ore, o ancora meno, in cui effettivamente ci si dedica ai work item del primo e del secondo quadrante.
La difficoltà intrinseca di questo framework è, chiaramente, quella di riuscire a distinguere tra urgenza e importanza e, come tutte le cose, il miglior modo per affinare le proprie capacità è quello di esplorare e procedere sul campo.
Stay tuned!
