Metodologia Agile: il Project Management con una marcia in più

Metodologia Agile: ne parlano tutti. A volte anche a sproposito. Ascoltiamo dalla voce di un project manager la verità su questo termine così di moda.
Condividi:

Metodi agili, metodologia agile, agile development, agile project management persino agile marketing e agile sales.
Quante volte avete sentito la parola "agiàil" e vi siete chiesti: ma cos'è sta roba? Servirà a qualche cosa oppure è solo la moda del momento?
Oggi ne parliamo con un amico del podcast di lunga data, una delle persone che da subito ha dato fiducia a questo progetto partecipando sin alle prime puntate.
Ascolta "Cos'è l'Agile: impariamo a mettere il turbo al Project Management con Piero Tagliapietra" su Spreaker.
Ti è piaciuta la puntata? Dillo su Twitter.

Ascolta il podcast dove preferisci

Premi subscribe (è gratis!) utilizzando la tua app preferita.

La puntata di oggi avrà come ospite Piero Tagliapietra.
Per chi non conoscesse Piero Tagliapietra, Piero vive nella gestione dei progetti unendo il suo ruolo di Strategist (trovare le soluzioni) a quello di Project Manager (per realizzare quanto deciso) creando le giuste condizioni perché il team possa esprimere il suo pieno potenziale.
A Piero piace proprio il suo lavoro perché gestire bene i progetti significa avere persone felici, maggior valore per i clienti e, in generare, migliorare il mondo.
Buona lettura o buon ascolto.

Metodi Agili - Piero Tagliapietra

Parliamo di metodologie? Io sento spesso parlare di Agile. Scusa, ma cos’è sto Agile?E poi come cappero si pronuncia? 😉

Allora: partiamo dalle cose semplici. Normalmente si parla di agiàil per indicare due elementi: da un lato una filosofia (legata più al business e all’azienda) e dall’altro una famiglia di metodologie (connesso quindi un con la gestione dei progetti). Diciamo che si inizia a sentirne parlare oggi, ma le radici sono piuttosto vecchie (se guardiamo ad alcune radici possiamo andare agli anni 80 e ancor più indietro se pensiamo al lean): diciamo che uscendo dal mondo software siamo vicini al “picco delle aspettative pompate” (se usiamo come riferimento il Gartner Hype Cycle)

Dovendo sintetizzare più la parte filosofica tenderei a dire che alla base di Agile (o Metodologie Agili) ci sono tre grandi principi:

  • bisogna fare le cose giuste e generare valore
  • le persone sono al centro del progetto (è il team a generare valore per il progetto)
  • i progetti cambiano e bisogna accettare il cambiamento

Tendenzialmente ti direi che Agile è più complesso rispetto ad altri sistemi poiché:

  • innanzitutto è una famiglia di metodi (come ad esempio Scrum, uno dei framework più famosi, ma poi abbiamo XP, Extreme Programming, TDD, Test Driven Development, FDD, Feature Driven Development) dove spesso rientra anche il Lean (data la vicinanza di principi tra Agile e Lean)
  • secondo perché Agile parte da un approccio empirico e si è chiesto: come posso creare un modo per creare qualcosa che funzioni per tutti? Semplice, non è possibile. Posso dare principi, linee guida, indicazioni: ma poi praticamente è la realtà specifica che deve identificare cosa funziona per il suo ecosistema specifico.

Quindi purtroppo non è come per i mobili IKEA dove hai delle istruzioni operative da seguire, ma devi prende i principi e calarli nella realtà aziendale (diciamo che sono principi di buon senso).

Che differenza c'è fra Agile a Cascade?

Sono due metodologie e potremmo in realtà distingue le due famiglie mettendo da un lato i metodi Predittivi (come Cascade) e dall’altro quelli Adattativi (dove troviamo approcci Iterativi e Incrementali).

La differenza tra i due metodi si sintetizza rapidamente:

  • da un lato prima di iniziare a lavorare vogliamo sapere esattamente che cosa si deve fare, come, quando etc. Una volta definito il tutto non si cambia più nulla e si inizia a realizzare il progetto seguendo varie fasi. Cambi idea? Le cose che avevi detto erano sbagliate? Spiace, ormail il progetto è partito.
  • d’altra parte c’è l’idea che su molti progetti, soprattutto all’inizio, le idee non siano proprio cristalline e quindi che sia opportuno partire dalle cose certe e poi vedere, una volta che si ha qualcosa in mano, la strada da intraprendere. Con gli approcci Iterativi ho un miglioramento costante inglobando rapidi feedback nel mio ciclo di lavoro, con quelli Incrementali consegno piccoli pezzi finiti.

Diciamo che entrambi hanno punti di forza e debolezza, ma spesso nei progetti legati al digital, dove l’incertezza regna sovrana, Agile consente di ridurre i rischi di progetto sia per il cliente (che non deve aspettare la fine della cascata) che per chi lavora (dato che può capire rapidamente se il progetto sta andando nella giusta direzione e generando valore per il cliente).

Sono concetti che poi il metodo Lean Startup ha portato all’estremo: MVP, Minimum Viable Product. Invece di fare tutto il tuo prodotto meraviglioso parti con una prima versione, controlla, migliora, cresci (volendo essere pignoli, pignoli è il Ciclo di Deming degli anni 40, il PDCA, estremizzato).

Due anni fa un fornitore propose a un'azienda che seguivo un preventivo fatto secondo la metodologia agile. Praticamente il prezzo non era certo. Il cliente pagava non per il risultato ma per dei loro "sforzi di lavoro". Mi ricordo che il cliente continuava a domandare quanto avrebbe speso e loro ripetevano che dipendeva da lui e da quanti "sforzi" di x giorni di lavoro gli avrebbe fatto dare.

Alla fine il cliente, per non iscriversi ad un corso universitario lì mandò a quale paese. Queste metodologie quanto è bene che sconfinino in altri ambiti?

In generale credo che volessero essere pagati a “sprint”, cicli di lavoro. Dovendo semplificare (e riprendendo quanto detto sopra) è parte del metodo incrementale: ogni x giorni (o settimane) io ti consegno una cosa perfettamente finita che tu puoi controllare e tu mi paghi quella cosa finita (per cui è anche un modo per ridurre i rischi finanziari).

Per rispondere partiamo da due domande: quanto ci vuole a fare una casa? e un sito? Ovvio che con queste informazioni è difficile fare un preventivo che vada oltre una cosa tipo “tra zero e infinito”.

Vediamo quindi che, sempre per amor di semplificazione, Agile si trova perfettamente a suo agio nei progetti incerti dove nemmeno il cliente sa cosa vuole esattamente: lo scopriamo insieme. È un concetto importante della filosofia Agile: il rischio è condiviso tra fornitore e cliente, lavoriamo insieme per fare qualcosa che generi valore per te (non perché abbiamo deciso che il progetto era fatto da A,B e C).

Ovvio che tra “non facciamo stime” e “il progetto non cambia” ci sono delle scale di grigio e Agile ha tutta una serie di indicazioni su stime e pianificazione. Io posso dare una dimensione indicativa all’inizio del progetto che, man mano andiamo avanti, potrò raffinare: da questo punto di vista se vogliamo Agile ha fatto proprio il principio d’incertezza di Humprey: un requisito diventa noto una volta che l’utente finale l’ha provato e usato.

Se vogliamo questa è uno degli scogli dell’adozione di Agile: bisogna che ci siano collaborazione e condivisione del rischio, ma è un percorso, non un punto di partenza. Dato che “solo i Sith vivono di assoluti” non bisogna usare solo e sempre Agile: in una fase incerta è possibile usarli, quando il cliente è “sicuro” possiamo passare ai predittivi.

Dal mio punto di vista anche questo è parte della filosofia Agile: Agile vuole creare il maggior valore possibile. Per farlo serve una fase con Cascade? Facciamolo. “Da domani facciamo tutti Scrum a qualunque cosa” lo vedo come il perfetto approccio per Wile Coyote.

Come faccio a capire quale metodologia è più adatta al lavoro del mio team?

Tendenzialmente direi “quella che funziona”, ma potrebbe essere troppo vaga. Partiamo da una riflessione: il project manager gestisce progetti? In generale possiamo già dire che il progetto è una cosa vuota: sono le persone a creare il progetto e quindi il project manager si occupa di fare in modo che le persone si trovino nella condizioni per fare il miglior progetto possibile.

Se siamo d’accordo con questa idea (cioè che il PM da persona che batte sui tamburi è un allenatore, un abilitatore delle potenzialità del team) ecco che già siamo verso la filosofia Agile e Lean. Calcola che il primo punto dell’Agile Manifesto (un documento formalizzato nel 2001) recita “le persone e le interazioni hanno più valore di strumenti e processi”.

Si tratta ovviamente non di metodo, ma di cultura aziendale (e forse questo è lo scoglio maggiore per l’adozione dell’Agile) ed è una sorta di consapevolezza che forse sta iniziando a diffondersi.

Torniamo alla gestione del progetto: come si gestisce il processo di delega? Non è facile fidarsi e contare sui propri collaboratori: qui si apre forse anche la questione dei talenti...ma sulla dedica credo caschino un sacco di persone, perché di fatto non ci si fida. Tu che dici?

Partiamo da due concetti base: la delega non è mai totale (in bianco) e non si delega tutto. Anche qui possiamo parlare più di un processo, di un percorso che di un bottone acceso/spento.

In generale, per una buona delega, ci vogliono la giusta comunicazione e un clima di collaborazione in modo che le persone sappiano cosa devono fare e in caso di dubbio non si facciano però scrupoli a chiedere e approfondire. La delega non è “fai tu, io me ne lavo le mani”, ma “credo tu possa farlo nel migliore dei modi, se poi hai bisogno sono qui”.

Ovvio che tutto questo si basa sulla comunicazione: se non sai cosa fare, cosa ha valore per il cliente il risultato non può che essere un “ecco, non posso mai delegare perché il team fa casino”. Chiarezza e comunicazione sono alla base. Se vuoi è qualcosa alla base di Scrum (che abbiamo già citato) e il cui nome è legato allo sport: è la mischia nel Rugby.

Nel fango, abbracciato ai compagni, c’è li il PM che ti dice cosa fare? No, ascolti, ti adatti, aiuti i compagni: questo è la base dell’Agile. Avere team determinati che sanno cosa fare (ovvio che idealmente è un team selezionato, nella realtà hai delle persone far diventare un team).

Inoltre credo  che spesso sia difficile accettare che ognuno di noi lavori in maniera diversa e qualcosa fatto da un’altra persona non sarà mai come lo avremmo fatto noi (ma se non lo accetti non credo si faccia molta strada).

Sicuramente è anche in questo caso un tema di cultura aziendale e di indole personale: è importante ribadire ancora che si va verso la delega al team che deve essere formato, aver fatto esperienza etc. Non lanci progetti a caso sperando vada bene (non succede).

Come si costruiscono allora le procedure e le modalità per comunicare all'interno del team che porta avanti un progetto?

Nel corso del tempo ho trovato due cose particolarmente efficaci:

  • la prima è lo Stand Up Meeting (o Daily Scrum) ovvero un momento di confronto rapido dove ci si aggiorna, anche informalmente sulle cose da fare. In questo caso secondo me è il principio ad essere fondamentale: darsi dei tempi e momenti fissi d’incontro (anche non necessariamente giornalieri: ravvicinati quanto serve). Per gli appassionati di crossfit si può fare anche in Plank (così la riunione dura meno) mentre per gli altri si può fare in piedi (senza computer in modo da parlare e ascoltare) e in cinque minuti sappiamo tutto quello che serve per affrontare la giornata o i giorni successivi
  • la seconda è chiedere alle persone cosa vogliono fare, dove vogliono crescere e soprattutto abituarle a criticare i colleghi. Si tratta di una cosa non facile perché c’è tutto un modo di fare le critiche: legate a una situazione specifica, al lavoro e non alla persona… e questo aiuta tantissimo a fare in modo che le persone costruiscano un ambiente sicuro nel quale si sentano liberi di fare domande e introdurre cambiamenti nel progetto (in modo da generare valore)

Quali sono le competenze richieste a chi gestisce progetti?

Tendenzialmente oggi un buon Project Manager deve mettere insieme due aspetti:

  • da un lato delle competenze in ambito di Project Management come la conoscenza dei principi base di gestione di un progetto, stime e pianificazione, alcuni metodi e strumenti (dal Gantt a Scrum) e piattaforme (da Asana a Trello passando per MS Project)
  • dall’altro, a mio avviso ancora più importante, sono le capacità, cioè quelle soft skills fondamentali per gestire il team (o forse più correttamente far esprimere il pieno potenziale al team). E qui iniziamo a parlare di Leadership, Coaching, Negoziazione, People Management etc.

Ovvio che se passiamo dal gestire il progetto (consegnare A, milestone B in arrivo, delivery, delivery, delivery, una sorta di Dalek PM) al gestire le persone prima di tutto, per me, il lavoro del PM diventa bellissimo (cosa c’è meglio di un team che diventa autonomo e lavora benissimo?) e il ruolo però passa più a quello di allenatore.

Pensa, in Scum (uno dei framework più famosi) non c’è il PM, ma una figura che si chiama Scrum Master: ecco, il suo ruolo (tra gli altri) è quello di far lavorare bene il team, senza però aver potere su di loro. Ispirare, risolvere conflitti, servant leadership… fantastico.

Parliamo di strumenti: cosa serve a un project manager per far bene il suo lavoro?

Ti direi prima di tutto fiducia (la famigerata sponsorship del management) unita alla volontà di cambiare e generare valore: chi fa Agile vuole migliorare il mondo e risolvere problemi (si dice ridendo che Agile non funzioni in Italia perché rende manifeste le inefficienze e le aziende poi non saprebbero cosa fare dato che non vogliono risolverle). Poi, anche qui, dipende.

Personalmente sono un fan della carta e delle cose tangibili (vuoi mettere la soddisfazione di toccare qualcosa per noi che facciamo “digital”?) perché rendono evidenti a tutti il lavoro (perchè fare un SAL - stato avanzamento lavori - quando ho sempre tutto davanti agli occhi?), le persone sono sempre allineate/consapevoli e infine si prendono degli impegni in pubblico.

Un bel foglio o una bella lavagna con le cose da fare sono fantastici: ovvio che anche qui bisogna mediare con il team e la location. Nulla vieta di usare un tool e oggi più o meno tutti hanno le stesse funzioni.

Cosa potresti suggerire a chi ascolta per poter iniziare in progetti con il piede giusto: ci dai una ricetta che possiamo applicare da domani? C'è qualche esercizio o azione specifica che vuoi suggerire loro?

Ti direi tre cose: ascoltare, chiedere e parlare. I progetti spesso falliscono perché “pensavo volessi questo e non ti ho disturbato” oppure “pensavo lo facessi tu” o “ma io credevo fosse finito”. Ridurre l’incertezza è forse il primo elemento importante per migliorare la gestione dei progetti.

Un piccolo esercizio è la creazione ad esempio della scheda di progetto (che può andare dalle tre righe alle n-pagine nel quale scriviamo:

  • cosa vuole il cliente?
  • che cosa è importante per il cliente?
  • chi fa cosa?
  • cosa dobbiamo fare?
  • cosa vuol dire finito?

Già questi cinque punti possono aiutare il team a lavorare meglio e a non perdersi i pezzi. A volte sembra una perdita di tempo, ma se ritorniamo alla delega, questo è un ottimo strumento,

Se so che per il cliente è importante “avere una soluzione veloce” il team verrà a chiedere se scegliere l’opzione A che è lenta o l’opzione B che è veloce? Probabilmente verranno già con la soluzione implementata perché sanno cosa fare.

Aiutaci a far crescere il podcast!

Ti è piaciuta la puntata di oggi? Lascia la tua recensione su iTunes e iscriviti al podcast.

Se ascolti MERITA BUSINESS PODCAST su Stitcher o altre piattaforme puoi lasciare la tua recensione seguendo queste istruzioni. Grazie!

Fai conoscere MERITA BUSINESS PODCAST ai tuoi follower su Twitter!
Condividi il podcast

Note della puntata

Se vuoi saperne di più su Piero Tagliapietra puoi iniziare dal suo sito PieroTaglia.net
Se invece vuoi leggere il libro che Piero a scritto sull'influencer marketing puoi acquistarlo su Amazon.
Inoltre puoi trovare Piero praticamente su tutti i social. Comincia a seguirlo da LinkedIn, Facebook e Twitter.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

- 12 Febbraio 2024

Social Media Manager: serve o non serve?

Molti imprenditori si lamentano di non avere risultati dai social. Cerchiamo di capire come si possono approcciare per fare in modo che rendano.
- 5 Febbraio 2024

Creator Economy: il WEB3 la cambierà per sempre.

Come il web3 è destinato a trasformare la Creator Economy. Anche se ci vorrà tempo...
- 29 Gennaio 2024

Crypto YouTuber: la storia di Davide Vasco

La storia di come Davide Vasco ha aperto il suo canale YouTube raccontando errori e prospettive dei suoi investimenti in crypto.

ENTRA NELLA COMMUNITY
Iscriviti alla newsletter e ricevi l'invito al Gruppo riservato agli ascoltatori del podcast.

crossmenu