Quando si dovrebbe – e non dovrebbe – utilizzare Agile

Le pratiche agile vengono adottate dalle organizzazioni in tutti i settori e mercati. Il driver per questo è la convinzione che i leader organizzativi hanno nel potere di Agile di trasformare notevolmente, modernizzare e migliorare le loro attività ottimizzando lo sviluppo dei sistemi, massimizzando la flessibilità e l’efficienza e semplificando sistemi e processi aziendali complessi.

Tuttavia, l’utilizzo del modello Agile potrebbe non essere sempre l’opzione migliore per un particolare progetto. In effetti, alcuni progetti possono essere gravemente complicati cercando di utilizzare tecniche Agili, quindi sconfiggendo l’intero scopo di utilizzare la metodologia Agile in primo luogo.

Per evitare ciò, le organizzazioni e i responsabili del programma devono capire come applicare Agile dove è appropriato e riconoscere quando altri approcci sono più appropriati. Di seguito è riportato un breve elenco di caratteristiche del progetto che possono aiutare a decidere quando e quando non utilizzare Agile.

Quando dovresti – e non dovresti-usare Agile

Utilizzare Agile quando… NON usare Agile quando…
…il vostro progetto richiede membri del team che sono ben disciplinati, ben stagionato, e qualificato per mettere Agile in uso pratico. Se il tuo progetto è abbastanza complesso da richiedere dipendenti così qualificati, è un segno che le tattiche agili possono aiutare a rendere lo sviluppo del progetto più efficiente. …il lavoro per il tuo progetto può essere eseguito da membri del team che sono novizi, relativamente non qualificati e che non hanno mai avuto esperienza pratica con Agile. Non ha senso cercare di utilizzare Agile se i dipendenti non hanno familiarità con esso, in quanto non saranno in grado di utilizzarlo correttamente.

…il tuo cliente o cliente sarà disponibile e disposto a partecipare in stretta collaborazione per tutta la durata del progetto. I progetti agili richiedono un feedback coerente da parte dei clienti durante tutto il processo, poiché il successo dipende dal modo in cui hai risposto alle esigenze in evoluzione del tuo cliente.

…il cliente o il cliente non saranno disponibili o disposti a partecipare in stretta collaborazione per tutta la totalità del progetto. Come affermato in precedenza, i progetti Agili dipendono da un feedback coerente da parte dei clienti durante tutto il processo. Quindi, se il tuo client non è disponibile, non provare a utilizzare Agile.

…il successo del tuo progetto sarà definito dal modo in cui il team ha soddisfatto e risposto attivamente alle esigenze di sviluppo del cliente per tutta la durata del progetto. Questo può essere ottenuto solo con il feedback del cliente in più fasi durante il progetto.

…il successo del tuo progetto è definito da quanto bene le esigenze originali del cliente, non le esigenze in evoluzione, sono state soddisfatte. Mentre i progetti Agile si concentrano sulle esigenze in continuo sviluppo del cliente, se il tuo progetto ha obiettivi o obiettivi statici, starai meglio senza usare Agile.

…i risultati finali del progetto possono essere ragionevolmente distribuiti in pacchetti di lavoro realizzabili in brevi periodi di tempo di circa due o quattro settimane. La velocità e la flessibilità dei progetti Agili dipendono da una distribuzione fluida e rapida in ogni nuova fase del processo.

…i deliverable del tuo progetto non possono essere ragionevolmente distribuiti in pacchetti di lavoro realizzabili in periodi di tempo di 6 settimane o più brevi. Le pratiche agili non saranno in grado di avvantaggiare il progetto se i risultati finali di ciascuna fase del progetto non possono essere distribuiti abbastanza rapidamente.
…il tuo progetto comporta processi iterativi o ciclici in cui i risultati incrementali aggiungeranno valore al tuo progetto fornendo continuamente nuove linee guida per il tuo progetto. Ciò si riferisce alla necessità di feedback dei clienti, in quanto fornirà gran parte della nuova guida e direzione per il vostro progetto. …il processo del tuo progetto è meglio implementato come lineare o a spirale (al contrario di iterativo), in cui i risultati incrementali avranno poco o nessun valore significativo nello sviluppo del tuo progetto. Ciò significa che il feedback dei clienti e la rivalutazione, aspetti vitali dello sviluppo Agile del progetto, non saranno necessari.

È una verità che il futuro è Agile. In effetti, con i mercati in continua evoluzione di oggi e la tecnologia in rapido progresso, la flessibilità e la reattività che le tecniche Agili possono fornire potrebbero essere l’opzione migliore per molte iniziative di modernizzazione. Tuttavia, Agile potrebbe non essere sempre il metodo migliore per implementare un progetto specifico. C’è un tempo e un luogo per tutto, anche i progetti che non dovrebbero utilizzare Agile.
Per leggere un elenco completo di scenari in cui dovresti e non dovresti utilizzare le pratiche Agili nel tuo progetto, così come altri suggerimenti per la transizione verso un nuovo paradigma organizzativo, consulta il white paper di RG sulla consegna del progetto agile di successo.

Per saperne di più sulla metodologia Agile nella pratica, scarica la nostra “Guida del praticante Agile.”

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.