Il master scrum può assegnare le attività?

Secondo lo articolo di Wikipedia su Scrum , le attività di Sprint non sono assegnate dallo ScrumMaster:

Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. This promotes self-organization of the team, and developer buy-in.

Inoltre, la definizione di ScrumMaster è che lui / lei è la persona responsabile per assicurarsi che le persone seguano le regole del processo Scrum.

ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.

ScrumMaster non assegna compiti, in modo semplice e semplice. Il team è auto-organizzante e le decisioni su chi lavora su ciò che viene deciso dal team.

Questo è vero Scrum. Naturalmente molte organizzazioni potrebbero comunque utilizzare varianti di questo tipo.

Questo è il modo in cui dovrebbe funzionare, ma come in tutte le cose che funzionano alla grande in teoria ... non sempre funziona.

Dall'esterno ci sono dipendenze, desideri dei clienti e driver. Alcune cose devono essere fatte prima di poter lavorare su quel fantastico widget su cui tutti vogliono lavorare.

Ci sono abilità di base dello sviluppatore che guidano dall'interno. Alcune cose sono difficili e alcune persone sono semplicemente migliori. Certo, quando si lavora all'interno di una timeline infinita, posso semplicemente farvelo capire; ma quando qualcosa deve essere fatto, allora assegnare alla persona che si trova nella posizione migliore per farlo in modo più veloce e migliore è quello che sta ottenendo il lavoro.

E poi ci sono problemi di personalità come lo scrum master e / o gli sviluppatori che non riescono a legare le proprie scarpe senza che gli venga detto di farlo. Il mio team, ad esempio, ha entrambi. Semplicemente funziona meglio per tutti di ignorare questo piccolo fatto di Scrum in questi casi.

In altre parole, non farlo solo perché lo dice il processo. Fai ciò che funziona. Fanculo il resto.

Naturalmente, poi c'è anche l'altro fatto basilare dell'esistenza umana ... forse non sai nemmeno chi sia effettivamente lo Scrum Master. Forse non è la persona con quel titolo. Forse non ne hai nemmeno uno.

Mai.

Scrum è totalmente chiaro su questo. Il gruppo di sviluppo, come gruppo, è responsabile del completamento degli articoli nel backlog di Sprint. Hanno anche completamente il controllo su come fanno lo sviluppo e nessuno può dirgli come farlo.

Come allenatore, lo Scrum Master ha un ruolo nel segnalarlo quando vede la squadra rischiare di perdere gli obiettivi Sprint per qualsiasi motivo. Ma poi ha bisogno di chiedere loro di capire come hanno intenzione di affrontarlo, e poi togliersi di mezzo.

Un altro approccio potrebbe essere quello di consentire al team di completare lo Sprint, ritenerlo responsabile per la mancanza di risultati e quindi lasciarlo discusso nella Sprint Retrospective.

Come qualsiasi ideologia, ci sono momenti in cui il libro delle regole deve essere gettato via o accuratamente ignorato.

Usa un giudizio su ciò che sembra appropriato. Fai attenzione a qualcuno che diventa un project manager di fatto, o, peggio ancora, alle persone prepotenti di fare determinate cose.

C'è una grande differenza tra l'assegnazione delle attività in base a dettare (tu DEVI fare X) e l'allocazione per discussione e accordo. A volte l'accordo potrebbe essere tiepido.

Poi di nuovo, forse la squadra ha bisogno di dirigere ... è difficile da sapere.

Tuttavia, sarei preoccupato per qualsiasi processo che insiste sul fatto che è necessario seguire il processo fino alla lettera, senza spazio per oscillazioni o giudizi. Tale processo è un sostituto per il pensiero.

Secondo me, il mago non dovrebbe farlo, i membri del team dovrebbero occuparsi personalmente. Se il supervisore sta facendo solo l'amministrazione come nel nostro team, non si vede alcun problema. Il nostro scrum master fa in modo che la tavola di mischia della carta rimanga sincronizzata con il file excel. Il ruolo del maestro di mischia dovrebbe essere uno di facilitazione in cui siamo sicuri di poter fare il tuo lavoro senza impedimenti. Questo è il modo in cui lavoriamo. Sai perché il tuo supervisore lo fa? È un project manager che ha paura di diventare obsoleto? Ha paura che la squadra non riprenda i compiti da solo? Potrebbe essere una buona idea parlarne durante una retrospettiva.

Sono stato un vero scrum master in entrambi i tipi di ambienti (in cui ho spinto le attività a singoli individui e in cui gli individui eseguono attività).

O il team Push, le risorse di sviluppo non erano intercambiabili. Il lavoro del client Windows doveva andare allo sviluppatore di windows e il web lavorare allo sviluppatore web. Quindi sono stato in grado di trasferire le attività alle risorse durante le sessioni di pianificazione. Sono stato anche in grado di pianificare la capacità individuale per sapere quando smettere di spingere.

Il metodo pull ha funzionato bene in una squadra in cui qualsiasi attività può essere rilevata da qualsiasi risorsa. Ma, non potevo pianificare la capacità individuale durante la sessione di pianificazione, invece dovevo dipendere dalla velocità media per sapere quando era abbastanza sufficiente. (Ci sono voluti ~ 3-4 sprint prima che avessimo una buona idea di velocità).

Mi sono imbattuto in un articolo interessante delineando pro / contro di Push vs. Pull.