---

Come scalare il framework Scrum nei progetti distribuiti e di grandi dimensioni? Potrebbe sorprenderti!

Il framework Scrum, come descritto finora, funziona al meglio con un singolo Scrum Team in un'unica sede. Nella realtà, però, spesso un solo Scrum Team non può realizzare interamente un progetto, oppure i suoi membri devono distribuirsi su più sedi.

Quando un team non può soddisfare le esigenze del prodotto, l'organizzazione può considerare team aggiuntivi. La sola distribuzione geografica non richiede più team e aggiungere persone può aumentare i costi di coordinamento. In molti casi osserviamo anche team distribuiti in sedi geograficamente lontane o in continenti diversi.

Numerose ragioni spingono le organizzazioni a distribuire i team in sedi diverse:

• Ragioni tecniche: Alcune conoscenze necessarie a costruire componenti software distinti non sono disponibili nella sede centrale,
• Ragioni di competenza: Alcune capacità necessarie alle diverse attività di ingegneria software non sono disponibili localmente. Per esempio, automazione dei test, progettazione dell'interfaccia utente o integrazione del software interno con quello di altri fornitori possono richiedere esperti esterni alla sede centrale,
• Ragioni dimensionali: Il progetto richiede più persone per consegnare ai clienti entro i tempi prestabiliti. L'organizzazione avrà quindi bisogno di più membri di quanti possano ragionevolmente appartenere a un solo Scrum Team. Può essere necessario creare più Scrum Team coesi invece di ampliare indefinitamente un unico team,
• Ragioni aziendali: Usare risorse umane in sedi meno costose o garantire continuità al lavoro con ingegneri in fusi orari diversi può costituire una valida motivazione economica.

Poiché la comunicazione è parte integrante del framework Scrum, tutti i membri devono impegnarsi a superare le sfide dell'ambiente di progetto distribuito. Inoltre, tutti devono avere accesso a strumenti di comunicazione, comprese audio/video conferenze e condivisione dello schermo.

Gli strumenti comuni di gestione del progetto sostengono una comunicazione sana e continua. Possono comprendere Product Backlog, Sprint Backlog, elenchi degli incidenti, strumenti di condivisione di conoscenze e notizie e così via.

Organizzazione del progetto: più team

Il modo più semplice di ampliare Scrum in un progetto di maggiori dimensioni è aumentare il numero di team nella stessa sede.

Se più team devono collaborare alla realizzazione di un progetto, è meglio aumentarne progressivamente il numero.

Cosa significa per te?

Più team in un'unica sede

Nella maggior parte delle organizzazioni, crescere progressivamente è più gestibile che avviare dieci nuovi team tutti insieme. La buona pratica è iniziare con uno Scrum Team. Dopo alcuni Sprint riusciti, uno o due team aggiuntivi possono unirsi al progetto. Una volta verificato che questi Scrum Team (maggiori informazioni su Più Scrum Team ) collaborano bene, puoi continuare ad aggiungerne altri all'organizzazione del progetto distribuito.

Aumentare il numero di team

Esistono due modi tipici per creare nuovi Scrum Team:

• Dividere uno Scrum Team esistente in più team, aggiungendo membri quando e dove necessario,
• Creare un nuovo Scrum Team con ingegneri diversi, finora non coinvolti nel progetto.

Dividere un team esistente permette di valorizzare i membri che hanno già conoscenze ed esperienza del progetto in corso.

Perciò, i nuovi team sono solitamente produttivi almeno in parte fin dalla formazione. Lo svantaggio principale è aver diviso in due un team esistente pienamente operativo. Questo può sempre causare problemi di motivazione dei membri. Soprattutto quando i cambiamenti avvengono senza preavviso e spiegazioni da parte dei vertici e i membri non sono preparati mentalmente e tecnicamente.

Aggiungendo team completamente nuovi, quelli esistenti possono mantenere la propria struttura e proseguire gli Sprint. Coordinamento, inserimento e integrazione con i nuovi team richiedono comunque attenzione. Occorrerà però più tempo per sviluppare le conoscenze e lo slancio necessari a rendere pienamente operativi i team nuovi.

Qualunque sia il modo scelto per aggiungere nuovi Scrum Team, ricorda i seguenti principi:

• Inizia con pochi Scrum Team,
• Aumenta gradualmente il numero di team,
• Assicura continuità del lavoro e consegna regolare di software e valore aziendale durante cambiamento e crescita,
• Se problemi significativi ostacolano produttività e continuità del lavoro, risolvili prima di espanderti con nuovi Scrum Team.

Organizzazione del progetto: team distribuiti

La maggiore complessità di più team emerge quando i nuovi Scrum Team devono distribuirsi in varie sedi. Barriere comunicative, difficoltà di coordinamento e incomprensioni sulle norme comuni del progetto sono solo alcune delle molte complessità.

Più team in più sedi

Non affrontare queste sfide ha conseguenze gravi.

Le aziende devono contare miliardi di dollari di budget IT sprecato per mancanza di competenze in Leadership organizzativa e Competenza nello Scrum su larga scala.

Ecco quattro suggerimenti fondamentali per affrontare queste sfide:

• Assicura che i nuovi membri siano formati nel framework Scrum come Scaled Scrum Expert,
• Assicura che i nuovi membri conoscano adeguatamente il progetto e comprendano ciò a cui contribuiscono, non solo tecnicamente ma anche in termini di valore aziendale professionale, così da decidere nel lavoro come aumentare il valore del proprio contributo,
• Assicura la definizione delle norme del progetto. Come un singolo Scrum Team ha regole di comunicazione, pianificazione ed esecuzione, un'organizzazione con più team deve avere norme di livello superiore. Così i team possono comunicare, pianificare, operare, risolvere problemi e consegnare insieme valore ai clienti e all'azienda.
• Assicura che i nuovi membri lavorino almeno temporaneamente con quelli esperti. Possono servire visite alle sedi remote e formazione sul lavoro: è del tutto accettabile, anzi auspicabile. Questo approccio trasferisce agevolmente le conoscenze e crea un dialogo personale e bidirezionale tra persone di team e sedi diverse.

Team virtuali

Un'altra possibilità è uno Scrum Team con membri distribuiti su più sedi. Un team simile si chiama «team virtuale».

La sfida principale è garantire una comunicazione impeccabile tra i membri. Gli Scrum Team devono comunque svolgere tutti gli eventi previsti per coordinare il lavoro, ma senza trovarsi tutti nella stessa stanza.

Team virtuali

I membri della stessa sede possono lavorare insieme in una stanza condivisa quando utile, assicurando la piena partecipazione dei colleghi remoti. Devono però affidarsi maggiormente agli strumenti collaborativi e comunicativi. Possono partecipare agli eventi Scrum dalla stessa sala riunioni, collegandosi all'altra parte del team virtuale in videoconferenza.

Scrum Product Owner Team

Come abbiamo ripetuto in questo materiale, la comunicazione regolare tra Scrum Product Owner e Scrum Team è cruciale per consegnare con successo un progetto.

Gli Scrum Team in sedi diverse devono poter accedere efficacemente alle decisioni sul prodotto. Per un unico prodotto, i team condividono un Product Owner, un Product Goal e un Product Backlog. Il Product Owner può delegare attività di supporto mantenendo la responsabilità; non serve un Product Owner distinto responsabile per ogni team.

Questa edizione descrive «Scrum Product Owner Team» e «Chief Scrum Product Owner» come un modello organizzativo di collaborazione. Un Product Owner può lavorare con delegati o altri specialisti di prodotto, ma questi titoli non sono responsabilità Scrum aggiuntive e non sostituiscono l'unico Product Owner responsabile di un prodotto.

Il Product Owner responsabile, sostenuto da questa collaborazione, si concentra sull'assicurare che:

• Venga costruito il prodotto giusto per soddisfare le richieste del cliente,
• Il Product Owner e gli eventuali delegati collaborino efficacemente, aiutando i team a creare valore aziendale e tecnico per i clienti.

Il Product Owner resta responsabile della gestione efficace del Product Backlog. Il lavoro di supporto sui requisiti può beneficiare di altre competenze e del contributo degli stakeholder. Tra questi possono esserci rappresentanti del business case, stakeholder pertinenti, architetti d'impresa e architetti tecnologici.

Per team che lavorano sullo stesso prodotto, Product Owner e collaboratori di supporto usano un unico Product Backlog ordinato verso un Product Goal condiviso. Ogni Scrum Team è responsabile della consegna di alcune user story. Ci saranno comunque storie specifiche che richiedono l'attenzione e i risultati di più team.

Team di componenti e team di funzionalità

Distribuendo il lavoro tra team diversi, possiamo assegnare loro la responsabilità di componenti software o funzionalità specifiche. Per questo li chiamiamo «Component Team» o «Feature Team».

Team di componenti

Nei team di componenti, ciascun team è responsabile soltanto dell'implementazione di componenti dedicati del sistema complessivo. Per completare una user story, solitamente bisogna dividerla in parti più piccole, implementabili in un singolo componente. Le dipendenze tra i componenti di questi team rendono l'integrazione continua inevitabile per una consegna efficace.

Scrum Product Owner Team

Queste dipendenze possono rendere più difficile consegnare una funzionalità completa in uno Sprint. Vanno affrontate con collaborazione e integrazione: i team di uno stesso prodotto devono comunque creare un Incremento integrato e utilizzabile che soddisfi la Definition of Done condivisa.

Questo aumenta le dimensioni dei lotti e i tempi di attraversamento del lavoro in corso non ancora integrato. Non è un buon risultato: gli Scrum Team dovrebbero puntare a consegnare incrementi software rilasciabili in lotti più piccoli e con tempi più brevi.

Il vantaggio dei team di componenti è che facilitano la concentrazione e lo sviluppo di competenze sui dettagli architetturali e progettuali di componenti specifici. Questo può essere molto utile per componenti che richiedono ricerca e innovazione.

D'altro canto, i membri si specializzano solo in singoli componenti del sistema complessivo. Possono perdere la visione d'insieme e la consapevolezza delle necessità aziendali delle funzionalità.

Ricorda che i clienti ci pagano per consegnare funzionalità con cui gestire le proprie attività, non componenti. Senza un'attenzione costante alle funzionalità, ottimizzazione complessiva e integrazione possono richiedere più tempo. Poiché le decisioni dei team di componenti tendono a ottimizzare singoli componenti, possono creare colli di bottiglia invisibili per successo e prestazioni della soluzione complessiva.

Team di componenti

Team di funzionalità

I team di funzionalità sono pienamente responsabili dell'implementazione delle user story come specificate nel Product Backlog. I team non devono più essere suddivisi per componente. Ogni Feature Team consegna una funzionalità pienamente operativa e il valore aziendale associato.

Team di funzionalità

I membri dei team di funzionalità hanno competenze interfunzionali. Operano con la massima autonomia possibile per consegnare rapidamente. Il vantaggio è che il team mantiene la conoscenza del sistema, agevolando l'integrazione delle proprie funzionalità con il resto del sistema.

Può però essere più difficile acquisire conoscenze sufficienti sui componenti. Inoltre, creare un team di funzionalità autonomo, capace di consegnare rapidamente e indipendentemente, richiede tempo: costruire un team interdisciplinare efficace non è facile. Eppure sono questi i team ad alte prestazioni che portano a termine il lavoro nella maggior parte delle organizzazioni, probabilmente anche nella tua.

Come scegliere tra team di componenti e team di funzionalità?

Nella pratica, la maggior parte delle grandi organizzazioni usa sia team dedicati ai componenti sia team di funzionalità.

Team di componenti e di funzionalità

Nel grafico, il team C è un team di componenti. Fornisce servizi infrastrutturali pianificati e su richiesta agli altri team, che operano come team di funzionalità. Il team C non implementa direttamente user story complete dall'inizio alla fine. Soddisfa i requisiti delle storie che i team di funzionalità si sono impegnati a consegnare.

Questo permette di ridurre al minimo, nei team di funzionalità, il numero di persone qualificate che devono conoscere quei componenti.

Lo Scrum Master nell'ambiente di progetto distribuito

In un ambiente di progetto distribuito, il ruolo dello Scrum Master è ancora più essenziale. In queste configurazioni:

• Occorre un ulteriore impegno per allineare i team ai valori del framework Scrum,
• Serve più tempo per definire norme (standard) dei singoli team e del progetto che influenzano numerosi team,
• Infine, le maggiori dipendenze tra team e risultati da consegnare comportano molti impedimenti.

Lo Scrum Master deve essere accessibile ed efficace nel sostenere il team. La presenza nella stessa sede può aiutare, ma non è un requisito Scrum e il supporto remoto è possibile. L'organizzazione distribuita deve consentire allo Scrum Master di:

• Favorire la rimozione degli impedimenti ai progressi del team,
• Aiutare il team a definire accordi di lavoro efficaci e
• Aiutarlo a migliorare l'uso del framework Scrum.

Alcune organizzazioni usano un Lead (Primary) Scrum Master per sostenere coaching e coordinamento tra team. È un modello organizzativo facoltativo, non una gerarchia obbligatoria né una sostituzione delle responsabilità di ciascuno Scrum Team.

Ogni Scrum Team nell'organizzazione più ampia mantiene la responsabilità dello Scrum Master e necessita di supporto efficace per eventi, autogestione e miglioramento propri.