In breve:
Condividere lo stesso raggio di mischia tra diversi gruppi di mischia, solo per dividere il carico di lavoro, è contro lo spirito di mischia ed è destinato a fallire.
Inoltre, gli sviluppatori non sono solo una capacità intercambiabile per elaborare le storie degli utenti: gli sviluppatori accumulano conoscenza durante ogni sprint e la condividono all'interno del piccolo team. Questa conoscenza deve rimanere disponibile negli sprint successivi per garantire un'efficienza sostenuta.
Sarai certamente deluso di sentire questo. Ma fortunatamente c'è una speranza dalla parte del Nexus, se sei pronto ad adattare un po 'il tuo approccio.
Dettaglio: perché è contro i principi di mischia?
Il problema con il PO
Scrum si basa sul presupposto che un Product Owner (PO) è totalmente responsabile del prodotto nel campo di applicazione e decide in merito alle priorità. In base alla guida Scrum :
The Product Owner is responsible for maximizing the value of the
product resulting from work of the Development Team.
The Product Owner is the sole person responsible for managing the
Product Backlog.
Nella tua situazione il singolo PO è un collo di bottiglia. Quindi vuoi avere più PO. Ma poi le OP non sono più l'unico responsabile. E se ci sono diverse OP, hanno tutte la stessa comprensione (e proprietà) del prodotto?
Un paio di riunioni periodiche non risolveranno questo problema. O ci saranno tre OP che possiedono il prodotto con necessariamente una diversa comprensione del prodotto. O ci saranno un PO e due assistenti che non hanno più il potere richiesto. Questo non sarà più Scrum.
Il problema con i team
Uno dei principi di Scrum è che i team sono autonomi, si organizzano e hanno tutte le competenze per avere successo. Alcune citazioni dalla guida di Scrum:
teams have all competencies needed to accomplish the work without
depending on others not part of the team.
Scrum recognizes no sub-teams in the Development Team
accountability belongs to the Development Team as a whole.
Di fatto, la tua organizzazione deve avere tre sottoinsiemi che sono corresponsabili per il prodotto in generale.
Rendere diversi team che lavorano sullo stesso ambito solo per dividere il carico di lavoro, si tradurrà in una squadra che dipende da un'altra (ad esempio se una squadra deve sviluppare un perfezionamento di una storia utente fatta da un'altra squadra). Perderai tutte le sinergie che Scrum cerca di raggiungere.
Il ridimensionamento di Scrum non è un problema!
Scrum of Scrum
La mischia della mischia è l'approccio più comune. Ci sono diversi team (e quindi diversi PO), ma ognuno è responsabile di un sottoprodotto. Naturalmente ci potrebbe essere qualche sovrapposizione tra le squadre, ma è limitata alla frontiera tra sub -prodotti e ben gestiti nella mischia della mischia. La scalabilità segnalata è oltre 200 e fino a 1000 membri del team.
Nexus: una soluzione per te?
L'approccio Nexus è più vicino a quello che stai cercando. È stato sviluppato dagli inventori di Scrum.
Un Nexus ha un singolo PO (e quindi una chiara proprietà del prodotto) e un singolo SM, ma diversi team integrati. L'approccio affronta in dettaglio l'integrazione tra i team e la sincronizzazione dell'intero processo Scrum. A tale scopo utilizza un team di integrazione strettamente accoppiato (più strettamente accoppiato rispetto alla mischia di mischia).
L'arretrato è suddiviso tra i team in modo da minimizzare le dipendenze (in modo da aumentare l'autonomia di ogni squadra). Sarai comunque lieto che non vi sia alcun obbligo di identificare diversi sottoprodotti. Tuttavia, questo approccio tiene conto dell'aspetto di costruzione della conoscenza che ho menzionato prima:
To the extent that requirements, team members’ knowledge, and
code/test artifacts are mapped to the same Scrum Teams, dependency
between teams can be reduced.
La scalabilità riportata è di tre o nove squadre di mischia, ovvero 9x9 + 2 = 83 persone.