Problema di adattamento scrum per squadra

Dai a tutti le storie, lascia che chiunque scelga la storia su cui vogliono lavorare - tuttavia, limita il numero di storie in uno sprint a un numero che pensi possa essere fatto, e ha senso dal punto di vista della consegna .

L'intero aspetto dell'agile, inclusa la mischia, è che la squadra deve prendere le decisioni su cosa lavorare e come ottenerlo, non gli individui. Quindi dovresti considerare la squadra nel suo insieme e lasciare che decidano chi deve lavorare su cosa. Finché la consegna completa tutte le storie (non solo quelle divertenti), allora va tutto bene.

Tutti i membri del team dovrebbero vedere i progressi di tutte le storie su cui si stanno lavorando durante gli stand up, in modo che tutti possano lavorare come una squadra. Se hai una situazione in cui alcune persone hanno storie "buone" su cui lavorare, e altre ricevono test e documentazione, allora c'è qualcosa di sbagliato nel team stesso. Rompe le gerarchie, appiattisci la struttura in modo che tutti siano uguali e assicurati che tutti sappiano che sono tutti responsabili della consegna.

Tutti dovrebbero essere coinvolti nel processo di mischia allo stesso modo, se ci sono problemi nell'assegnare il lavoro allo sviluppatore giusto dovrebbero essere affrontati nella revisione sprint, ma suona più come se la tua squadra non agisse come una squadra e la gelosia e la personalità stanno intralciando la professionalità

Sebbene la struttura piatta di S sia ottima quando funziona, a volte nel team si richiede un individuo rispettato per prendere decisioni e delegare dove il team non può raggiungere un reciproco consenso.

Mi assicuro che i test iniziali e la documentazione siano eseguiti dallo sviluppatore responsabile della storia, quindi ognuno ha alcune delle cose noiose da fare, a condizione che venga eseguita anche la revisione tra pari.

Prova ad abbinare per alcuni dei lavori più interessanti o più difficili e assicurati che le coppie siano mescolate regolarmente, questo diffonde le abilità attraverso il team e dà a più persone l'accesso a storie migliori.

Penso che il problema sia che le storie sono "assegnate". La squadra dovrebbe decidere chi fa cosa e il team dovrebbe essere corresponsabile del successo.

Gli sviluppatori junior dovrebbero assumere mansioni più elevate? A volte, sì, altrimenti come cresceranno? Devono convincere gli sviluppatori più anziani a fargli provare e fornire una rete di sicurezza.

Sospetto che una volta che il team avrà il potere di distribuire il lavoro, cambierà atteggiamento e punto di vista. Al momento sembrano lamentarsi perché non si sentono personalmente responsabili.

La metodologia scrum afferma che tutti gli sviluppatori dovrebbero essere trattati come uguali quando in realtà non lo sono. Alcuni di loro sono più capaci di gestire compiti complessi rispetto ad altri e questo non è un atteggiamento personale ma una valutazione professionale. La chiave per un team di scrum di successo è offrire agli sviluppatori la libertà di scegliere le proprie storie, ma essere comunque in grado di delegare compiti specifici a determinati sviluppatori, se necessario. Ma questo processo deve essere trasparente e ovvio per tutti per evitare la gelosia e le incomprensioni.

È molto importante che il team sia d'accordo nel suo insieme su quale membro del team sta lavorando su cosa. Se non hai persone che si levano in piedi le une sulle altre e anche a un certo punto, ti imbatterai nel tipo di membro della squadra che deve coniare una frase, stronzi "Cherry pick" che sono più facili degli altri o semplicemente stanno provando a si fanno notare come "Sprint Hero".