Troppo grande per scalare – Guida alle dimensioni ottimali del team Scrum

Ascolta la versione audio di questo articolo

Che tu stia lavorando in una piccola startup o su un nuovo prodotto in una grande azienda, è probabile che arrivi a un punto in cui hai troppe persone in una squadra. Identificare i segnali all'inizio ti eviterà di raggiungere la fase più inefficiente della squadra.

Ogni prodotto è diverso, così come i team che ci lavorano. Pertanto, dividere una squadra ti richiederà anche di prendere alcune decisioni che riflettano le tue circostanze. Alcune cose da considerare sono:

• Come mantenere l'integrità del know-how quando i compagni di squadra non lavorano più insieme
• Dovresti dividere le funzioni (es. team di front-end e back-end)?
• Le nuove squadre dovrebbero avere arretrati separati?
• Il team di gestione del prodotto dovrebbe crescere di conseguenza?

Quando dovresti iniziare a creare una seconda squadra?

L'indicazione più ovvia per iniziare a pensare a una divisione della squadra o all'aggiunta di una nuova squadra è quando il budget aumenta. Ciò può verificarsi a causa di un nuovo round di investimento in una startup o di nuovi obiettivi per il tuo prodotto in un'azienda. Se l'aumento del budget è così sostanziale che il tuo team crescerà di 3 volte o più, allora è un gioco da ragazzi che dovrai dividere il tuo team attuale per distribuire il know-how. Tuttavia, le decisioni non diventano così chiare quando l'aumento del budget è incrementale e si finisce per aggiungere alcune nuove persone al roster. Se, ad esempio, hai in programma di far crescere la tua squadra da 7 a 11 persone, è necessaria una divisione? Agile promuove piccoli team ma promuove anche individui e interazioni su processi e strumenti. Avere due o più team crea inevitabilmente più processi per poter lavorare in sincronia.

Cosa dicono gli esperti?

Jeff Bezos, il fondatore di Amazon, ha utilizzato la regola delle due pizze sia per le riunioni che per i team. Ciò significa che ciascuno dovrebbe avere solo tante persone quante due pizze possono sfamare durante il pranzo.

La Scrum Guide suggerisce di avere da tre a nove membri del team che stanno effettivamente eseguendo lo sprint backlog. Ciò significa che non includerai il Product Owner o lo Scrum Master nel totale a meno che uno di loro non stia implementando gli elementi dello sprint backlog.

Questi numeri sembrano avere un senso intuitivo, ma dietro c'è anche un po' di matematica. Se pensi a una squadra, ogni persona è come un nodo e si collega ad altri nodi. Queste sono le relazioni interpersonali tra i compagni di squadra. Possono essere amichevoli, competitivi, dispettosi o premurosi. Qualunque sia la relazione tra due persone, è comunque un legame che richiede una certa capacità mentale da parte di ciascuna persona. Man mano che una squadra cresce, questi numeri di questi collegamenti non crescono in modo lineare. La formula per i collegamenti tra nodi è \(n(n-1)/2\). Ecco il grafico di crescita dei link:

Il grafico illustra chiaramente da un punto di vista matematico perché i team operano in modo più efficiente quando non sono troppo grandi. Se prendiamo da 3 a 9 membri del team suggeriti dalla Scrum Guide, avremo tra 3 e 36 link. Se crescessimo fino a 15 persone, avremmo più di 100 link. Una squadra di questo tipo potrebbe operare in modo efficiente solo se i suoi compiti fossero molto ben definiti e raramente si sovrapponessero o se esistessero dei sottogruppi non ufficiali. Non è né il caso né lo si desidera quando si lavora sulla base dei principi Agile.

Segni che la squadra sta diventando troppo grande

Scrum quotidiano

A volte indicato come il daily standup, il daily scrum è un incontro dell'intero team per discutere i progressi e gli impedimenti dello sprint. La Scrum Guide suggerisce di cronometrarli a 15 minuti e questa è una buona cartina di tornasole per le dimensioni del team. Se inizi a notare che la tua squadra sta superando la barra dei 15 minuti, può indicare una delle due cose:

• Le mischie giornaliere non sono efficienti. Le persone entrano in troppi dettagli. Oppure non c'è un chiaro ordine di parola e ci vuole tempo prima che i compagni di squadra parlino. Forse il Product Owner o lo Scrum Master sta usando lo Scrum quotidiano come un'opportunità per fornire vari aggiornamenti non correlati allo sprint.
• La squadra è troppo grande. Se le mischie giornaliere sono efficienti, ma stai ancora superando i 15 minuti, allora potresti semplicemente avere troppe persone nella squadra. Dovresti anche iniziare a notare che le persone stanno perdendo interesse perché c'è un limite alla quantità di informazioni che una persona può acquisire. Se troppe persone forniscono aggiornamenti, diventa difficile tenere traccia dei progressi di tutti e comprendere lo stato del team . Questo fa sì che le persone si rivolgano all'interno e riflettano solo sui loro progressi piuttosto che cercare opportunità per aiutare gli altri.

Grooming e pianificazione dello sprint

Sia il grooming che la pianificazione dello sprint sono attività legate alla scomposizione delle storie degli utenti e alla stima dei tempi o delle dimensioni di consegna. Mentre avere più persone può aiutare il team a prendere decisioni migliori, avere troppe persone potrebbe portare il team a un punto morto. Ci sono sempre modi diversi per portare a termine lo stesso compito e il numero di argomenti da ciascuna parte aumenta con il numero di persone nella squadra.

Come per la mischia quotidiana, non confondere una sessione di pianificazione inefficiente con il team troppo grande. In definitiva, è compito dello Scrum Master rendere le cerimonie di Scrum efficienti ed efficaci.

Retrospettiva

Durante una retrospettiva, i membri del team possono risolvere qualsiasi argomento o conflitto e trovare modi per migliorare il proprio processo di lavoro. Le retrospettive ci insegnano l'arte del compromesso in quanto ci fa cercare un terreno comune tra parti diverse. Una squadra è tanto potente quanto i suoi membri sono disposti a scendere a compromessi sulle loro differenze.

Tuttavia, come con la pianificazione dello sprint, troppi membri del team creano troppi collegamenti, che sono tutti potenziali punti di conflitto. Inizia a notare se trovi un terreno sempre meno comune durante le retrospettive. Potrebbe essere un segno che la squadra è troppo grande e trarrebbe vantaggio dalla divisione.

Come dividere la squadra

A prima vista, dividere la squadra è un compito relativamente facile. Dividi i membri del team in due gruppi, assicurati che ognuno abbia persone con esperienza simile e definisci gli obiettivi per i nuovi team. Tuttavia, ci sono alcune cose da considerare che potrebbero avere un grande impatto sul successo futuro delle nuove squadre.

Morale di squadra

Probabilmente una delle cose più importanti da tenere a mente è il morale della squadra. Alla fine della giornata, saranno le persone del team che dovranno lavorare nella nuova composizione. Se la squadra è matura in termini di principi Agile, allora dovrebbe essere in grado di fare la divisione da sola. Questo è il risultato più desiderabile perché i membri del team conoscono meglio le loro relazioni interne, chi lavora meglio con chi e chi potrebbe trarre vantaggio dall'essere in team separati.

Team interfunzionali

Scrum promuove team interfunzionali "con tutte le competenze necessarie per creare un incremento di prodotto". Questo vale quando si ridimensiona a due o più team. Per molti sviluppatori, soprattutto se non conoscono Agile, la tendenza naturale è quella di pensare in linea con le linee tecniche. Ad esempio, le squadre spesso vogliono dividersi in squadre di back-end e front-end. Questo potrebbe avere senso in alcune rare occasioni, ma come product manager dovresti sconsigliarlo la maggior parte delle volte. Un team pieno di front-ender non è in grado di fornire da solo un incremento di prodotto e naturalmente inizierà a pensare di più alla capacità tecnica, che è ciò che li unisce. Invece, dovrebbero concentrarsi sul cliente e su come soddisfare le sue esigenze.

Un'altra considerazione interessante sono i ruoli non di sviluppo nella squadra. In varie situazioni, un team potrebbe includere un designer, un analista aziendale o uno specialista del controllo qualità. Una volta divisa una squadra, soprattutto se non stai assumendo troppe nuove persone, sorge un dilemma su cosa fare con questi ruoli. Dovrebbero dividere il loro tempo tra le squadre? Dovresti assumere nuove persone, che si dedicherebbero a un solo team? Dovrebbero collaborare con i team di sviluppo o far parte del team di prodotto?

Non c'è davvero un buon consiglio unico per questo perché ogni prodotto è così diverso. È meglio prendere queste decisioni insieme al team, tenendo presente che potrebbe essere necessario correggere la rotta lungo il percorso.

Le squadre dovrebbero avere arretrati separati?

Se una squadra è divisa, la domanda naturale è se debbano lavorare sullo stesso arretrato o averne di separate. Possiamo guardare allo Scaled Agile Framework per una guida.

Scrum@Scala

Scrum@Scale è una metodologia sviluppata dal creatore della Scrum Guide. Scrum@Scale non è molto prescrittivo e non delinea in modo specifico come gestire i product backlog. Tuttavia, rileva due punti:

• Il processo a livello di team è lo stesso descritto nella Guida Scrum.
• I proprietari di prodotti formano un team di proprietari di prodotti, in cui creano un unico backlog unificato. Questo viene fatto per evitare duplicazioni di lavoro e per creare visibilità all'interno dell'azienda. Allo stesso tempo, i team hanno i loro backlog separati che alimentano gli elementi dal backlog unificato.

Quindi, in sostanza, Scrum@Scale immagina i nuovi team con i rispettivi PO e backlog. Aggiunge solo alcune strutture aggiuntive per coordinare il lavoro tra i team. Scrum@Scale funziona al meglio con diversi, decine o centinaia di team, ma può fornire informazioni preziose anche se si lavora con due team.

Scrum su larga scala (Meno)

LeSS promuove un approccio interessante al product backlog. In LeSS, un product owner lavora con da due a otto team. Potrebbe sembrare impossibile che un PO funzioni con così tanti team. La filosofia di LeSS prevede che l'ordine di acquisto lavori a livello astratto e deleghi ai team le responsabilità di perfezionamento degli articoli del backlog di prodotto. In questo caso, i team di sviluppo interfunzionali dovrebbero includere anche la conoscenza del dominio aziendale per essere in grado di fornire un incremento del prodotto. In LeSS c'è un solo backlog.

Come tenersi aggiornati

Per un product manager, più team significano più lavoro per monitorare i progressi e rispondere alle domande.

Dai priorità alle riunioni

Se stavi partecipando alle mischie quotidiane di una singola squadra, molto probabilmente continuare questa abitudine sarà improduttivo. Considera gli Scrum giornalieri come un'opportunità per entrare per avere un'idea delle squadre e ricordare loro che sei disponibile per le discussioni.

La tua partecipazione alle sessioni di pianificazione dello sprint dipenderà dalla maturità delle squadre. Se i team includono molti volti nuovi o non lavorano con Agile da molto tempo, sarà necessaria una guida da parte tua. Anche se ti senti sicuro di lasciare che il team pianifichi senza la tua presenza, assicurati di essere disponibile a fare un salto o a chattare con il team durante la pianificazione in caso di domande.

Le revisioni dello sprint dovranno rimanere la tua massima priorità e tutte dovrebbero essere prese in considerazione. Le revisioni dello sprint sono un'opportunità per ottenere feedback di prima mano da tutte le parti interessate presenti e dal team stesso. È un momento in cui le ipotesi sono convalidate e non dovrebbero mancare.

Coinvolgi di più con gli Scrum Master

Anche se potresti ridurre il tuo impegno con alcune delle cerimonie di Scrum, dovresti raddoppiare la tua collaborazione con lo Scrum Master. Potrebbe essercene più di uno ora dopo la divisione del team, nel qual caso dovresti lavorare a stretto contatto con tutti loro.

Assicurati di poterti fidare di loro per dare una visione onesta dei progressi della squadra e di eventuali problemi che sorgono durante gli sprint. Queste relazioni ti permetteranno di rimanere aggiornato senza la necessità di impegnarti in tutte le cerimonie di scrum.

Presenta Scrum di Scrum

A volte chiamato meta scrum, uno scrum of scrum è una nuova cerimonia che viene tipicamente introdotta come scala dei processi di scrum. È una replica della mischia quotidiana a un livello superiore. Ogni team designa un ambasciatore, che si incontra tutti i giorni alla mischia degli scrum per discutere di progressi e impedimenti. Questa cerimonia viene utilizzata anche per evidenziare eventuali problemi tecnici tra squadre che potrebbero dover essere risolti.

Prendi in considerazione l'espansione del team di prodotto

Se la configurazione di Scrum richiede che il product manager interagisca attivamente con il team, valuta la possibilità di aggiungere più persone al lato prodotto. Ci sono alcuni modi per avvicinarsi a questo.

Junior Product Manager. Un percorso consiste nell'assumere un ruolo più strategico per te stesso mentre aggiungi dei product manager junior per gestire alcune delle faccende quotidiane. Potrebbero svolgere alcune attività come il controllo della qualità (QA), la scrittura di specifiche per le storie degli utenti o la creazione di modelli di alto livello per nuove funzionalità.

Analisti aziendali. Un altro modo è far lavorare uno o più analisti aziendali all'interno o al fianco dei team. Il product manager può collaborare con gli analisti aziendali per identificare i presupposti del prodotto e quindi consentire agli analisti aziendali di trovare il modo di convalidarli tramite ricerche o nuove funzionalità.

Conclusione

Man mano che la tua squadra cresce, è probabile che inizi a notare alcuni segni che sta diventando troppo grande, specialmente in:

• Mischia quotidiana. Se stai superando il lasso di tempo di 15 minuti durante le mischie quotidiane e vedi che le persone iniziano a perdere interesse.
• Pianificazione dello sprint. Se finisci in stallo durante la pianificazione dello sprint sempre più spesso.
• Retrospettiva. Se inizi a notare che sta diventando più difficile raggiungere compromessi durante le retrospettive.

Tutto ciò indica il fatto che potrebbe essere necessario dividere la squadra. Dividere una squadra è apparentemente un compito facile, ma ha anche conseguenze durature e ogni product manager ha alcune cose da considerare quando lo fa:

• Morale di squadra. Idealmente, dovresti lasciare che il team decida come dividere per ridurre al minimo il numero di buoni rapporti di lavoro scartati.
• Team interfunzionali. I team dovrebbero avere tutte le competenze necessarie per creare un incremento di prodotto.
• arretrato di prodotti. Decidi se i tuoi team avranno un backlog separato o unificato.

Tenere traccia di due o più squadre richiederà la definizione delle priorità. Un efficace product manager dovrebbe pianificare come mantenersi aggiornati con i nuovi team:

• Dai priorità alle riunioni. Pensa attraverso quali cerimonie Agile valgono il tuo tempo e quali possono essere ignorate.
• Impegnarsi con gli Scrum Master. Usa gli Scrum Master come proxy del tuo team e raccogli informazioni da loro.
• Espandi il team del prodotto. Aggiungi persone che lavorino con te e aiuti con attività ripetitive quotidiane o conduci ricerche sugli utenti e analisi di mercato.

Utilizzando questi suggerimenti, dovresti essere in grado di avere una divisione netta del team. Se i tuoi team continuano a crescere e ne aggiungerai ancora di più in futuro, dovresti leggere Scaled Agile Framework, che fornisce suggerimenti su struttura e processo per Agile su larga scala.