In un mondo che cambia devi essere AGILE!

Mettiamo le cose in chiaro, la metodologia contemplata dalla certificazione PMP® è, come dire, la bibbia del Project Management.

PMP® certifica le tue competenze, non le riconosci solo tu o le persone vicino a te, le riconosce un istituto internazionale che è di riferimento nel mondo. Il Project Management Institute (pmi.org).

Ma AGILE è di notevole interesse perché in alcuni contesti, dove il cambiamento è continuo e quasi ingestibile, offre delle soluzioni interessanti, che si stanno diffondendo sempre di più nel mondo del Project Management.

Il Manifesto AGILE dichiara i principi base a cui i diversi approcci come SCRUM, XP si ispirano. Mi piace introdurlo con una mia esperienza diretta:

Nel 2001 eravamo impegnati su un progetto di sviluppo di e-Commerce per un cliente di rilevanza nazionale. Ad un solo mese dal termine il referente lato cliente avanza una richiesta di modifica. La risposta da parte di tutto il Team fu un tassativo NO! Il cliente non la prese bene …

All’epoca utilizzavamo una metodologia di Project Management tradizionale e sequenziale (waterfall), accogliere la richiesta di variazione del cliente ad un mese dal termine avrebbe avuto impatti non trascurabili sul progetto. Oggi, è evidente che per la tipologia di progetto quella metodologia non era adatta.

Fu proprio l’esigenza di avere una metodologia di project management alternativa a quelle tradizionali, più efficace in contesti dove spesso le cose “cambiano”, che spinse 17 professionisti dello sviluppo software a riunirsi nel 2001 per scrivere il Manifesto dei principi AGILE.

Vediamoli.

PRINCIPIO 1

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.

PRINCIPIO 2

Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente. Non importa se la pianificazione nella metodologia classica ha stabilito delle attività che possono cambiare solo con delle richieste formali. Ciò che importa è soddisfare il Cliente, consegnando del software che sia per lui di valore, e consegnarlo subito, a cicli brevi, per farlo verificare quanto prima.

Il focus è il valore per il cliente. Il punto di vista è il punto di vista del cliente.

Gli scenari tecnologici cambiano velocemente, il cambiamento è la normalità ed è accettato, in modo da creare vantaggio competitivo, sempre per il cliente.

PRINCIPIO 3

Consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.

Se il cambiamento caratterizza lo scenario progettuale, non possiamo consegnare versioni di software dopo 6 mesi. I tempi brevi ci consentono di recepire subito l’evoluzione del contesto.

Non solo, ci permettono di capire se quanto sviluppato soddisfa il committente e crea valore per il suo business. Il time box possibile è incluso tra due settimane a due mesi.

PRINCIPIO 4

Committenti (Business People) e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.

Il modo migliore per avere il feedback da chi ha contatti con il Cliente, è averlo vicino. Lavorando fianco a fianco ogni giorno. Se c’è qualcosa da cambiare viene comunicato subito, non si perde tempo a sviluppare qualcosa che non serve e che sarà cambiato dopo.

PRINCIPIO 5

Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.

Se il primo punto è creare valore per il cliente, il secondo punto è come creiamo valore? Il fattore di successo più importante è costituito dalle persone. Incoraggiarle e creare un ambiente dove possono esprimersi al meglio.

PRINCIPIO 6

Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.

Perché vogliamo la presenza giornaliera di chi gestisce il cliente (business people)? Perché possiamo parlarci senza scambi formali di email (a volte lunghi). In questo modo le informazioni sono scambiate subito ed il contributo delle varie figure professionali è sempre e solo nella direzione della creazione di valore per il cliente.

PRINCIPIO 7

Il software funzionante è il principale metro di misura di progresso.

E’ vero che documentare è importante, ma la cosa più importante è che il software rilasciato soddisfi il cliente. Se lo scenario cambia, il software cambia e la documentazione è da riscrivere. La priorità è invece sul software.

PRINCIPIO 8

I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.

E’ in piena coerenza con i principi precedenti. Abbiamo detto che il valore viene prodotto dalle persone, che devono lavorare in un ambiente che permetta loro di esprimersi al meglio. Avere dei ritmi di lavoro con dei picchi non consente alle persone di dare il meglio. Meglio mantenere un ritmo costante e produttivo.

PRINCIPIO 9

La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.

PRINCIPIO 10

La semplicità – l’arte di massimizzare la quantità di lavoro che non verrà fatto – è essenziale.

Se utilizziamo i migliori modelli di progettazione e la migliore soluzione tecnica raggiungiamo il risultato con il minimo sforzo.

PRINCIPIO 11

Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.

PRINCIPIO 12

A intervalli regolari è necessario che il team rifletta su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

C’è fiducia nelle persone. C’è fiducia nel fatto che le migliori soluzioni le trovano lavorando insieme. Ma migliorano nel tempo. Per migliorare nel tempo è necessario che tarino il loro comportamento e migliorino continuamente. Per farlo occorre stabilire ad intervalli regolari un momento di riflessione sul come migliorare.

Se facciamo nostri questi principi, possiamo senza dubbio stabilire che:

• Gli individui e le iterazioni sono più importanti dei processi e dei tools
• Il software funzionante è più importante della documentazione esaustiva
• La collaborazione con il cliente è più importante della negoziazione e del contratto
• Rispondere ai cambiamenti è più importante di seguire un piano

Devo dire che questi sono dei principi che ispirano anche se non si usa AGILE, penso soprattutto a quanto si afferma sulla fiducia nelle persone, un elemento molto potente, che può portare davvero risultati inaspettati.

Nel corso BE Formazione di preparazione all’esame di certificazione PMP® vengono esposti molti concetti che si ispirano ad AGILE e ne includono la filosofia. Sono concetti richiamati da tecniche diverse come Rolling Wave Planning, dove si spiega come la pianificazione di dettaglio si sposti lungo l’onda dell’evoluzione del progetto.

Ma Agile è solo per i progetti software?

I principi del Manifesto Agile appena visti valgono sicuramente per i progetti di sviluppo software.

Ma è possibile applicare Agile anche in altri contesti?

La risposta è si!

Non a caso nel 2005 viene stilata una dichiarazione con l’intento di ampliare l’applicazione dei principi Agile anche a progetti non software. La necessità era evidentemente quella di definire un approccio diverso al management in generale.

Ma di questo vi parlerò nel prossimo articolo.

A presto.

Leggi anche: “Il Manifesto AGILE: il cambiamento è di casa (parte seconda)”