---

Che cosa sono coordinamento e pianificazione tra team? Potrebbe sorprenderti!

Scrum of Scrum

Dopo il capitolo precedente, potresti chiederti come coordinare i diversi Scrum Team perché collaborino efficacemente.

È una domanda legittima e abbiamo cercato di rispondere anche a questa.

Incontri Scrum of Scrum

Gli incontri Scrum of Scrum assomigliano ai Daily Scrum. Qui, però, l'attenzione non è sul lavoro dei singoli membri, ma sugli Scrum Team stessi.

Scrum of Scrums è una pratica facoltativa di coordinamento, non un evento Scrum formale aggiuntivo. I team possono scegliere 15 minuti al giorno; quando serve più coordinamento, una sessione di 30–60 minuti è un altro esempio. Devono verificare se il formato sia utile.

Esempi di domande di coordinamento

• Che cosa ha fatto ieri il team?
• Che cosa intende fare oggi?
• Ci sono impedimenti che ostacolano o rallentano l'avanzamento?

Le risposte devono naturalmente coprire user story e interdipendenze che influenzano anche altri team.

Nel modello storico descritto, un Chief Scrum Product Owner e un Lead Scrum Master possono facilitare insieme gli incontri. Sono titoli organizzativi facoltativi, non responsabilità Scrum aggiuntive. In alternativa, uno dei due può moderare gli incontri oppure possono ruotare il compito.

Sprint Review comuni

Le Sprint Review comuni con tutti i team non sono obbligatorie, ma possono essere molto utili. Occorre comunque soddisfare lo scopo della Review. I team sullo stesso prodotto esaminano il risultato integrato insieme agli stakeholder; sessioni locali separate non sono un doppione obbligatorio.

Partecipano i delegati degli Scrum Team e il Product Owner responsabile del prodotto condiviso. Anche gli stakeholder esaminano il risultato.

I team possono ruotare i propri delegati secondo le preferenze. Un facilitatore designato, come il Lead Scrum Master facoltativo dell'esempio, può aiutare a rendere efficace la Review comune.

Le Review comuni consentono a tutti i team di mostrare gli incrementi rilasciabili al Product Owner responsabile, ai referenti di supporto e agli stakeholder pertinenti.

Soddisfano così due scopi:

1. Tutti gli Scrum Team sono allineati sullo stato attuale del progetto complessivo.
2. Tutti raccolgono feedback sul lavoro e possono considerarlo nei successivi Sprint Planning.

Sprint Retrospective comuni

Come le Review comuni, le Sprint Retrospective comuni non sono obbligatorie ma possono essere molto utili.

Non sostituiscono le retrospettive che ogni Scrum Team deve tenere.

Partecipano i delegati dei team, che possono essere ruotati a loro discrezione.

Le retrospettive comuni possono essere facilitate da un coordinatore designato, come il Lead Scrum Master facoltativo dell'esempio. Servono a individuare e attuare miglioramenti su come l'organizzazione del grande progetto usa il framework Scrum.

Tutte le questioni che richiedono attenzione e collaborazione di più Scrum Team (approfondisci Più Scrum Team) per essere risolte devono emergere in questi incontri. Occorre pianificare, programmare e seguire i percorsi di soluzione.

Pianificazione tra team: lo Scrum Product Backlog globale

Quando più team lavorano allo stesso prodotto, condividono Product Goal e Product Backlog sotto un solo Product Owner responsabile. La lezione chiama questa vista Scrum Product Backlog globale. Referenti di supporto e team possono contribuire ad affinarne il contenuto, ma la responsabilità rimane a quel Product Owner.

Backlog specifici per team

Quando necessario, le user story del backlog globale possono essere suddivise in storie più specifiche per team.

Questi dettagli possono essere mantenuti in viste operative specifiche e, dopo la selezione, nello Sprint Backlog di ciascun team. Si riferiscono al Product Backlog condiviso, anziché diventare backlog dello stesso prodotto con priorità indipendenti. I riferimenti aiutano i team a capire il ruolo delle proprie user story nel quadro complessivo e il valore fornito al cliente.

Programmazione degli Sprint

In un progetto Scrum distribuito, puoi scegliere tra due opzioni per sincronizzare i diversi team.

• Sprint sincroni
• Sprint asincroni

La prima usa Sprint sincroni: tutti iniziano e finiscono lo stesso giorno.

Sono generalmente preferiti perché rendono comunicazione e coordinamento relativamente più semplici.

Sprint sincroni

Un'altra opzione sono gli Sprint asincroni, che non iniziano e finiscono lo stesso giorno. Il vantaggio è non concentrare tutti i rituali Scrum nella stessa giornata. Può permettere al Product Owner e ai referenti di coordinamento di partecipare a Sprint Planning, Sprint Review e Sprint Retrospective degli altri team e sostenerli quando richiesto.

Quando un team fornisce servizi agli altri, gli Sprint asincroni offrono un vantaggio aggiuntivo.

Sprint asincroni

Ecco lo scenario illustrato sopra: il lavoro del team A (fornitore) deve essere integrato nei risultati del team B (principale). Con Sprint asincroni, il team A può concludere prima del team B. Quest'ultimo può quindi prendere i risultati del team A e integrarli prima di chiudere il proprio Sprint.

Stime dello sforzo

I team possono scegliere convenzioni comuni di dimensionamento, come punti in stile Fibonacci o taglie di magliette, quando aiutano la pianificazione condivisa. Scrum non lo richiede e i punti o la velocità di un team non sono automaticamente comparabili a quelli di un altro.

Quando una convenzione comune è utile, applicala coerentemente nel Product Backlog condiviso, mantenendo la responsabilità del dimensionamento ai Developer.

Serve particolare attenzione alle stime dei team di componenti. Generalmente forniscono servizi per le user story dei team di funzionalità e devono quindi ricevere sostegno e chiarimenti necessari durante le proprie stime e lo Sprint Planning.