Alcuni membri del team aspettano solo che vengano discusse le storie sulle quali è più probabile lavorare e solo allora partecipano. Altrimenti giocano solo con il loro telefono e non ascoltano.
In qualche modo capisco questa posizione. Perché ascoltare una discussione su una funzione che probabilmente non contribuirà a sviluppare nello Sprint o mai?
Cosa pensi che dovremmo fare?
Interrompi la proprietà del codice. Rendi ugualmente probabile che chiunque in una squadra lavori su qualsiasi attività specifica.
Ci sarà quasi certamente un certo contraccolpo, perché gli sviluppatori si sentono a proprio agio con una specifica area di codice e con altre persone che non guardano oltre le loro spalle. Inoltre, il management vedrà un problema con il lavoro che impiega più tempo del normale, perché c'è sempre una curva di apprendimento.
Ma è davvero nell'interesse di tutti. Essere indispensabili è un'arma a doppio taglio. Inizia a diventare più difficile ottenere il tempo libero, la sera, nei fine settimana o per le vacanze. E la proprietà del codice fa male a un'azienda perché, quando qualcuno se ne va, costa più tempo di quanto tu abbia mai risparmiato su piccoli bit di trasferimento di conoscenze.
Inviti le persone giuste alle tue riunioni? Se hai diviso il sistema in aree di responsabilità per i sottotitoli, perché invitare tutti i sottotitoli ad ogni riunione?
Ad esempio, se hai un team di frontend e un team di back-end, mantieni le sessioni di pianificazione per il lavoro front-end ai membri del team di frontend. Forse invitare qualcuno della squadra di back-end come collegamento nel caso in cui un'attività superi i confini della squadra (ma se ciò accade frequentemente, potresti voler rivalutare la divisione delle responsabilità tra i tuoi team).
Idealmente tutti dovrebbero lavorare su tutto, ma in realtà spesso non è pratico a meno che il tuo sistema sia veramente piccolo e semplice, con il risultato che tutti conoscono ogni parte di esso in modo approfondito. In pratica, naturalmente, molti sistemi sono abbastanza grandi da aspettarsi che ogni membro della propria organizzazione abbia una conoscenza sufficiente di un compito pianificato per poter dare un input valido durante le sessioni di pianificazione (per non parlare di lavorare in modo altrettanto produttivo su ogni parte del sistema). semplicemente non realistico.
Il loro disinteresse è solo un sintomo. Il problema è che non stai distribuendo il lavoro in modo uniforme a tutti i membri del tuo team. Idealmente, ogni membro del team dovrebbe ritirare qualsiasi nuovo biglietto non limitato ad alcune aree del progetto.
Sembra un problema motivazionale - perché a qualcuno non interessa il progetto su cui stanno lavorando? Forse perché la squadra è divisa tra "organizzatori" e "mancati".
Quindi coinvolgi tutti, invece di 1 o 2 persone che prendono in carico le sessioni di pianificazione, coinvolgi tutti - fai assumere a diverse persone la responsabilità di ogni sessione, preferibilmente fai assumere incarichi diversi durante la sessione. Ruota tutto intorno. So che questo può sembrare difficile perché c'è sempre qualcuno che vuole discutere e organizzare tutti, ma qui sono il problema.
Ecco un'idea: quando pianifichi scegli una persona a caso per prendere in carico ogni storia. A caso. Registra chi è stato responsabile anche per la pianificazione, quindi il prossimo sprint potrai dire se hanno fatto un buon lavoro ottenendo un buon consenso tra stime e divisione dei compiti. Questo farà sì che prestino attenzione e daranno loro una ragione per impegnarsi nel progetto.
Ricorda, il problema non sono loro, ma tu e il modo in cui le sessioni di pianificazione sono state fatte. Quindi, quando qualcun altro prende in mano un piano narrativo, essi scelgono come procedere, dovrebbe esserci un modo ufficiale di procedere. (es. non sederti e continua a forzare la tua organizzazione su di loro per procura)
Qual è la durata dello sprint?
Le durate di sprint più lunghe portano a
Quindi, se la durata dello sprint è più di due settimane, prova a lavorare con sprint più brevi.
Se è difficile convincere gli stakeholder a impegnarsi in sprint più brevi, puoi saltare alcuni degli incontri formali, ad es. solo la revisione sprint dopo ogni 2 sprint, anziché dopo ogni sprint.