Padroneggiare i progetti agili

Un approccio di progetto agile è contemporaneo e viene postulato come una panacea. Quale azienda non vuole essere agile? Tuttavia, il cambiamento verso l'agilità (parziale) in un'organizzazione richiede due circostanze fondamentali:

• Deve valere la pena: Con le procedure agili, si ottengono migliori risultati di progetto o i risultati del progetto sono portati alla maturità del prodotto più velocemente con sufficiente accettazione.
• Deve essere possibile: Gli approcci agili richiedono seri aggiustamenti nella cultura organizzativa, cioè nell'atteggiamento e nel comportamento delle persone a tutti i livelli della gerarchia. Inoltre, deve essere possibile espandere iterativamente il risultato di un progetto e portarlo gradualmente alla maturità.

Andare in dettaglio su tutti gli aspetti di una trasformazione agile di successo andrebbe oltre lo scopo di questo articolo. I prerequisiti più importanti sono riassunti nella tabella 1. Bisogna anche tener conto che ogni cambiamento in un'organizzazione - compreso quello verso l'agilità - richiede molto tempo di maturazione oltre a una buona preparazione e implementazione.

Modelli applicativi e trasformazione
Le organizzazioni di solito si avvicinano alla trasformazione agile - il cambiamento da un approccio di progetto classico a uno agile - con molto cuore e anima e un'attenta gestione del cambiamento. Tuttavia, la piena espressione dell'agilità non si adatta a tutti gli ambienti. Fondamentalmente, vediamo tre diversi modelli per l'applicazione dell'agilità nelle organizzazioni (vedi Fig. 1):

1. Il modello ibrido: progetti agili combinati con la classica gestione del portafoglio progetti e dei programmi
2. Il modello bimodale (chiamato anche a due velocità): i progetti classici e agili coesistono e sono prioritari per la gestione classica o agile del portafoglio progetti e dei programmi.
3. L'agilità completa: approcci di gestione agile a livello di portafoglio progetti, programmi e progetti

Elementi classici e agili possono essere combinati bene e raggiungere insieme un'alta efficacia. Il mix di modelli è l'obiettivo finale o una tappa intermedia nel percorso della trasformazione agile. Non c'è un giusto o sbagliato, ma solo un migliore o peggiore adattamento ai bisogni e alle capacità di un'organizzazione.

Opportunità, rischi e qualità
Nel nostro lavoro con i clienti, ci troviamo spesso di fronte a domande come: opportunità, rischi e gestione della qualità sono previsti nel mondo agile? Come possiamo assicurarci che il nostro progetto non vada fuori controllo? Chi è responsabile se non ci sono i classici project manager?

L'approccio agile affronta implicitamente le opportunità e i rischi attivamente e ripetutamente: con riunioni regolari (Sprint Planning, Daily SCRUM, Sprint Retrospective) e Sprint Reviews. Raccomandiamo di accentuare le opportunità e i rischi in modo tale che il proprietario del prodotto tenga e valuti i propri backlog di opportunità e rischi. I corrispondenti elementi del backlog possono essere inclusi nella pianificazione dello sprint come requisiti. Questo ha il vantaggio che la gestione delle opportunità e dei rischi è integrata in modo naturale nella gestione operativa del progetto. Anche gli impedimenti vengono rilevati e risolti in modo tempestivo. Questo processo è supportato dal maestro SCRUM nel suo ruolo centrale di trovatore di soluzioni ed eliminatore di ostacoli.

La gestione della qualità nell'esecuzione di un progetto agile è simile (vedi Tabella 2): la qualità dovrebbe essere fornita continuamente. Il controllo della qualità e le eventuali correzioni sono fatte in ogni iterazione. La qualità è valutata per mezzo di criteri di accettazione precedentemente definiti per le storie utente. Soddisfare i criteri genera da un lato dei benefici per il business e dall'altro assicura che la qualità richiesta sia raggiunta.

Dal nostro punto di vista, gli approcci agili forniscono buoni mezzi per affrontare opportunità, rischi e qualità più frequentemente, in modo più trasparente e attraverso più ruoli. Abbiamo avuto una buona esperienza con la raccomandazione di affrontare esplicitamente questi problemi.

Controllo e reporting
Nei progetti gestiti classicamente, il controllo basato sulle dimensioni QUARZ (Q = qualità, U = ambito, A = sforzo o costi, R = rischi, Z = tempo) si sta affermando sempre più. Queste dimensioni sono presenti anche nei progetti agili, ma sono gestite implicitamente:

• Qualità: I requisiti di qualità fanno parte dei criteri di accettazione. La realizzazione e l'accettazione di una storia utente in uno sprint include quindi sempre la qualità oltre al beneficio di business.
• Portata: L'ambito di consegna e la portata di un progetto sono determinati dalla gestione del backlog e controllati nella sprint review - spesso in combinazione con il controllo dei costi.
• Costi: I costi del progetto tendono ad essere fissi, ma l'ambito è cambiato.
• Rischi: Le opportunità e i rischi si riflettono in backlog separati e confluiscono automaticamente nella pianificazione dello sprint.
• Tempo: gli sprint sono a tempo determinato. Le deviazioni dalle scadenze nei progetti si verificano solo attraverso l'esecuzione di sprint aggiuntivi.

A causa della tendenza a fissare i costi e a variare l'ambito, il controllo nei progetti agili è spesso ridotto all'elaborazione del product backlog e al numero necessario di sprint. Attraverso un'adeguata applicazione delle procedure del progetto agile, il controllo all'interno dei singoli sprint avviene quasi in tempo reale, il che aumenta la trasparenza e la velocità di reazione. D'altra parte, troviamo debolezze nel controllo trasversale relativo all'intero progetto. Dato che gli investimenti vengono fatti anche nei progetti agili, il controlling legato al progetto non dovrebbe essere trascurato. Raccomandiamo uno sguardo acuto a tutte le dimensioni di QUARZ, compresa la combinazione costo-campo.

Tenendo conto delle seguenti condizioni di applicazione, abbiamo avuto un'ottima esperienza con il metodo earned value per il controllo e il reporting nei progetti agili:

• Comunichiamo con grafici da cui si possono ricavare le tendenze.
• La curva del valore pianificato è disegnata come una linea retta sull'intero numero o su una parte degli Sprint pianificati. Rappresenta la somma di tutti i compiti che sono necessari per soddisfare gli elementi del backlog nel rispettivo sprint.
• Per determinare la curva dell'earned value, consideriamo solo i compiti completati (approccio 0/100) dalla pianificazione dello sprint.
• Per la curva del budget bruciato, usiamo lo sforzo effettivo cumulativo che il team SCRUM fa a settimana.
• Per rendere tutti i valori comparabili tra loro, li presentiamo relativamente in percentuale.
• Le curve earned-value e budget-burned sono tracciate in modo sprint-overlapping e sono quindi paragonabili alla linea retta planned-value.

La figura 2 illustra questa procedura. I metodi earned value adattati in questo modo risultano in un controllo efficace e trasversale del progetto e sono facili da integrare nel reporting del progetto. Il risultato è una panoramica significativa del progresso del progetto (portata), dei costi del progetto e della tendenza per dimensione. Le restanti dimensioni QUARZ sono direttamente collegate all'ambito e ai costi e completano il controllo del progetto.

Nota: Per rendere più facile colmare il divario con i veri "agilisti", di solito facciamo a meno della nomenclatura earned value, etichettando le curve "progresso pianificato", "progresso effettivo" e "sforzo effettivo", per esempio, e chiamando il grafico "project burn-down chart".

Conclusione
Gli esempi di cui sopra mostrano quanto siano preziosi i metodi/strumenti classici nelle procedure dei progetti agili e che possono essere integrati bene. Nella nostra esperienza, le discipline di gestione dei progetti adeguatamente eseguite sono un fattore intrinseco di successo nonostante o proprio a causa dell'agilità. Organizzazioni come l'International Project Management Association (IPMA) o il Federal IT Steering Committee (FSUIT) hanno integrato approcci agili nei loro attuali standard di gestione dei progetti.

Sappiamo come i mondi a volte quasi dogmaticamente separati degli approcci classici e agili possono essere combinati con profitto. Usa la nostra esperienza a tuo vantaggio.