Il Team Scrum dovrebbe consistere di un massimo di dieci persone. Ma cosa fare quando un gruppo più grande di specialisti deve lavorare su un progetto? O se l’organizzazione decide di seguire un modo di gestione agile? Per risolvere questo problema, gli sviluppatori Scrum hanno proposto Scrum@Scale. È un’architettura senza scala per organizzare interi team secondo i principi Scrum.
Scaling Scrum – indice:
Introduzione
Non appena un’organizzazione cresce, compaiono nuovi tipi di problemi. Ad esempio, un calo dell’efficacia dei dipendenti causato da una struttura interna complessa, decisioni difficili o impostazione della direzione. Le aziende che operano in modo agile a livello di piccoli team di progetto spesso cercano di scalare.
Molte imprese funzionano bene senza scalare Scrum. Anche se molti Team Scrum stanno operando simultaneamente, non hanno bisogno di coordinamento poiché i gruppi operano in modo indipendente. Tuttavia, ciò non significa che si tratti di uno Scrum multi-team. La necessità di scalare si presenta solo quando la maggior parte dell’organizzazione sta lavorando su un prodotto e può sincronizzare i suoi molteplici Team Scrum in modo efficace.
La maggior parte delle organizzazioni che adottano metodi di gestione agile su larga scala sceglie il modello SAFE, o Scaled Agile Framework. Oggi, tuttavia, non ci concentreremo su SAFE ma discuteremo un modello diverso chiamato Scrum@Scale, poiché secondo il 15° rapporto State of Agile del 2021, è la seconda scelta migliore tra le aziende che optano per l’agile.
Scrum@Scale
Nel 1996, i creatori di Scrum, Jeff Sutherland e Ken Schwaber, stavano lavorando a un grande progetto. Mentre lo facevano, avevano difficoltà a mantenere i team più piccoli che lavoravano in Scrum sincronizzati. Hanno trovato un modo per scalare, che alla fine hanno chiamato Scrum@Scale.
Analogamente alla Guida ufficiale di Scrum, c’era la Guida Scrum@Scale, che definisce questo modo di scalare il lavoro come:
Un framework all’interno del quale reti di Team Scrum operano seguendo la Guida Scrum per risolvere problemi complessi e adattivi e consegnare creativamente prodotti con il massimo valore possibile.
La premessa di base di Scrum@Scale è la semplicità e l’efficienza. Pertanto, il suo funzionamento si basa su un’architettura senza scala. In altre parole, utilizza Scrum per scalare Scrum. In questo modo, un team scrum composto da individui che agiscono come Product Owner, Scrum Master o Sviluppatore diventa lo Scrum degli Scrum: un team composto da team.
Lo Scrum degli Scrum
Lo Scrum degli Scrum è un team scrum con persone che ricoprono ruoli tradizionali di Scrum. Tuttavia, poiché il compito dello Scrum degli Scrum è integrare i risultati del lavoro di diversi Team Scrum, ha bisogno di ulteriori ruoli:
- Team Product Owner – un gruppo di Product Owner che si incontra per concordare le priorità e creare una visione del prodotto coesa
- Chief Product Owner – il Product Owner del Team Scrum o una persona che si occupa esclusivamente dello Scrum degli Scrum
- Scrum of Scrums Master – la persona che supervisiona l’efficacia dello Scrum degli Scrum.
Si incontrano agli stessi Eventi Scrum e utilizzano simili Artifact.
Ulteriori problemi di scaling e Scrum@Scale
L’architettura senza scala di Scrum@Scale significa che consente di scalare più di una sola volta. Se un’organizzazione ha bisogno di coordinare team su una scala ancora più grande, può impostare lo Scrum degli Scrum.
Tuttavia, scalare Scrum, come qualsiasi altra metodologia di gestione, ha i suoi difetti, e in questo caso, sono simili a quelli dei Team Scrum di base, solo che sono proporzionalmente maggiori. Ecco perché raccomandiamo di elaborare i dettagli della collaborazione all’interno di ciascun Team Scrum prima di iniziare Scrum su larga scala. Suggeriamo di scalare Scrum per team esperti che hanno una buona conoscenza e comprensione dei valori e del funzionamento di Scrum.
Scaling Scrum – riepilogo
Scalare Scrum non è un gioco da ragazzi. Richiede ai Team Scrum di applicare proficientemente i principi Scrum e sincronizzare i loro compiti con altri Team Scrum. Pertanto, la domanda fondamentale a cui rispondere è: È necessario scalare? Solo perché ci sono molti Team Scrum in un’organizzazione non significa automaticamente che coordinarli porterà a risultati migliori.
Se un’organizzazione sceglie di aumentare Scrum, guadagna un’architettura senza scala che può essere ulteriormente aumentata con successo. Tuttavia, ogni aumento è accompagnato da un aumento del livello di complessità con cui il Team Product Owner, il Chief Product Owner e lo Scrum of Scrums Master devono confrontarsi.
Se ti piace il nostro contenuto, unisciti alla nostra comunità di api operose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.
Scrum Guide:
- Glossario dei termini, ruoli e nozioni di base
- Che cos'è Scrum?
- Valori Scrum
- Come implementare Scrum nella tua azienda?
- Team Scrum - cos'è e come funziona?
- Chi è un Product Owner?
- Gli errori più comuni del Product Owner
- Chi è lo Scrum Master?
- I più comuni errori del Scrum Master
- Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
- Team di sviluppo in Scrum
- I più comuni errori degli sviluppatori
- Artefatti Scrum
- Scaling Scrum
- Sprint Backlog
- Cos'è il Product Backlog?
- Cosa sono le User Stories?
- Creare la migliore User Story con INVEST
- I più comuni errori nelle User Story
- Criteri di accettazione della User Story
- Stima e Punti Storia in Scrum
- Planning Poker
- Gioco di Stima del Team
- Definizione di Incremento
- Eventi Scrum
- Che cos'è un grafico di burndown?
- Vantaggi e svantaggi del grafico di burndown
- Bacheche Kanban in Scrum e Scrumban
- Velocità nello Scrum - Velocità del Team di Sviluppo
- Daily Scrum Scrum giornaliero
- Pianificazione dello Sprint
- Revisione dello Sprint
- Che cos'è una Retrospettiva Sprint?
- Errori comuni durante una Retrospettiva di Sprint
- Nutrimento del Product Backlog
- Come creare e interpretare un grafico di burndown?