Squadre multiple di scrum che passano al singolo backlog

Al momento abbiamo 5 team di scrum che lavorano sull'arretrato dei propri prodotti nell'ultimo anno. Ogni squadra lavora sul proprio sistema dedicato ma la tecnologia sottostante è la stessa .Net.

Ci sono state molte discussioni sul passaggio a team basati su feature che lavorano su un unico backlog. Il motivo è che uno dei nostri sistemi principali ha una notevole quantità di lavoro in arrivo e la loro capacità non è sufficiente per fornire tutto il lavoro dell'anno. L'altro motivo che ritengo sia quello significativo è che offre una maggiore flessibilità per adattarsi rapidamente ai cambiamenti nel portafoglio.

È stata presa la decisione di cambiare due team per lavorare su un unico backlog ma gli sviluppatori non hanno esperienza sugli altri sistemi. Una cosa che stiamo facendo è l'abilità incrociata spostando uno sviluppatore di sistemi di esperienza nel team.

La mia domanda è: hai sperimentato il passaggio al singolo backlog per due o più sistemi diversi. Quali sono state le tue sfide? Cosa dovevi fare per farlo funzionare?

Gestiamo circa una mezza dozzina di progetti utilizzando un unico backlog. Dico "a proposito" perché dipende da come si desidera differenziare i progetti.

Liberamente, abbiamo cinque o sei proprietari di prodotti, alcuni dei quali possiedono più di un prodotto. Abbiamo una squadra ragionevolmente piccola con sette sviluppatori e un caposquadra che codifica anche quando ha tempo. E abbiamo alcuni evangelizzatori che lavorano con il nostro processo popolare per spostare idee nella pipeline. Certo, molte persone indossano diversi cappelli che confondono le cose, ma lo ignorerò per la mia risposta. È interessante notare che non abbiamo un maestro di mischia formale.

Non abbiamo dovuto unire gli arretrati insieme, ma sembra un compito semplice da parte tua.

Mantenere le cose organizzate può essere una vera seccatura, quindi ecco alcuni punti che vorresti considerare.

• La governance è la chiave. Chiunque abbia un dito amministrativo nella torta deve comunicare con gli altri prima di apportare modifiche significative. E / o coloro che apportano modifiche devono essere a proprio agio con la loro autorità per farlo (ed essere pronti a prendere il calore per un brutto cambiamento). I nostri responsabili del cambiamento hanno un forte sostegno esecutivo e le linee sono piuttosto chiaramente tracciate intorno alle aree. Ma quando c'è un dubbio, chiediamo prima di cambiare.

• Possono esserci più spese generali legate alla preparazione, alla definizione delle priorità e ai kick-off degli arretrati. La priorità come rituale soffre di più perché è difficile riunire tutti i proprietari su base regolare. Utilizziamo una serie di go-betweens per negoziare la priorità e / o fornire la cattiva notizia di non effettuare la riduzione della priorità.

• Gran parte del nostro lavoro è guidato da un impegno esterno. Ciò toglie un po 'di autonomia alle nostre decisioni, ma questa è la realtà degli affari. Tuttavia, i tuoi sviluppatori devono essere consapevoli di questo cambiamento. Le piume possono incresparsi se si percepisce una perdita di controllo percepita. Tuttavia, cerchiamo di non impegnarci eccessivamente e abbiamo dovuto dire "no" ad alcuni proprietari di prodotti che erano seduti sulla cuspide di farcela.

• Generalmente utilizziamo due metodi per taggare a quale prodotto appartiene un articolo arretrato prodotto. Usiamo entrambi semplicemente perché semplifica la toelettatura e altre attività.

  1. Anticiperemo il titolo PBI con il nome del prodotto o la versione abbreviata.
  2. Abbiamo un campo separato che indica il prodotto complessivo e che deve anche essere compilato.

• Dobbiamo impegnarci consapevolmente nell'allenamento incrociato e assicurarci che tutti possano avere una mano nelle varie aree. Abbiamo una base di codice molto ampia rispetto al nostro team di sviluppo. Parte del codice che facciamo è anche molto specializzato. Il nostro team leader è fantastico in questo senso e spingerà il nostro livello di impegno verso il basso in modo che possiamo permetterci le inefficienze che derivano dal cross-training. Avere un forte vantaggio di squadra è fondamentale in questo senso.

• Facciamo del nostro meglio per mantenere i nostri tempi di sprint. Progetti complessi con nuovi membri del team si traducono in un sanguinamento non insolito con impegni. Il processo attorno alla tua ramificazione ti aiuterà davvero qui. Tutto il nostro lavoro viene svolto su un ramo che viene poi ricongiunto a una versione trunk. Abbiamo anche un server di build che gira di notte oltre ai trigger ad hoc. Gli sviluppatori che interrompono la build conoscono e risolvono il problema entro 24 ore. Periodo. La mancata risoluzione entro 24 ore significa che il commit viene annullato e gli sviluppatori senior danno loro dolore. E gli sviluppatori senior sono più difficili con se stessi quando si tratta di mantenere la build.

• Le analisi e le recensioni del codice diventano ancora più critiche. Aiuta a tenere tutti aggiornati su ciò che sta cambiando nelle varie aree.

• Allo stesso modo, lo standup giornaliero coinvolge tutti gli sviluppatori più le persone dell'interfaccia utente. Siamo al limite della comunicazione collaborativa benefica e dell'inefficienza di troppe persone. Ma manteniamo lo standup a meno di 15 minuti e passeremo rapidamente dalle discussioni secondarie. Di solito abbiamo finito tra 5 e 10 minuti.

• Non posso parlare degli effetti su metriche come velocità o impegno complessivo e tassi di burndown. Questi aspetti non sono stati abbastanza importanti per noi da seguire da vicino. YMMV, quindi prendilo in considerazione. Ciò presume anche che ogni squadra abbia una definizione ragionevolmente simile del punto della trama. In caso contrario, questo farà confondere le stime iniziali dopo l'unione. Genererà anche alcuni problemi per i confronti storici poiché non stai usando la stessa unità di misura di prima. Una semplice via d'uscita è semplicemente dichiararlo un "nuovo team" per le metriche e iniziare a raccogliere dati dopo l'unione.

• Abbiamo visto significativi benefici da questo approccio. Abbiamo avuto degli sprint in cui tutte le mani sono focalizzate su un'area e possiamo fare molti cambiamenti in un breve periodo di tempo. Non dovresti sottovalutare il valore che deriva dalla capacità di applicare rapidamente il doppio del normale numero di sviluppatori su un determinato progetto. Ma devi anticipare il cross training. Significa anche che non abbiamo mai sviluppatori con "niente da fare" a causa di cicli di test o toelettatura o altro. Abbiamo sempre un arretrato da affrontare.

• Tempo dedicato per progetti di ricerca e sviluppo. Altrimenti è troppo facile per loro scivolare attraverso le fessure e perdi l'opportunità di investire in quelle aree.

• Lavorare davvero sulla codifica senza ego e che mentre potresti avere esperti in un'area, non hai proprietari di un'area di codice. Prevenire l'opportunità di ego contuso è importante quando vengono introdotti stili diversi in un'area. Finché il nuovo codice soddisfa gli standard del team ed è funzionale, dovrebbe essere buono. Solo perché non è come l'esperto avrebbe fatto, non importa.

• Assicurarsi che i team coinvolti stiano utilizzando le stesse convenzioni e lo stesso stile di codifica. Niente come incoerenza qui per provocare il caos nei tuoi tentativi di integrazione.

• Continua a tenere le tue retrospettive e tienili in gruppo. È importante ottenere il feedback di tutti su ciò che funziona, ciò che non funziona e ciò che deve essere provato in modo diverso. Questo aiuta a creare un senso di cameratismo all'interno del team e dà un senso di appartenenza al processo di sviluppo.

La risposta Scrum corretta è "Chiedi ai team". Questo è il principio di auto-organizzazione in cui dovrebbero essere in grado di ristrutturarsi per svolgere rapidamente il lavoro. Vedi che molte persone nei team hanno più conoscenza del contesto di un estraneo e sanno cosa è meglio. Ciò include anche il Product Owner.

Suppongo che tu sia venuto qui e abbia posto la domanda in quanto c'è qualcosa che non sembra giusto e che hai preoccupazioni nascoste. Quindi ti darò alcuni suggerimenti per discutere con il team per prendere la decisione giusta.

Proprietario del prodotto

Esiste un solo proprietario del prodotto per un backlog e questo dovrebbe essere un uomo d'affari o una persona che rappresenta un'azienda. Non dovrebbe essere la gestione IT. Un grande arretrato ha molti elementi e con più team potrebbe essere troppo per un singolo PO da gestire. È possibile che si desideri mantenere gli arretrati separati per questo motivo.

Se ci sono più PO, allora hai sicuramente bisogno di più backlog poiché i team dovrebbero essere dedicati in uno sprint a un singolo PO e backlog. Il motivo è che un team non ha bisogno di gestire i conflitti tra le priorità dei proprietari di prodotti.

Sviluppo del prodotto rispetto alla manutenzione

I team di manutenzione lavorano su molti piccoli miglioramenti, bug su diversi prodotti e possibilmente con diversi proprietari di prodotti. Questi team BAU necessitano del supporto della gestione IT per pianificare e gestire i conflitti tra più proprietari di prodotti.

I team di progetto dovrebbero concentrarsi su un prodotto alla volta per ridurre al minimo il cambio di contesto e fornire un ottimo prodotto alla volta. Il cambio di contesto potrebbe comportare la consegna di molti prodotti mediocri con un certo grado di debito tecnico.

Cambio di contesto

Lavorare su più prodotti o funzionalità diverse provoca il cambio di contesto che rallenta la produttività dei team. L'OP dovrebbe tener conto di questo quando si lavora su ciò che è prossimo e su quale squadra dovrebbe lavorare su quale parte del lavoro. La quantità di commutazione non è insignificante e non è solo un problema teorico, è reale e ho visto il team scendere dell'80% della produttività a causa di questo.

Un buon PO proverà le funzioni di gruppo e il tipo di lavoro per aiutare i team a fare meno cambi di contesto, migliorando così le loro prestazioni.

Rischio

Purtroppo, il management cerca di mettere il rischio di tempo, denaro, budget e pressioni aziendali sulla squadra; e i team lo accettano accettando questo. Come professionista dello sviluppo, dovresti semplicemente dichiarare i fatti e gli impatti delle decisioni e far sì che l'azienda si faccia carico dei propri rischi.

Esempi

• Accettando un momento ridicolo. Piuttosto dì quali sforzi ci vorranno per fare correttamente il lavoro e far sì che le aziende gestiscano il problema del tempo

• Stime. Il business si aspetta che i team valutino accuratamente in un mondo di complessità e incertezza. I team dovrebbero chiedere alle aziende cosa stanno facendo per mitigare il superamento delle stime a causa di sfide impreviste, che sono altamente probabili. Le squadre non dovrebbero tener conto del grasso, ma dovrebbero fare affari.

• Debito tecnico. I team dovrebbero stimare l'esecuzione di un codice di alta qualità che è stato completamente testato e stimare ciò, ovvero smettere di scrivere difetti dovuti a pressioni. Se le aziende vogliono una qualità inferiore, allora è il loro rischio e quando le cose vanno male è un loro problema.

professionismo

Sii un professionista affermando di costruire le cose giuste per la qualità concordata. Stimare secondo le proprie capacità in base ai fatti a portata di mano. Quando questi fatti cambiano, comunicalo e adattare il preventivo. Come team di sviluppo, crea ottimi prodotti e non correre rischi per l'azienda. Comunicare e gestire le aspettative.

Ispeziona e adatta

I team dovrebbero sempre cercare modi per migliorare e se sentono che migliorerà le cose, dovrebbero provarlo. Quindi ispezionare per vedere se ci sono miglioramenti. Alla fine dovrebbero adattarsi e migliorare il loro nuovo approccio o eliminarlo se non funzionano. L'intento alla base di cercare di migliorare dovrebbe essere sempre lì.

Linea di fondo

In definitiva, la gestione del backlog è la scelta dell'OP. Il modo in cui vuole gestire la coda di lavoro dipende da loro. L'unica idea è che DEVONO mantenere la pipeline di lavoro per TUTTI i team sani e in buono stato. Spetta quindi all'OP decidere.

Il contratto

Nelle sessioni di pianificazione dello sprint, il team dovrebbe aspettarsi un elenco di articoli di backlog di prodotti elaborati che siano chiari, inequivocabili e ordinati. Con una breve discussione con l'OP il team dovrebbe sapere esattamente cosa vuole l'OP; il COSA . Il team si concentra quindi su come costruiranno.

Se l'OP arriva alla riunione di pianificazione ben preparata, a chi importa come viene gestito l'arretrato. Se l'OP viene impreparato alla riunione di pianificazione dello sprint, questo dovrebbe essere affrontato dall'SM e reso molto visibile in quanto questo è totalmente inaccettabile e non è un problema di squadra da affrontare.

Di recente abbiamo assorbito l'arretrato di un'altra squadra. Il team aveva un solo membro (non molto di una squadra, lo so), ma c'è un vero lavoro sul loro arretrato. Non abbiamo molta familiarità con il loro lavoro e non hanno molta familiarità con il nostro.

Anche se i tuoi arretrati sono uniti, ciò non significa che tutti debbano lavorare su tutto immediatamente. È irragionevole aspettarselo, quindi non preoccuparti troppo che tutti siano in grado di fare tutto in entrambi i backlog.

Invece, inizia facendo in modo che entrambi i team lavorino esattamente su ciò su cui stavano lavorando prima; l'unica differenza è che tutto è nello stesso backlog.

Quindi, ogni iterazione / sprint ha alcuni membri di ogni squadra che lavorano su storie dell'altro arretrato. Non avendo tutti a lavorare su oggetti sconosciuti allo stesso tempo, dividi il costo dell'apprendimento reciproco dei sistemi . Nel tempo la tua squadra assorbirà gradualmente le conoscenze reciproche.

Se fai tutto l'apprendimento in anticipo, ci saranno penalità di prestazione significative. Qualcuno nel senior management sicuramente noterà, e sarai costretto ad assorbire l'arretrato di un'altra squadra nella speranza che una nuova squadra possa compensare le scarse prestazioni ... :) A parte gli scherzi, questa sarebbe la mia raccomandazione.

Suppongo che il motivo per cui tu (o il tuo management) desideri creare un backlog unito per due team sia che vuoi essere in grado di selezionare solo gli elementi del backlog per uno dei sistemi e far lavorare entrambi i team su di essi.

In questo caso, aspettatevi un sacco di attriti dal team che è costretto a lavorare sul sistema con cui non hanno familiarità. Aspettatevi che il team prenderà ogni goccia (cioè piccoli oggetti arretrati relativi al loro sistema "home") per continuare a lavorare sul sistema su cui stavano lavorando in precedenza. Chi li incolpa? Non è divertente lavorare su qualcosa in cui non sei bravo. E il fatto che l'altra squadra sia brava come qualcosa in cui non sei bravo lo peggiora, perché ti fa sembrare ancora più stupido.

Quindi, l'unico modo per ottenere questo risultato è dividere le due squadre e formarle in due squadre miste. Solo allora c'è la possibilità che tutti gli sviluppatori possano accelerare rapidamente sul sistema (attualmente) "importante".

Non è molto buono per farlo in questo modo. La mia azienda precedente, è passata alla modalità a singolo team per singolo prodotto perché nelle grandi aziende avevamo persone diverse che lavoravano su cose diverse.

Passare da un progetto all'altro costa anche fatica, e se c'è una nuova persona che inizia a sviluppare spese generali è davvero grande. È necessario ottenere i diritti di accesso al sistema sviluppato, al repository diverso, ecc.

Preferisco la specializzazione, le persone sanno cosa stanno facendo, hanno tutte le informazioni necessarie, conoscono le insidie ​​del progetto e le persone non hanno la sensazione che devi lasciarle andare da un progetto all'altro per farli funzionare, per succhiare ogni centesimo di loro.

Anche se sono inattivi nel loro progetto, sono molto più produttivi in ​​ciò che hanno familiarità, che saltare da un progetto all'altro.