Log in



Categories » ‘Project Management’

Scrum applicato in azienda: quale contratto per un progetto agile

July 14th, 2021 by

Mi viene sempre chiesto quale contratto fare per progetti che utilizzano la metodologia Scrum: in questo video provo a dare una risposta a questo quesito. Insieme a questo vi consiglio di riguardarvi il video in cui spiego perché in un progetto Scrum il cliente non avrà il 100% dei requisiti richiesti. Buona visione!

Scrum applicato in azienda: il planning poker

May 18th, 2021 by

In questo video ho fatto qualche esempio di planning poker, lo strumento più usato in scrum per fare le stime per analogia attraverso gli story point. Nel video ho utilizzato le carte da planning poker di Praxis Framework, che ringrazio.

Scrum applicato in azienda: story point e stime per analogia

April 13th, 2021 by

Uno dei concetti meno compresi e forse per questo meno applicati, ma secondo me utili quando si lavora in modalità agile.

Scrum applicato in azienda: il cliente non avrà il 100% dei requisiti richiesti

March 11th, 2021 by

Lavorare secondo un vero paradigma agile significa per il cliente accettare che non otterrà il 100% di quello che ha richiesto. In questo video di 5′ vi spiego perché. Buona visione!

Scrum applicato in azienda: il concetto di Velocity di un team agile

February 1st, 2021 by

Riprendo un concetto fondamentale già spiegato in un articolo precedente e lo ripropongo in un breve video di 5′. Buona visione!

AgilePM (e Scrum) applicato in azienda: l’assegnazione dei ruoli

December 9th, 2020 by

Ho ripreso lo stesso spunto del video precedente e ho registrato questa spiegazione (7′) di come assegnare i ruoli di AgilePM (e di conseguenza i ruoli di Scrum), in una struttura organizzativa gerarchica tradizionale. Buona visione!

Scrum applicato in azienda: i ruoli

November 3rd, 2020 by

Prendendo spunto da una attività che mi trovo a fare spesso in azienda, ho registrato questo breve video (10′) per fornire uno spunto su come applicare Scrum, che nasce con un’organizzazione piatta, ai progetti di una struttura organizzativa gerarchica tradizionale. Buona visione!

Sul concetto di Velocity di un team agile

April 8th, 2020 by

Chi ha familiarità con le modalità di lavoro agile e i suoi vari framework di riferimento, dovrebbe aver sentito parlare del concetto di Velocity, che è la principale metrica di riferimento che viene utilizzata per misurare quanto lavoro un team di sviluppo può completare con successo nel corso di un intervallo di tempo fisso detto Sprint. Ma sappiamo cosa significa davvero misurare la Velocity di un team?

Il termine, per assonanza, tende a essere sempre tradotto con “velocità” per cui la metrica nella percezione comune diventa la “velocità del team e la sensazione è che il team debba ricercare la propria efficienza, che però per il modo di pensare agile è un controsenso.

In un contesto di lavoro agile infatti, quale per esempio Scrum, quello che importa non è tanto l’efficienza del team quanto la sua capacità di permettere al proprio cliente, in Scrum rappresentato dal ruolo del Product Onwer, di ottenere i risultati che creano valore per il cliente stesso.

Questi risultati che creano  valore in inglese sono detti Outcome e infatti si dice che le metriche per misurare un team agile devono essere Outcome based.

Per fare un esempio semplice ma efficace del concetto appena espresso, in un contesto agile a nessuno importa quanto un team sia efficiente a piantare chiodi o ad avvitare viti, quello che importa è la capacità di appendere quadri nel modo desiderato dal proprio Product Owner entro un tempo ragionevole previsto dal team e utile al Product Owner.

Siamo allora sicuri che “velocità” sia la traduzione corretta per il termine Velocity? Anche perché chiunque conosca un inglese anche elementare sa che normalmente “velocità” si traduce con “speed”. E quindi?

La spiegazione sta in un’altra delle mie passioni sportive, la barca a vela. Perché la parola Velocity in realtà è un termine nautico con un significato ben preciso e tutto mi fa pensare che chi ha adottato questo termine per i team agili abbia voluto utilizzare una metafora sportiva e in particolare velica, che però è risultata talmente sottile che quasi nessuno la ha colta.

La velocità di una barca a vela si misura con due grandezze: la velocità propria della barca nell’acqua (Speed Through Water – STW) che è quella che si percepisce navigando e la velocità effettiva sulla superficie terrestre (Speed Over Ground – SOG) che è quella che ci dice quanto la barca di sta effettivamente spostando. Senza qui addentrarsi in spiegazioni tecniche, le due velocità sono correlate ma non sono quasi mai uguali per via delle dinamiche dell’acqua. Sempre per fare un esempio semplice, si pensi a una barca che naviga contro corrente in un fiume dove c’è una corrente pari alla velocità della barca stessa; la STW sarà positiva, la barca rispetto all’acqua si muove, la SOG sarà nulla, rispetto alla superficie terrestre la barca è ferma.

La STW ci dice quanto rapidamente la barca si muove sull’acqua, quindi ci da un’indicazione di quanto è efficiente il moto della barca, la SOG ci dice quanto rapidamente la barca si muove sulla superfice terrestre, quindi ci da un’indicazione di quanto è efficace il moto della barca. Da notare che entrambe in inglese sono Speed, nessuna delle due è Velocity, che è un concetto ancora diverso. Cosa è la Velocity allora?

Nel disegno ho riportato una spiegazione un po’ semplificata del concetto velico di Velocity.

Una barca non può muoversi contro vento, al massimo può tenere un angolo di circa 45° rispetto alla direzione del vento. Se si vuole quindi raggiungere un obiettivo che sta controvento, occorre bordeggiare, ovvero ‘zigzagare’ come in figura con angoli di 45° rispetto alla direzione del vento e così facendo ci si avvicinerà al punto obiettivo. Quello che ci interessa non è né la STW, né la SOG ma la velocità con cui la barca si avvicina al punto obiettivo, che in inglese viene chiamata appunto Velocity Made good on Course (VMC), che è la componente della SOG che ci sta avvicinando al punto obiettivo.

Quindi il sottinteso di chi ha scelto il termine Velocity è che il team deve misurare la propria capacità relativa di avvicinarsi al punto obiettivo (che fuori di metafora è il risultato che crea valore per il Product Owner) e non tanto la propria efficienza di azione intrinseca (Speed Through Water – STW) ma nemmeno la propria efficacia assoluta (Speed Over Ground – SOG), perché per raggiungere l’obiettivo del Product Owner il team deve saper combinare la propria efficienza ed efficacia con una strategia che permetta di impiegare al meglio gli elementi propulsivi disponibili (il vento) per riuscire a raggiungere l’obiettivo nel tempo più breve possibile, ma senza compromettere il risultato. E chi ha esperienza di navigazione a vela sa bene che questa strategia di impiego degli elementi propulsivi disponibili è l’elemento che fa la differenza tra un buon velista e un principiante ed è più decisiva e importante rispetto a efficienza ed efficacia del mezzo, perché se si sbaglia il percorso o non si capisce come gira il vento e si finisce controvento, la barca si ferma.

Fuori dalla metafora velica, si usa quindi il termine Velocity perché non importa quanto il team agile sia efficiente e nemmeno quanto sia efficace, ma quanto sia complessivamente abile nel progredire il più rapidamente possibile verso gli obiettivi che creano valore per il cliente.

Organizzazione personale con GTD® integrata alla gestione dei progetti con PRINCE2®

February 10th, 2019 by

Utilizzo ormai da qualche anno il metodo GTD – Getting Things Done – per la mia organizzazione personale ed è uno degli strumenti che più mi ha permesso di dare ordine alla mia vita personale e professionale. Per questo ho fatto anche molte riflessioni per riuscire a integrarlo sempre più con PRINCE2 che è da ormai molti anni la mia metodologia di riferimento per la gestione dei progetti aziendali.

Uno degli aspetti che accomuna tutte le metodologie moderne di management, quale che sia il loro campo di applicazione, è l’enfasi sulla necessità di mettere bene a fuoco per ciascuna iniziativa intrapresa quelli che sono i risultati finali (outcome in inglese) e i benefici attesi in termini di valore generato. Ritroviamo concetti simili in PRINCE2 e GTD, ma anche per esempio in AgilePM, ITIL, Praxis Framework, Scrum e, pur se in modo più sfumato, in PMBoK.

Nel corso GTD Mastering Workflow level 2 viene approfondita la gestione dei progetti e viene suggerito un modello, il Natural Planning Model, molto efficace per la rapida e corretta impostazione di un progetto. Il modello consiste nei cinque passi come in figura, che partire dalla definizione dello scopo ultimo dell’iniziativa (purpose – rispondendo alla domanda perché facciamo il progetto?) e dei principi applicabili (principles – i vincoli o le regole irrinunciabili a cui dobbiamo conformarci) ci accompagna fino alla definizione delle prossime azioni visibili (next actions) da svolgere per avvicinarci al nostro risultato finale (outcome).

PRINCE2 dal canto suo prevede un processo di Avvio di un progetto e un processo di Inizio di un progetto che hanno l’obiettivo di permettere la verifica progressivamente più approfondita della giustificazione del progetto, arrivando a definire la direzione e l’estensione del progetto stesso. In particolare il processo di Avvio ha l’obiettivo di verificare se ci sono i prerequisiti per iniziare il progetto, documentati nel Project Brief, mentre il processo di Inizio ha l’obiettivo di stabilire le solide basi, documentate nella Project Initiation Documentation (PID).

Provando a sovrapporre il Natural Planning Model ai due processi di Avvio e Inizio di PRINCE2 si vede bene come il modello di pianificazione suggerito da GTD possa essere un valido supporto per l’efficace impostazione di un progetto condotto con PRINCE2 e per alimentare Project Brief e Project Initiation Documentation con i loro contenuti fondamentali. Viceversa alcune tecniche utilizzate in PRINCE2, in particolare lo sviluppo di Product Breakdown Structure e Product Flow Diagram possono supportare i passi di Brainstorm e Organizing del Natural Planning Model.

Nell’immagine ho indicato per ciascuno dei cinque passi del Natural Planning Model quali sono i capitoli corrispondenti da compilare all’interno dei template di PRINCE2. Il risultato conferma la coerenza tra i due approcci e la possibilità di un loro utilizzo integrato.

Imparare dalle lezioni e migliorare la gestione dei progetti

January 8th, 2019 by
«Io non perdo mai. A volte vinco, altre imparo»
Nelson Mandela
Uno degli aspetti che viene ripreso da tutte le metodologie di gestione dei progetti ma che spesso viene trascurato a livello applicativo è quello della gestione delle cosiddette lezioni apprese. Più o meno in tutti i contesti in cui mi trovo ad operare si fa qualcosa, ma è abbastanza raro trovare chi è disposto a utilizzare un metodo strutturato di apprendimento dall’esperienza. E a mio avviso un metodo strutturato di apprendimento dall’esperienza non può prescindere dal poter disporre di misure sulle performance di progetto.
Una best practice in tal senso la prendo quindi in prestito da ITIL e dal suo approccio CSI – Continual Service Improvement – approccio che mette la giusta enfasi sulla necessità di misurare i risultati di una qualsiasi attività per poter individuare i punti di forza su cui fare leva e i punti di debolezza da migliorare, senza mai perdere di vista il valore che ciascuna attività apporta all’azienda. L’approccio CSI – basato sul ciclo di Shewhart, ripreso da Deming – è stato pensato per il miglioramento dei servizi ma nella mia personale esperienza si può applicare altrettanto efficacemente ai progetti.
 
L’approccio CSI si compone di sei fasi, analizziamole alla luce dell’esigenza di apprendimento dall’esperienza nei progetti:
Fase 1: chiarire la visione, tenendo in considerazione la missione, gli obiettivi di breve e lungo termine, garantendo che tutti ne abbiano una comprensione comune. La visione rappresenta uno stato aziendale desiderato a medio termine e anche le modalità di gestione dei progetti devono contribuire alla sua realizzazione.
Fase 2: valutare la situazione attuale e stabilire una baseline, un punto di riferimento, di dove esattamente si trova attualmente l’organizzazione e, nel nostro specifico, il nostro approccio alla gestione dei progetti. Questa fase richiede delle misure e può essere impegnativa. L’aspetto fondamentale è l’onestà intellettuale, le misure possono essere di tipo qualitativo ma è essenziale essere onesti, non raccontarsela, motivo per cui un supporto esterno può essere utile. Per esempio l’utilizzo di un Modello di Maturità come quello fornito gratuitamente da Praxis Framework può aiutare a effettuare una valutazione sostanzialmente oggettiva.
Fase 3: definire i passaggi verso la visione in base alle priorità di miglioramento e stabilire obiettivi misurabili. Di solito è impossibile, o per lo meno molto difficile, passare direttamente dallo stato attuale a quello desiderato rappresentato dalla visione. Più verosimilmente si porteranno intraprendere azioni di miglioramento che ci faranno fare progressi nella direzione desiderata.
Fase 4: documentare e implementare un piano di miglioramento, facendo riferimento alle best practice per la gestione dei progetti. Ciascuno ha le proprie preferenze, ISO 21500, PMBoK, PRINCE2, AgilePM, Scrum, Praxis Framework sono tutte ricche di spunti e strumenti utilizzabili per il miglioramento. In questa fase è fondamentale mettere in atto azioni concrete di miglioramento a partire dal primo progetto disponibile
Fase 5: monitorare i risultati, utilizzando le misure e le metriche appropriate definite in precedenza. E qui di nuovo il Modello di Maturità di Praxis Framework  ci può fornire una misura oggettiva del miglioramento.
Fase 6: mantenere lo slancio assicurando che i miglioramenti siano integrati e che si vada in cerca di ulteriori opportunità di miglioramento. Per fare questo è importante che l’approccio CSI sia integrato nei processi di gestione dei progetti. Praxis Framework per esempio prevede due momenti in cui tale approccio può essere efficacemente utilizzato, nel Processo di Identificazione del progetto e nel Processo di Chiusura del progetto.
 
Insieme ai colleghi di E-quality abbiamo elaborato un percorso, PM@work, con l’obiettivo di supportare le aziende in questo percorso di miglioramento, in modo molto concreto e operativo.