Alcuni membri del team non partecipano attivamente alla pianificazione di Sprint

15

Alcuni membri del team aspettano solo che vengano discusse le storie su cui hanno maggiori probabilità di 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 caratteristica che difficilmente ti aiuterà a sviluppare nello Sprint o mai?

Cosa pensi che dovremmo fare?

agile scrum

— Eugene
fonte

9

Quanto è grande questa squadra?

— JeffO,

8

@JeffO ha colpito l'unghia sulla testa - questo è un problema classico di una squadra di grandi dimensioni. Squadra sovradimensionata = autorità / responsabilità individuali sottodimensionate = impegno individuale sottodimensionato. Una squadra della giusta dimensione significherà che tutto ciò di cui parlate riguarda gli effetti di tutti nella stanza. In alternativa, stai assumendo troppe responsabilità: perché ascoltare una discusione su una funzione che difficilmente ti aiuterà? Un team di dimensioni adeguate che non si occupa delle responsabilità dovrebbe avere tutti quelli che dovrebbero lavorare su ogni caratteristica.

— Jimmy Hoffa,

7

Telefoni spenti, senza eccezioni. Incontro semplice senso comune.

— user1019696,

5

@ user1019696 per essere onesti, ho potuto ricevere una telefonata da mia moglie che mio figlio si è rotto una gamba in qualsiasi momento. C'è una grande differenza tra "telefoni spenti" e "non stare **** con il telefono nel mezzo di una riunione, perché è semplicemente irrispettoso".

— Jimmy Hoffa,

4

@jwenting parli di un'era in cui c'erano segretari di società, non c'era una persona simile in un'azienda in cui ho lavorato per anni - non avrebbero avuto niente da fare. E no, non può aspettare. Soprattutto non per lavoro, scusate ma lavoro di famiglia. Detto questo, forse ricevo una chiamata nel mezzo di 1 su 30 o 40 riunioni (forse ??) di cui probabilmente rispondo 1 su 30 o 40 ... Non è difficile non essere un coglione con il telefono. Se le persone hanno bisogno di essere disabilitate o rimosse dalle loro persone per evitare di essere un coglione, forse quella persona è solo un coglione.

— Jimmy Hoffa,

32

Ferma la proprietà del codice. Rendi ugualmente probabile che chiunque in una squadra lavori su una determinata attività.

Ci sarà quasi sicuramente un contraccolpo su questo, perché gli sviluppatori si sentono a proprio agio con una specifica area di codice e con altre persone che non si guardano alle spalle. Inoltre, il management vedrà un problema con il lavoro che impiega più tempo di quanto potrebbe normalmente, perché c'è sempre una curva di apprendimento.

Ma è davvero nel miglior 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 è un male per un'azienda perché, quando qualcuno lascia, costa più tempo di quanto tu abbia mai risparmiato su piccoli frammenti di trasferimento delle conoscenze.

— pdr
fonte

4

+1 Assolutamente. C'è una falsa impressione di efficienza quando pensi che i programmatori siano solo un'altra parte della catena di montaggio e poi ti chiedi perché un progetto viene arretrato perché uno dei denti deve essere sostituito.

— JeffO,

3

@JeffO, che è praticamente lo standard nella gestione della società di sviluppo software nella mia esperienza, considerando gli sviluppatori come parti identiche in una macchina che può essere sostituita all'istante con un'altra unità di carbonio ...

— jwenting

3

@jwenting che li rende perfettamente adatti anche per essere esternalizzati. Non vedo perché gli sviluppatori aiutino in questo atteggiamento.

— GrandmasterB,

1

@jwenting Questo è il punto di agilità. Per cambiare questo tipo di visione delle cose.

— Euforico,

1

@Euforico nella mia esperienza, il risultato finale è il contrario, i manager vedono le persone ancora di più come risorse che possono essere semplicemente scambiate al volo, come requisiti ...

— jwenting

15

Inviti le persone giuste ai tuoi incontri? Se hai suddiviso il sistema in aree di responsabilità per i sotto-gruppi, perché invitare tutti i sotto-gruppi a ogni riunione?
Ad esempio, se si dispone di un team frontend e di un team backend, mantenere le sessioni di pianificazione per il lavoro frontend ai membri del team frontend. Magari invita qualcuno della squadra di backend 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 le tue squadre).
Idealmente tutti dovrebbero lavorare su tutto, ma in realtà questo spesso non è pratico a meno che il tuo sistema non sia davvero piccolo e semplice, risultando in chiunque lo conosca a fondo. In pratica, naturalmente, molti sistemi sono abbastanza grandi da aspettarsi che ogni membro dell'organizzazione abbia una conoscenza sufficiente di un'attività pianificata per essere in grado di fornire input validi durante le sessioni di pianificazione (figuriamoci essere ugualmente produttivo lavorando su ogni parte del sistema) è semplicemente non realistico.

— jwenting
fonte

12

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 a determinate aree del progetto.

— Tom Squires
fonte

3

È bello in teoria. In pratica, specialmente su grandi progetti, il sistema può essere abbastanza grande da rendere poco pratico per ogni membro del team avere una conoscenza sufficiente di ogni sua parte per essere produttivo quando ci lavora.

— jwenting,

@jwenting - sembra proprio che questa squadra sia molto sicura di non dover mai lavorare su altre parti. Sebbene una persona non possa sapere tutto, ciò non significa che dovrebbe imparare il meno possibile.

— JeffO,

@JeffO vero, ma non ci si può aspettare che possano partecipare attivamente alla pianificazione di cose per aree di cui non sono a conoscenza. Ascolta e impara, ma tieni la bocca chiusa. E magari usa il tuo cellulare per fare alcune foto del consiglio di pianificazione :)

— jwenting del

1

@jwenting in pratica su grandi progetti è necessario distribuire di più il lavoro! Non è che tutti abbiano le stesse conoscenze, ma hanno ugualmente probabilità di lavorare su qualsiasi area particolare. Consentire scuse rende i membri del team più propensi a non adottare nuove aree.

— Dave Hillier,

5

Sembra un problema motivazionale - perché alcune persone non si preoccupano del progetto a cui stanno lavorando? Forse è perché la squadra è divisa in "organizzatori" e "outs".

Quindi coinvolgi tutti, invece di 1 o 2 persone che si occupano delle sessioni di pianificazione, coinvolgi tutti: fai in modo che persone diverse prendano il controllo di ogni sessione, preferibilmente fai assumere a persone diverse durante la sessione. Ruota tutto intorno. So che questo può sembrare difficile perché c'è sempre qualcuno che vuole agitarsi e organizzare tutti, ma qui sono il problema.

Ecco un'idea: quando pianifichi, scegli una persona a caso per occuparti di ogni storia. A caso. Registra anche chi era responsabile della pianificazione, quindi al prossimo sprint puoi dire se hanno fatto un buon lavoro per ottenere un buon consenso su stime e suddivisione dei compiti. Ciò li farà prestare attenzione e darà loro anche un motivo per impegnarsi nel progetto.

Ricorda, il problema non sono loro, sei tu e il modo in cui vengono svolte le sessioni di pianificazione. Quindi, quando qualcun altro prende in carico un piano della storia, possono scegliere come procedere, dovrebbe esserci un modo ufficiale di procedere. (ad esempio, non sederti e continua a forzare la tua organizzazione su di loro per procura)

— gbjbaanb
fonte

Buone idee. Spero che le persone non vedano questo come una perdita di tempo.

— Eugene,

1

Qual è la durata dello sprint?

Durate di sprint più lunghe portano a

Più lavoro da pianificare nello sprint, che porta a
Incontri di pianificazione più lunghi, che portano a
Maggiore difficoltà per i membri del team a rimanere concentrati, ...
I membri del team si annoiano

Quindi, se la durata dello sprint è superiore a due settimane, prova a lavorare in sprint più brevi.

Se è difficile indurre le parti interessate a impegnarsi per sprint più brevi, è possibile saltare alcune delle riunioni formali, ad esempio avere la revisione dello sprint solo ogni 2 sprint, anziché dopo ogni sprint.

— Pete
fonte