6. CAMBIAMENTO
6.3 Panoramica
6. CAMBIAMENTO
6.1 Introduzione
Tutti i progetti, indipendentemente dal metodo o framework adottato, sono esposti al cambiamento. È assolutamente indispensabile che i membri del team di progetto comprendano che i processi di sviluppo di Scrum sono concepiti proprio per abbracciare il cambiamento. Le organizzazioni devono cercare di massimizzare i benefici che scaturiscono dal cambiamento e minimizzarne gli eventuali impatti negativi attraverso processi accurati di gestione del cambiamento, nel rispetto dei principi di Scrum.
Il Cambiamento, così come definito nella Guida al Corpo di Conoscenze di Scrum (Guida SBOK™), si applica alle situazioni di seguito elencate:
Portfolio, programmi e/o progetti di qualsiasi settore industriale
Prodotti, servizi, o qualsiasi altro risultato da consegnare agli stakeholder
Progetti di qualsiasi dimensione o complessità
Il termine ―prodotto‖ nella Guida SBOK™ si può riferire ad un prodotto, servizio, o altro deliverable. Scrum può essere applicato in maniera efficace a qualsiasi progetto di qualunque settore industriale – dai piccoli progetti o team di appena sei membri fino ai progetti grandi e complessi che arrivano a diverse centinaia di membri del team.
Questo capitolo si divide nelle seguenti sezioni:
6.2 Guida per i Ruoli — Questa sezione fornisce un‘indicazione su quali paragrafi sono importanti per
ciascuno dei principali ruoli di Scrum: Product Owner, Scrum Master e Scrum Team.
6.3 Panoramica—Questa sezione definisce il concetto di cambiamento, specificamente all‘interno del
contesto dei processi di Scrum. Inoltre tratta del modo in cui sono gestite le Richieste di Modifica nei processi Scrum.
6.4 Cambiamento in Scrum—Questa sezione approfondisce l‘importanza di un‘efficace gestione del
cambiamento in un progetto Scrum. Tratta inoltre del modo in cui si possono realizzare flessibilità e stabilità attraverso una gestione appropriata delle Richieste di Modifica che si presentano nel corso di un progetto.
6.5 Integrazione del Cambiamento—Questa sezione chiarisce nel dettaglio come vengono valutate e
approvate (o rifiutate) le Richieste di Modifica in applicazione del framework Scrum.
6.6 Cambiamento nei Programmi e nei Portfolio—Questa sezione descrive l‘impatto dei cambiamenti sui
programmi e sui portfolio.
6.7 Riepilogo delle Responsabilità—Questa sezione definisce le responsabilità dei membri del team di
6.8 Confronto fra Scrum e il Project Management Tradizionale—Questa sezione parla dei benefici della
gestione del cambiamento con i metodi Scrum rispetto ai metodi utilizzati nei modelli tradizionali di project management.
6.2 Guida per i Ruoli
1. Product Owner—La responsabilità di avviare il cambiamento fa capo prima di tutto al Product Owner; pertanto, per questo ruolo è consigliato l‘intero capitolo.
2. Scrum Master—Anche lo Scrum Master dovrebbe avere familiarità con l‘intero capitolo, con particolare attenzione alle sezioni 6.3, 6.4, 6.5 e 6.7.
3. Scrum Team—Lo Scrum Team dovrebbe concentrarsi principalmente sulle sezioni 6.3, 6.4.2, 6.5 e 6.7.
6.3 Panoramica
Il cambiamento è inevitabile in tutti i progetti. Nell‘ipercompetitivo mondo di oggi, in cui la tecnologia, le condizioni di mercato e i modelli di business sono in continuo movimento, il cambiamento rappresenta l‘unica costante.
Per Scrum è fondamentale riconoscere che a) gli stakeholder (ad esempio clienti, utenti e sponsor) nel corso del progetto cambiano idea su quello che vogliono e su ciò di cui hanno bisogno (il cosiddetto ‗requirements churn‘, cioè l‘abbandono dei requisiti) e b) che è molto difficile, se non impossibile, per gli stakeholder definire tutti i requisiti durante l‘inizio del progetto.
I progetti di sviluppo Scrum accolgono il cambiamento tramite piccoli cicli di sviluppo, che incorporano il feedback del cliente sui deliverable del progetto dopo ogni singolo Sprint. Questo permette al cliente di interagire regolarmente con i membri dello Scrum Team, di vedere gli incrementi di prodotto appena sono pronti e di modificare i requisiti fin dall‘inizio del ciclo di sviluppo. Inoltre, i team di gestione del portfolio o del programma possono rispondere alle Richieste di Modifica attinenti ai progetti Scrum e riferibili al loro livello. Scrum incorpora un principio fondamentale del Manifesto Agile (Fowler e Highsmith, 2001): ―Rispondere al cambiamento prima di seguire un piano‖. L‘applicazione di Scrum si basa sul concetto che il cambiamento va abbracciato e trasformato in vantaggio competitivo. Per tale motivo, è più importante essere flessibili che seguire strettamente un piano predefinito. Questo significa che è essenziale avere un approccio adattivo al project management che consenta il cambiamento durante l‘intero ciclo di sviluppo del prodotto o servizio. L‘adattabilità al cambiamento è uno dei vantaggi chiave del framework Scrum. Anche se Scrum funziona bene in tutti i progetti di qualsiasi settore industriale, può essere particolarmente efficace quando il prodotto
6
mercato dello specifico prodotto è volatile, e/o quando si punta a rendere il team sufficientemente flessibileda riuscire ad incorporare il cambiamento dei requisiti. Scrum è utile specialmente per i progetti complessi che presentano un grado elevato di incertezza. La pianificazione e le previsioni di lungo termine sono di solito inefficaci per questo tipo di progetti, che implicano alti livelli di rischio. Scrum guida il team al raggiungimento dei risultati di business di maggior valore attraverso i principi della trasparenza, dell‘ispezione e dell‘adattamento.
6.3.1 Richieste di Modifica non Approvate e Approvate
Le richieste di procedere a dei cambiamenti sono di solito presentate come Richieste di Modifica. Le Richieste di Modifica rimangono nello stato di ‗non approvate‘ fino a quando non ottengono l‘approvazione formale. Lo Scrum Guidance Body definisce di solito un processo di approvazione e gestione dei cambiamenti valido per tutta l‘organizzazione. In mancanza di un processo formale, è consigliabile far approvare direttamente dal Product Owner le piccole modifiche che non hanno un impatto significativo sul progetto. La tolleranza per queste piccole modifiche può essere definita a livello di organizzazione oppure dallo sponsor per uno specifico progetto. Nel maggior parte dei progetti, il 90% delle Richieste di Modifica può essere classificato come piccole modifiche che devono essere approvate dal Product Owner. Per questo motivo il Product Owner ricopre un ruolo molto importante nella gestione dei cambiamenti in un Progetto Scrum.
Le modifiche che superano il livello di tolleranza assegnato al Product Owner devono essere approvate dagli stakeholder appropriati, che lavorano insieme al Product Owner.
A volte, se da un cambiamento richiesto potrebbe derivare un impatto considerevole sul progetto o sull‘organizzazione, può essere necessaria l‘approvazione da parte del senior management (ad esempio, Executive Sponsor, Portfolio Product Owner, Program Product Owner, o Chief Product Owner).
Le Richieste di Modifica relative al progetto sono discusse e approvate durante i processi Sviluppare le Epic,
Creare il Prioritized Product Backlog e Mettere a Punto il Prioritized Product Backlog. Le Richieste di Modifica Approvate sono quindi prioritizzate insieme agli altri requisiti del prodotto e alle loro rispettive User
Story e poi incorporate nel Prioritized Product Backlog.
La Figura 6-1 sintetizza il processo di approvazione dei cambiamenti, mentre la Figura 6-2 spiega come si aggiorna il Prioritized Product Backlog con i cambiamenti approvati.
Figura 6-1: Esempio di Processo di Approvazione dei Cambiamenti
Figura 6-2: Aggiornamento del Prioritized Product Backlog con i Cambiamenti Approvati Richieste di Modifica non
Approvate
Chi approva? - Product Owner
(la maggior parte dei Cambiamenti)
- Stakeholder e Product Owner
(Cambiamenti al di sopra della tolleranza dei Product Owner)
- Senior Management
(Cambiamenti Significativi) Richieste di Modifica Approvate
Quando si approvano?
- Sviluppare le Epic
- Creare il Prioritized Product Backlog - Mettere a Punto il Prioritized Product Backlog Pro do tto Cambiamenti prioritizzati (Non approvati) ( Cambiamenti prioritizzati
(Approvati) Prioritized Product Backlog Aggiornato Cambiamento 1 Cambiamento 2 Cambiamento 3 Cambiamento 4 Cambiamento 5 Cambiamento 6 Cambiamento 7 Cambiamento 2 Cambiamento 4 Cambiamento 7 Cambiamento 2 Cambiamento 4 Cambiamento 7