Guida Scrum | 16. Scaling Scrum

Lo Scrum Team dovrebbe essere composto da un massimo di dieci persone. Ma cosa fare quando un gruppo più ampio di specialisti deve lavorare su un progetto? O se l'organizzazione decide di seguire una modalità agile di gestione? Per risolvere questo problema, gli sviluppatori di Scrum hanno proposto [email protected] Si tratta di un'architettura senza scalabilità per organizzare interi team secondo i principi di Scrum.

Scaling Scrum – sommario:

1. introduzione
2. [email protetta]
3. Lo Scrum di Scrum
4. Ulteriori problemi di ridimensionamento e [protetto dalla posta elettronica].
5. Riepilogo

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, da un processo decisionale o da un'impostazione di direzione difficili. Le aziende che operano in modo agile a livello di piccoli team di progetto spesso cercano di aumentare la scalabilità.

Molte aziende se la cavano bene senza scalare Scrum. Anche se molti Scrum Team stanno funzionando contemporaneamente, non hanno bisogno di coordinamento poiché i gruppi operano in modo indipendente. Tuttavia, questo non significa che sia 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 efficacemente i suoi molteplici Scrum Team.

La maggior parte delle organizzazioni che adottano metodi di gestione agile su larga scala scelgono il modello SAFE o Scaled Agile Framework. Oggi, tuttavia, non ci concentreremo su SAFE ma parleremo di un modello diverso chiamato [email protected] , poiché secondo il 15° rapporto sullo stato dell'agile del 2021, è la seconda scelta migliore tra le aziende che optano per l'agile.

[email protetta]

Nel 1996, i creatori di Scrum, Jeff Sutherland e Ken Schwaber, stavano lavorando a un grande progetto. Mentre lo facevano, avevano problemi a mantenere sincronizzati i team più piccoli che lavoravano in Scrum. Hanno escogitato un modo per ridimensionarlo, che alla fine hanno chiamato [email protected]

Analoga alla Guida Scrum ufficiale era la Guida [email protected] , che definisce questo modo di ridimensionare il lavoro come:

Un framework all'interno del quale operano reti di Scrum Team seguendo la Scrum Guide per risolvere complessi problemi adattivi e fornire in modo creativo prodotti con il maggior valore possibile.

La premessa di base di [email protected] è semplicità ed efficienza. Pertanto, il suo funzionamento si basa su un'architettura senza scala. In altre parole, usa Scrum per scalare Scrum. In tal modo, uno Scrum Team composto da individui che agiscono come Product Owner, Scrum Master o Developer diventa lo Scrum of Scrum: un team composto da team.

Lo Scrum di Scrum

Lo Scrum of Scrum è uno Scrum Team con persone che assumono ruoli Scrum tradizionali. Tuttavia, poiché il compito di Scrum of Scrums è quello di integrare i risultati del lavoro di diversi Scrum Team, necessita di ulteriori post:

• Product Owner Team : un gruppo di Product Owner che si incontrano per concordare le priorità e creare una visione coesa del prodotto
• Chief Product Owner – Il Product Owner dello Scrum Team o una persona che si occupa esclusivamente dello Scrum of Scrum
• Scrum of Scrum Master – la persona che sovrintende all'efficacia dello Scrum of Scrums.

Si incontrano agli stessi Eventi Scrum e usano Artefatti simili.

Ulteriori problemi di ridimensionamento e [protetto dalla posta elettronica].

L'architettura scale-free di [email protected] significa che consente il ridimensionamento più di una volta. Se un'organizzazione ha bisogno di coordinare i team su una scala ancora più ampia, può impostare Scrum of Scrum.

Tuttavia, lo scaling Scrum, come qualsiasi altra metodologia di gestione, ha i suoi difetti, e in questo caso sono simili a quelli degli Scrum Team base, solo che sono proporzionalmente maggiori. Ecco perché consigliamo di elaborare i dettagli della collaborazione all'interno di ogni Scrum Team prima di avviare Scrum su scala più ampia. Suggeriamo il ridimensionamento di Scrum per i team esperti che hanno una buona conoscenza e comprensione dei valori e del funzionamento di Scrum.

Scaling Scrum – riepilogo

Scaling Scrum non è un gioco da ragazzi. Richiede agli Scrum Team di applicare abilmente i principi di Scrum e sincronizzare i propri compiti con altri Scrum Team. Pertanto, la domanda di base a cui rispondere è: è necessario il ridimensionamento? Solo perché ci sono molti Scrum Team in un'organizzazione non significa automaticamente che coordinarli porterà risultati migliori.

Se un'organizzazione sceglie di aumentare Scrum, ottiene un'architettura senza scalabilità che può essere ulteriormente aumentata con successo. Tuttavia, ogni potenziamento è accompagnato da un aumento del livello di complessità che il Product Owner Team, il Chief Product Owner e lo Scrum of Scrum Master devono affrontare.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog