Come gestire i sottoprogetti genericamente accoppiati in Scrum?

In realtà farei un passo indietro e fare la domanda - per la tua soddisfazione - come anche del team - "C'è un problema?" e "Qual è il problema?", se la prima risposta è Sì.

Successivamente, la domanda - "Perché Scrum?" Anche se ci sono ragioni esterne, potrebbe valere la pena di vedere cosa funzionerà meglio per la squadra. In che modo puoi apportare modifiche nel processo per risolvere i problemi specifici che stai affrontando, in modo che anziché guardare dal punto di vista "Come posso implementare Scrum meglio?", Puoi guardare "Come faccio a fornire software migliore / più veloce? E le squadre sono più felici, meno annoiate, più impegnate e produttive? " - e invita il team a collaborare per risolvere il problema.

Se questo ha senso, allora un approccio che suggerirei è di applicare i principi Kanban (visualizzare il tuo lavoro / flusso di lavoro, implementare i limiti Pull e WIP e gestire / ottimizzare il flusso) per migliorare le prestazioni del tuo team Scrum. È possibile che io possa essere accusato di usare un "martello Kanban" per ogni nail software, ma credo che la tua situazione abbia bisogno di una maggiore analisi e comprensione prima di concludere che "fare Scrum meglio" ti aiuterà a raggiungere un posto migliore.

Alcune cose specifiche che l'applicazione dei principi Kanban farà per te -

1. Aiuta a gestire il lavoro dei due team in corsie separate su una scheda Kanban e offri solo una facile comprensione visiva a entrambi i team di ciò che l'altro sta facendo, quanto sono caricati, dove sono i colli di bottiglia, ecc.

2. Poiché il loro recapito è disaccoppiato, puoi esaminare più opzioni da sincronizzare. up, integrare e rendere le uscite dei clienti in modo coerente, fornendo allo stesso tempo l'opportunità a entrambi i team di intraprendere lavori "intangibili" come la riduzione del debito tecnico. Nel processo, potresti decidere di cambiare o rimuovere un intervallo temporale artificiale di 2 o 3 settimane che una definizione di processo arbitraria ti impone.

Nell'esempio riportato di seguito, ciascuno dei tuoi team potrebbe rilasciare il codice per l'integrazione alla propria cadenza e i processi di post-integrazione potrebbero seguire la cadenza richiesta dall'azienda. Se qualcuno dei team ha avuto un intervallo tra gli eventi di rilascio, potrebbe riprendere il lavoro nella corsia intangibile (debito tecnico) e fare quelli mentre attende che l'altra squadra completi il proprio lavoro.

Perunperiododitempo,potresticontinuarearealizzarerilasciinquestomodoopassareaunmodellodiconsegnapiùcontinuo,seilcosto(sforzo)dirilascioèinferiorealcostodiattesa(costoopportunità/tempoalmercato).(Senonhaiancoraincontratoquestoapproccio(Scrumban/Kanban),potrestiessereinteressatoaleggeredipiùsuquestoqui-" Cos'è Scrumban ?"

La situazione

Descrivi il progetto come molto liberamente accoppiato, e af erano due diversi progetti:

• diversi membri del team, ogni squadra è altamente coesa (noi vs.them)
• stack tecnici diversi
• sprint che termina a parte
• attenzione diversa ai requisiti

Dall'altro lato questi progetti sono molto correlati:

• le storie degli utenti di back-end non possono essere concepite in totale isolamento del front-end. Questo è il motivo per cui hai un solo PO per entrambi
Il test
• deve essere integrato, ecco perché alcuni tester lavorano per entrambi.
• potrebbe esistere l'uno senza l'altro?

In effetti sono così interconnessi che c'è un singolo PM, PO, SM e tutti al di fuori del progetto sembrano vederlo come uno. Non c'è fumo senza fuoco ...

Come migliorare?

L'esperienza dimostra che avere team distinti che non parlano l'uno con l'altro finisce nei problemi di architettura non validi . I componenti integrati necessitano di progettazione integrata e comprensione reciproca.

Naturalmente, la noia e lo spreco di risorse devono essere evitati.

Quindi inizia con la mischia quotidiana. La mischia giornaliera è 15 minuti e non di più. Al massimo 7'30 "in cui una metà della squadra potrebbe annoiarsi: con le dimensioni della tua squadra, è 1 minuto per ogni compagno di squadra a parlare. Come potresti annoiarti qui? E se ci sono cambiamenti o ritardi in una squadra , non dovrebbero saperlo gli altri?

Quindi mantieni il comportamento quotidiano quotidiano. Ma assicurati che siano 15 minuti e non di più. Se ciò non è possibile, organizzare una riunione quotidiana sub-team, in cui selezionare gli argomenti per la riunione congiunta e effettuare ogni 10 minuti. Sono 20 minuti utilizzati in modo efficiente al giorno.

Ora la pianificazione dello sprint dovrebbe andare di pari passo, in modo che il front-end possa ottenere ciò che serve dal back-end a tempo debito. Ma ogni sottogruppo dovrebbe fornire le stime per il proprio lavoro. È ridicolo stimare il lavoro dell'altro lato: questo renderebbe i dati inaffidabili, causerebbe decisioni sbagliate e quindi causerebbe problemi. E in ogni pianificazione, c'è una parte che è troppo dettagliata per essere di interesse generale. Questo potrebbe essere fatto anche da sottoteam.

Revisione e retro richiedono analogamente un'interpretazione comune dell'intero progetto, dopo una prima discussione all'interno dei sottogruppi in cui si potrebbe decidere cosa intensificare.

Che cosa succede se è ancora troppo lungo

Sono stato pesantemente coinvolto in grandi progetti interfunzionali, con in genere 4-7 sottogruppi. In questo caso, è difficile fare frequenti incontri con tutti. Quindi l'alternativa è un approccio a cascata: ogni squadra fa i suoi incontri e un rappresentante del team partecipa a un incontro globale (e fornisce un feedback sui risultati globali se è diverso dalle aspettative). Tuttavia, questo potrebbe essere eccessivo nel tuo contesto attuale.

Se questo è un progetto a lungo termine, dividi le squadre. Sì, è abbastanza drastico. Tuttavia, tu stesso stai già riconoscendo che in pratica hai a che fare con due team:

how do we make sure the important interteam questions get addressed

Guardando il numero di persone coinvolte ...

we are 7-9 developers and 3-4 testers and a few other roles

... non dovrebbe essere un problema creare due squadre. Scrum sostiene non più di 9 persone in un'unica squadra. Sì, stai facendo Scrum-ish, ma ancora.

Dopo la divisione, ciascuna squadra può concentrarsi completamente sui rispettivi prodotti. Potresti comunque avere lo stesso proprietario del prodotto e lo stesso scrum master per entrambi i team. Avere lo stesso ordine di acquisto renderà più semplice l'allineamento con le aspettative degli stakeholder, in quanto esiste una sola fonte di requisiti.

Ora per l'integrazione delle due parti. Sì, sarà necessario un certo sforzo. Da un punto di vista tecnico, un sistema di costruzione continua che integri le due parti sarebbe fantastico. Molto più importante, i team devono comunicare, parlarsi e riallinearsi a intervalli regolari. La nomina di un membro per squadra come ambasciatore dell'integrazione nell'altra squadra potrebbe essere un'opzione. I team responsabilizzati troveranno un modo per integrare efficacemente il loro lavoro con il lavoro svolto da altri. Lo stanno già facendo, vero?

Se lo trovi difficile, ti consigliamo di leggere la guida Scrum Nexus . È finalizzato a più vaste configurazioni multi-team e può sembrare eccessivo, ma anche per due team la guida contiene una serie di grandi concetti per ottimizzare l'integrazione. Puoi sempre scegliere alcune idee e sperimentare ciò che funziona per i tuoi team.