Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

246 gennaio
, anno 2019

Agile goes to Hollywood

IV parte: Gestire iniziative e priorità con l’Agile Portfolio Management

Avatar

Giovanni Puliti

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.

hollywood

Agile goes to Hollywood

IV parte: Gestire iniziative e priorità con l’Agile Portfolio Management

Giovanni Puliti

Giovanni Puliti

  • Questo articolo parla di: Lean/Agile, Organizzazione aziendale, Project Management

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.

Figura 1 – Un esempio di matrice pesata.
Figura 1 – Un esempio di matrice pesata.

 

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).

Figura 2 — La matrice weighted scored (a volte definita “scoring ponderato”).
Figura 2 — La matrice weighted scored (a volte definita “scoring ponderato”).

 

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.

Figura 3 – La matrice di Eisenhower. I numeri rappresentano la priorità che dovrebbe assumere una iniziativa che ricade nel quadrante corrispondente. Prima di tutto le cose importanti e urgenti; poi quelle importanti anche se non urgenti; quelle poco importanti ma urgenti andrebbero delegate (o fatte dopo); infine quelle poco importanti e poco urgenti non dovrebbero essere fatte (o fatte per ultime se c’è tempo).
Figura 3 – La matrice di Eisenhower. I numeri rappresentano la priorità che dovrebbe assumere una iniziativa che ricade nel quadrante corrispondente. Prima di tutto le cose importanti e urgenti; poi quelle importanti anche se non urgenti; quelle poco importanti ma urgenti andrebbero delegate (o fatte dopo); infine quelle poco importanti e poco urgenti non dovrebbero essere fatte (o fatte per ultime se c’è tempo).

 

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).

Figura 4 – La trasposizione della matrice di Eisenhower in quadrante cartesiano dà luogo a un diagramma in cui gli assi misurano importanza e urgenza.
Figura 4 – La trasposizione della matrice di Eisenhower in quadrante cartesiano dà luogo a un diagramma in cui gli assi misurano importanza e urgenza.

 

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.

Figura 5 – Scomposizione del progetto in competenze.
Figura 5 – Scomposizione del progetto in competenze.

 

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).

Figura 6 – Scomposizione del progetto in competenze con relativo “peso”.
Figura 6 – Scomposizione del progetto in competenze con relativo “peso”.

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.

Figura 7 – Skill Matrix dei vari team: i numeri da 1 a 3 (sono possibili anche altre scale) esprimono il grado di conoscenza e padronanza della singola competenza.
Figura 7 – Skill Matrix dei vari team: i numeri da 1 a 3 (sono possibili anche altre scale) esprimono il grado di conoscenza e padronanza della singola competenza.

 

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.

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”.

 

Facebook
Twitter
LinkedIn
Avatar

Giovanni Puliti

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.

Giovanni Puliti

Giovanni Puliti

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.
Tutti gli articoli
Nello stesso numero
Loading...

Agile per le masse?

Uno sguardo d’insieme alle varie declinazioni di “Agile”

7 argomenti per il 2019

Tendenze tecnologiche e non solo

#play14 edizione 2019

Cinque buoni motivi per partecipare

Nella stessa serie
Loading...

Agile Goes to Hollywood

III parte: Il ruolo del manager

Agile goes to Hollywood

II parte: Il tema del valore

Agile Goes to Hollywood

I parte: Quando Agile entra in una megaorganizzazione

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte