Chiunque si sia avvicinato (anche solo passando davanti agli uffici di un PM) negli ultimi 10 anni al Project Management ha sentito parlare dell’approccio Agile (pronunciato all’inglese, non come sinonimo di svelto, scattante)
Probabilmente addirittura di “Manifesto Agile” e magari ha persino frequentato dei corsi.
Date queste premesse verrebbe da credere che la “metodologia agile” sia diffusa, e ormai largamente metabolizzata anche negli ambiti esterni a quelli della programmazione (dove nasce).
Dopotutto il “Manifesto Agile” è una “dichiarazione teorica” dei principi di questo approccio le cui basi (l’iterative design) risalgono addirittura al 1957.
Eppure non è così. In molte, moltissime realtà si continua a preferire un approccio “tradizionale” al project management, o in alcuni casi una forma “imbastardita” di agile e waterfall (o quello che maggiormente si avvicina a questa forma).
Perché succede?
Normalmente questo genere di domande vengono liquidate appellandosi ad una naturale reticenza della nostra cultura lavorativa, ad una certa forma di abitudine, o ad una generale diffidenza nei confronti del “nuovo”.
Ma in questo caso specifico non può bastare come risposta, o non può bastare se vogliamo interrogarci (senza la presunzione di avere una risposta) sul perché una metodologia che ha più e più volte dimostrato la propria efficacia, sia ancora considerata “innovativa” nonostante il “Manifesto Agile” abbia ormai più di vent’anni.
Non è davvero una sorpresa.
Se dividiamo il mondo in due grandi gruppi (per amore di semplificazione, e con una buona dose di astrazione), chi lavora con metodologie Agile e chi no, ci rendiamo conto che per questa seconda categoria, il passaggio ad un approccio “agile” può essere difficile.
In alcuni casi, molto difficile.
Adottare un approccio Agile nel Project Management significa mettere in discussione molti dei capisaldi tipici di un approccio standard, che sia mutuato dal waterfall di cui abbiamo già parlato, o che sia frutto di un proprio percorso è indifferente.
L’Agile prevede delle condizioni (poche a dire il vero) ben precise affinché possa funzionare davvero. Alcune di queste condizioni rimandano ai ruoli, altre alla gestione delle tempistiche e le più importanti (a nostro avviso) alla gestione dei tempi/carichi.
La profonda riorganizzazione non solo delle mansioni, ma in termini più profondi della propria mentalità, richiede uno sforzo considerevole, e maggiore è radicata l’abitudine ad un certo tipo di attitudine, maggiore è la difficoltà che si riscontra nell’affrontarlo, questo cambiamento.
Intendiamoci: la metodologia Agile non è la soluzione definitiva ai problemi che un PM si trova ad affrontare.
Non esistono bacchette magiche (neanche nel mondo del Project Management).
Ma è un grosso aiuto. Esiste una sterminata bibliografia, e in realtà anche una storiografia delle applicazioni dell’approccio Agile a partire dalla prima metà degli anni ’70.
Quando ancora questi viveva entro i confini della programmazione è stato utilizzato per condurre il programma spaziale della NASA nel corso degli anni ’70 e i primi anni degli anni ’80, e ancora oggi è la metodologia più apprezzata.
Ma al di là dei meriti sul campo (sicuramente importanti), se dovessimo rispondere alla domanda “perché si dovrebbe provare la metodologia agile?” risponderemmo (in maniera un po’ tecnica, lo ammettiamo) che un approccio che sposta l’attenzione dalla mera consequenzialità dei task ad un modello che permette iterazioni successive di attività, pensato per favorire l’auto correzione delle problematiche e ideato tenendo a mente un’alta flessibilità di utilizzo e di processi è più di un metodo.
È un punto di vista diverso che può mettere in discussione molti dei pilastri di quello che oggi potresti considerare un Project Management ideale.
E se è in grado di metterti in discussione, allora vale la pena provarlo.
ITCore Group Educational può aiutarti. Abbiamo a catalogo un’intera sezione di corsi di formazione dedicati alla metodologia Agile.
Se vuoi saperne di più, contattaci.
Ad hoc
Contatti
