Introduzione
Nella puntata precedente abbiamo introdotto il tema dell’Agile Portfolio: abbiamo visto a cosa serve — a capire chi può fare cosa, che impatti ha se arriva una nuova richiesta o se devo spostare qualcosa — e quali sono le principali fasi della sua creazione.
L’Agile Portfolio permette quindi di controllare il flusso del lavoro all’interno della propria organizzazione. Quante cose stiamo facendo? Chi le sta facendo? Chi ha tempo e competenze per fare il prossimo progetto in arrivo nel backlog? Cosa succede se spostiamo sul Progetto345 il TeamABC che ora sta lavorando al Progetto123? Quali sono gli impatti sugli altri progetti? Quali i possibili ritardi? Che tipo di conseguenze economiche potremmo avere? Qual è il progetto che ha la maggior flessibilità e che quindi può sopportare meglio uno slittamento temporale o un blocco momentaneo?
Questo mese proveremo a fornire alcuni strumenti per rispondere a queste domande; in particolare parliamo di prioritizzazione delle iniziative e di metodi decisionali per stabilire quale sia il team più adatto per svolgere una determinata attività.
Tassonomie sui progetti
L’Agile Portfolio Management fornisce una rappresentazione visuale del lavoro, tramite le board e i cartellini, e stimola la discussione fra i vari stakeholders coinvolti nella gestione delle iniziative. Rispetto a una gestione classica del portfolio, in questo caso la declinazione “agile” del portfolio è proprio la presenza di questa discussione“co-creativa”. Non c’è un’entità centralizzata che vigila e controlla e a cui si fanno dei report. La conversazione è fra pari. Le decisioni sono condivise, pubbliche.
Un punto fondamentale è che nel backlog delle iniziative in corso — o prossime future —, ogni progetto dovrebbe essere classificato in base alla priorità, il ROI economico, lo slack time (flessibilità economica), il ritorno in termini di miglioramento sistemico (quanto posso imparare, quanto posso crescere, quanto questo progetto rappresenta un investimento per la mia organizzazione) e altro ancora.
Queste considerazioni dovrebbero dar vita a quello che si chiama tassonomia dei progetti, in cui ogni iniziativa viene valutata sulla base di alcune metriche: solo in questo modo si può poi procedere alla prioritizzazione e si è in grado quindi di rispondere alla domanda fondamentale: “qual è il prossimo progetto da mettere in lavorazione?”. Oppure, “se le risorse scarseggiano, cosa possiamo fermare o rallentare?”.
Metriche condivise e discussione positiva
Per procedere a questo ordinamento si cerca di utilizzare metriche che siano condivise fra tutti e di procedere alla misurazione usando tecniche qualitative piuttosto che quantitative, prediligendo la stima comparativa al posto della valutazione esatta, che non sarebbe possibile.
In questo processo è importante che la valutazione sia condivisa ancor più che sia esatta. Ha valore il processo di discussione e condivisione, più che il valore assolutamente preciso del risultato. In tal senso, noi optiamo per una valutazione parametrica, pesata, agganciata a numeri discreti, distribuiti possibilmente su una scala non lineare… Ci ricorda qualcosa? Se dico Fibonacci, Planning Poker e stima delle storie utente? Matrice ponderata?
Anche in questo caso sono importanti anzitutto la discussione e il confronto, più che il valore numerico finale.
Alcuni esempi
Durante i nostri esperimenti abbiamo provato alcuni strumenti e tecniche che stiamo raccogliendo e mettendo a punto in un tool strutturato. Il tutto si basa su delle card progetto in cui sono riportate alcune metriche comuni, lasciando comunque spazio alla possibilità di aggiungerne altre, proposte dal team di lavoro.
La card costruisce una sorta di Score Balanced Matrix dove anche i pesi sono decisi in modo condiviso dal gruppo. Per peso si intende un valore che esprime l’importanza della metrica in esame. La matrice che ne risulta rappresenta di fatto un sistema di valutazione ponderato (ne abbiamo parlato in passato in [1]), ed è una semplificazione [2] della GE-McKinsey Matrix [3].
Matrice pesata
Ecco un esempio di un’ipotetica Score Balanced Matrix in cui si mettono a confronto differenti opzioni.
Nel nostro caso, ogni cartellino/iniziativa porta la valutazione di un progetto sulla base dei KPI e dei pesi scelti. Ogni progetto, quindi, riceve un punteggio che esprime la sua “importanza”.
Weighted Scored Matrix
Si può replicare lo stesso ragionamento usando un’altra misurazione che tenga presenta l’urgenza del progetto, anche se in questo caso il valore è facilmente calcolabile valutando la vicinanza del progetto e sottraendo la flessibilità delle date (slack time).
Si ottengono quindi due misure associate al progetto: importanza e urgenza.
Matrice di Eisenhower
A questo punto possiamo usare un approccio stile matrice di Eisenhower utilizzata nella gestione del tempo per classificare le molte attività che una persona o un gruppo deve svolgere.
La versione adattata della matrice di Eisenhower dà luogo a un quadrante cartesiano in cui le attività sono ordinate in base all’urgenza (aspetto temporale) e all’importanza (valore).
Questo diagramma permette di avere una visione sulla priorità dei progetti in modo da aiutare a decidere cosa mettere in alto nel backlog delle iniziative, cosa può permettersi di aspettare oppure cosa possiamo spostare se arriva una nuova attività molto importante.
Una nota sulle metriche
La decisione dei valore dei pesi e dei punteggi non sono lasciati totalmente alla libertà del team. Si possono per esempio imporre alcune policy sui punteggi — come nella GE-McKinsey Matrix — per evitare, caso tipico, che tutti i progetti finiscano per avere lo stesso punteggio e che quindi alla fine siano tutti urgenti e importanti.
Classificazione sui team
Ora che abbiamo trovato un modo per capire qual è la priorità sulle cose da svolgere, ci serve un’altra informazione importante. Se il Progetto123 nella pila delle todolist è il prossimo da mettere in lavorazione, dobbiamo decidere quale team è il candidato ideale per svolgere questo progetto.
Qui entrano in azione due valutazioni: competenze — tecnologiche e/o di dominio — e performance del team, nel senso che probabilmente si vorrebbe sempre assegnare i progetti importanti e urgenti ai team che performano meglio.
Performance e competenze, in senso ampio, sono argomenti centrali nel funzIonamento delle organizzazioni e nella corretta riuscita dei progetti che esse intraprendono. Si tratta di un ambito in cui il moderno approccio Agile HR sta facendo notevoli passi in avanti in questi ultimissimi anni.
In questo articolo non affrontiamo il tema delle performance, ma ci concentremo sul come identificare e far fruttare al meglio le competenze necessarie per sviluppare il prodotto con successo.
Le competenze necessarie in un progetto
Detto questo, la classificazione di un gruppo di lavoro in funzione delle proprie competenze e delle attività che è in grado di svolgere dovrebbe partire dal tipo di lavoro che è necessario svolgere. Per questo può essere utile una scomposizione macroscopica come quella riportata in figura 5.
Volendo, si potrebbe visualizzare il peso di ogni competenza necessaria, per esempio in funzione dell’effort; si potrebbe quindi estendere il diagramma introducendo una dimensione in modo del tutto qualitativo (figura 6).
Matrice delle competenze
A questo punto, in modo del tutto autogestito, il team valuta il proprio livello di conoscenza e padronanza — o anche capacità di effort — sulle competenze individuate precedentemente. Nasce la cosiddetta matrice delle competenze (Skill Matrix): il punteggio (da 1 a 3) rafforzato dal codice colore, indica quanto quel team si sente pronto o capace di lavorare con la competenza relativa.
A questo punto si dispone di uno strumento che consente di decidere quale sia il gruppo più idoneo per svolgere un determinato compito.
Figura 8 – Il processo di assegnazione team–progetto è piuttosto semplice.
Conclusione
Quello che abbiamo visto in questo articolo è il processo che serve per poter, da un lato, classificare e prioritizzare le iniziative in essere, dall’altro, valutare le competenze dei team e quindi la loro capacità di svolgere o meno un lavoro.
Un aspetto che volutamente non abbiamo considerato è la crescita delle competenze del team: non ne abbiamo parlato qui, ma si tratta di un punto fondamentale nell’agilità, e per il ruolo del manager in una organizzazione agile. Un gruppo che esprima un punteggio basso nello svolgere un determinato compito dovrebbe essere oggetto di un adeguato processo di cura e supporto per abilitare la crescita e il miglioramento continuo.
Non è oggetto dell’Agile Portfolio Management, anche se questo abilita interessanti considerazioni sul tema “crescita delle persone”.
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.