Alcuni anni fa mi trovai di fronte un compito piuttosto arduo. Diversamente dai molti progetti di sviluppo software che avevo gestito in precedenza, questa volta l’obiettivo era realizzare un nuovo sistema partendo da zero, ma con due importanti punti critici: il progetto era privo di un insieme di specifiche definite e, peggio ancora, godeva di scarso appoggio da parte degli stakeholder (basti pensare che mi fu concesso soltanto 1/6 del budget complessivo stimato).

Date queste premesse, le probabilità di fallimento erano molto elevate e l’approccio di PM classico analisi/progettazione/sviluppo/collaudo/rilascio non avrebbe fatto che incrementare queste probabilità.

Decisi allora di adottare un approccio molto diverso, la cui base sarebbe stata la prudenza: non ci sono specifiche chiare e complete? Allora sviluppiamo solo le parti che sono note. Non c’è fiducia sul risultato? Allora produciamo delle release intermedie funzionanti (anche se ovviamente limitate) per far “toccare con mano” il prodotto.

Redigemmo la lista delle funzionalità che sapevamo essere necessarie, dando una priorità a ciascuna di esse secondo il punto di vista dell’utente finale. Presi il mese come unità di tempo di riferimento: ogni quattro settimane avremmo realizzato alcune delle funzionalità presenti nella lista, selezionandole secondo un criterio di omogeneità, cioè in modo tale che messe insieme costituissero un sottoinsieme funzionante del sistema complessivo.

Alla fine di ciascun mese avremmo rilasciato un aggiornamento del prodotto, disponibile a tutti come se fosse davvero in produzione.

Trascorsi alcuni mesi fui in grado di organizzare delle sessioni dimostrative in cui si poteva vedere un prodotto certamente ancora limitato, ma già funzionante e, cosa molto importante, utilizzabile in produzione. Questo aumentò la confidenza da parte degli stakeholder sulle potenzialità del sistema e, conseguentemente, il loro appoggio al progetto.

Fu così che tutti i principali responsabili di reparto dell’azienda vennero coinvolti nel progetto, per dare il loro contributo in termini di idee, modifiche, miglioramenti o anche solo segnalazioni di anomalie. Naturalmente mantenni l’approccio del “mese di sviluppo”, in modo che i contributi esterni all’evoluzione del prodotto potessero ricevere feedback in tempi rapidi, generando così un circolo virtuoso a tutto vantaggio del sistema e della sua efficacia.

Oggi quel sistema è in produzione e svolge un ruolo fondamentale per l’erogazione dei servizi alla clientela di una grande azienda italiana, utilizzato da migliaia di utenti per pianificare e rendicontare le proprie trasferte aziendali.

Quando un anno fa ho intrapreso la sfida di SoundsOfThings mi sono chiesto quale fosse l’approccio migliore per gestire questo difficilissimo progetto. Esplorando le varie tecniche di Project Management disponibili, in particolar modo quelle più utilizzate nel mondo delle startup, mi sono imbattuto in Scrum, un framework di processo basato sui principi del Manifesto Agile. Con mia grande sorpresa ho ritrovato in Scrum alcuni dei princìpi cardine dell’approccio personale ed artigianale che avevo utilizzato anni prima, come ad esempio il concetto di Sprint: “un intervallo temporale di un mese o meno durante il quale viene creato un incremento del prodotto potenzialmente rilasciabile” (The Scrum Guide^TM, libera traduzione).

Nell’approfondire Scrum ho ritrovato i punti chiave che, artigianalmente, cercai anche io di privilegiare nell’esperienza descritta. Alcuni in particolare li ritengo di grande importanza:

• l’identificazione chiara di un soggetto che assume il ruolo di Product Owner, la cui responsabilità è massimizzare il valore del prodotto sia per gli stakeholder che per gli utenti
• Il coinvolgimento continuo e costante di tutti coloro che fanno parte del progetto, indipendentemente dal ruolo che ricoprono, mediante apposite riunioni programmate (sprint planning, daily scrum, sprint review, sprint retrospective)
• Le analisi retrospettive sui risultati ottenuti in ciascun sprint, in modo che il team possa individuare gli interventi necessari a beneficio dei successivi sprint

Adottare Scrum è senz’altro impegnativo, ma i risultati possono essere davvero interessanti.

Non credo ci sia un approccio buono per qualsiasi tipo di progetto, la scelta va fatta di volta in volta in funzione di diversi fattori come il contesto, gli obiettivi e numerosi altri. La mia esperienza però mi dice che le metodologie Agile hanno una marcia in più, per cui ciò che realmente conta non è utilizzare Agile ma pensare Agile.