Scrum Team è diventato troppo grande, come dovrebbe essere diviso

Due cose da ricordare:

• Uno, mentre le riunioni giornaliere di scrum possono essere utili, per alcuni progetti uno o due incontri a settimana possono essere sufficienti.

• Due, avere persone che partecipano a più incontri di mischia non è una cosa negativa di per sé (avere persone che dividono il loro tempo tra progetti è inefficiente, ma a volte è vita / lavoro).

Gli incontri Scrum / Standup dovrebbero essere abbastanza piccoli in modo tale che tutti i presenti siano sinceramente interessati a ciò che ognuno ha da dire. Questo di solito è di cinque persone o meno. I product manager / stakeholder possono essere felici di avere una singola riunione, ma gli sviluppatori la odieranno (e dovrebbero), e la qualità di ciò che verrà discusso ne risentirà.

Suggerirei di suddividere le cose in piccoli scrum / standups e diminuire la loro frequenza in modo che ogni sviluppatore non abbia una media di 1,5 scrum / standup al giorno. Potresti anche avere una riunione una volta alla settimana (o ogni due settimane) in cui vengono visualizzati i lead del team (o le squadre che decidono di inviare) e fornire ulteriori aggiornamenti / dimostrazioni agli stakeholder e agli altri team. Ciò farà risparmiare tempo e, si spera, genererà conversazioni molto più significative.

La domanda menziona Scrum, quindi possiamo iniziare da lì.

Se chiedi a un purista di Scrum, ti diranno che un team Scrum si auto-organizza. Ciò significa che se stai formando uno o più team Scrum in un'organizzazione, le squadre dovrebbero essere autorizzate a strutturarsi in modo appropriato. Uno Scrum Master (o un altro tipo di allenatore) insegnerà al team i ruoli, il dimensionamento delle squadre e aiuterà i team a garantire che siano interfunzionali o che abbiano un piano per ottenere un cross-funzionale.

Ora, Scrum è costruito attorno a una squadra di 4 e 11 persone (vedi la mia risposta qui per la logica ). Scrum non ha molte indicazioni per trattare con più team. Tuttavia, esistono framework che supportano più team: Nexus è degli stessi che hanno progettato Scrum ed è progettato per scalare fino a 3-9 squadre che utilizzano Scrum, Large-Scale Scrum (LeSS) è un altro framework che aiuta a scalare i principi Scrum fino a più team, il Scaled Agile Framework (SAFe) offre alcuni gusti diversi per organizzazioni di dimensioni diverse e DADlined Agile Delivery (DAD) fornisce una struttura che considera l'intera organizzazione operativa in un ambiente snello o agile insieme a cicli di vita e considerazioni diversi per aspetti non tecnici delle organizzazioni.

Se guardi i dettagli di Nexus, LeSS e SAFe, vedi che sono raccomandate squadre più piccole. Nexus e LeSS sono formati attorno ai team Scrum, quindi i team dovrebbero essere tra 4 e 11 persone che lavorano tutti in Scrum standard. SAFe raccomanda 5-10 persone e considera le squadre che lavorano in qualcosa di diverso da Scrum come base per il loro approccio. DAD, tuttavia, ha delle considerazioni per un certo numero di team, inclusi due approcci per ciò che chiama Squadre di medie dimensioni (squadre di età compresa tra 25 e 30 persone) o Medium Sized Team of Teams (gruppi da 12 a 50 organizzati in sottogruppi).

Quindi, sul problema: come abbattere una squadra.

Quasi ogni metodo agile considera il team interfunzionale. La domanda proponeva tre metodi per abbattere le squadre. Sembra che il terzo metodo, abbattendo le squadre in base al tipo di lavoro, sia il meno coerente con i metodi agili in quanto i team hanno maggiori probabilità di non essere interfunzionali. Qualsiasi metodo di team dovrebbe fornire al team tutte le competenze necessarie per fornire un valore significativo agli stakeholder.

La mia raccomandazione sarebbe quella di abbattere i team per componente consegnabile (pacchetto) e fornire al personale il team con sviluppatori che hanno già o possono sviluppare competenze in quei particolari componenti. Probabilmente dovresti anche formare "meta team" dei tuoi ruoli per coordinare e condividere le conoscenze tra i team, questo è particolarmente vero per i tuoi product manager e per gli esperti di architettura per garantire una visione e una direzione comuni tra i team. Finché è possibile personale ogni squadra con una persona in un ruolo di coaching / leadership, un proprietario del prodotto, un proprietario di architettura e una manciata di sviluppatori, è possibile applicare i principi agili. Per promuovere un team completamente interfunzionale, ti consiglio di assicurarmi che ci siano abbastanza specialisti (pensa che tester indipendenti, progettisti e ingegneri dell'esperienza utente, simili) supportino ogni squadra.

Consiglierei di considerare il DAD come una base - in genere è abbastanza vicino a Scrum che una transizione sarà facile per la maggior parte coinvolta, ma fornisce una guida per le situazioni in cui è possibile abbattere una squadra ma avere anche squadre che sono troppo i metodi Scrum grandi e tradizionali si rompono.