Scrum master può allocare compiti?

Stiamo seguendo la mischia nel nostro progetto. Vedo la maggior parte delle volte che lo Scrum Master assegna i compiti per noi. Tuttavia, ho letto da molti libri di mischia che la mischia funziona al contrario (l'approccio 'pull') e che i membri del team raccolgono compiti o funzionalità. Lo Scrum Master che assegna compiti è l'approccio corretto o va contro l'ideologia agile?

Secondo l' articolo di Wikipedia su Scrum , le attività di Sprint non sono assegnate da ScrumMaster:

Le attività sul backlog dello sprint non vengono mai assegnate; piuttosto, le attività vengono iscritte dai membri del team secondo necessità, in base alla priorità impostata e alle competenze dei membri del team. Questo promuove l'auto-organizzazione del team e il buy-in degli sviluppatori.

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

ScrumMaster La persona responsabile del processo Scrum, assicurandosi che sia utilizzato correttamente e massimizzandone i benefici.

ScrumMaster non assegna compiti, chiari e semplici. Il team si auto-organizza e decide chi lavora su ciò che viene deciso dal team.

Questo è vero Scrum. Molte organizzazioni possono ovviamente utilizzare varianti di questo, tuttavia.

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

Ci sono dipendenze, richieste dei clienti e driver dall'esterno. Alcune cose devono solo essere fatte prima di poter lavorare su quel widget di fantasia su cui tutti vogliono lavorare.

Ci sono abilità di sviluppo di base che guidano dall'interno. Alcune cose sono solo difficili e alcune persone sono solo meglio. Certo, quando lavoro all'interno di una sequenza temporale infinita, posso solo farti capire; ma quando qualcosa deve essere fatto, assegnarlo alla persona più indicata per farlo più velocemente e meglio è quello che sta ottenendo il lavoro.

E poi ci sono problemi di personalità come l'eccessivo controllo di Scrum Master e / o sviluppatori che non possono allacciarsi le scarpe senza che glielo venga detto. La mia squadra, per esempio, ha entrambi. In questi casi, funziona semplicemente meglio perché tutti ignorino questo piccolo fatto su Scrum.

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

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

Mai.

Scrum è totalmente chiaro su questo. Il team di sviluppo, come gruppo, è responsabile del completamento degli articoli nel backlog di Sprint. Inoltre, controllano completamente il modo in cui svolgono lo sviluppo e nessuno è autorizzato a dire loro come farlo.

Come allenatore, lo Scrum Master ha un ruolo nel metterlo in evidenza quando vede che il Team è in pericolo di perdere obiettivi Sprint per qualsiasi motivo. Ma poi ha bisogno di chiedere loro di capire come stanno andando a gestirlo, e quindi di togliersi di mezzo.

Un altro approccio potrebbe essere quello di consentire al team di completare lo Sprint, di ritenerli responsabili della mancanza di risultati e quindi di discuterne nella Sprint Retrospective.

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

Usa un po 'di giudizio su ciò che sembra appropriato. Fai solo attenzione a qualcuno che diventa un project manager di fatto, o peggio, fa bullismo alle persone per fare certe cose.

C'è una grande differenza tra l'allocazione delle attività per dettato (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 insista sul fatto che devi seguire il processo alla lettera senza spazio per oscillazioni o giudizi. Tale processo è un sostituto del pensiero.

Secondo me lo scummaster non dovrebbe farlo, i membri del team dovrebbero a loro volta raccogliere compiti. Se lo scrummaster sta facendo solo l'amministrazione, come nel caso del nostro team, non vedo alcun problema. Il nostro Scrum Master si assicura che la Scrum Board di carta rimanga sincronizzata con il file Excel. Il ruolo di Scrum Master dovrebbe essere facilitante, ci assicuriamo che tu possa svolgere il tuo lavoro senza ostacoli. Questo è il modo in cui lavoriamo. Sai perché lo scrummaster lo fa? È un project manager che ha paura di diventare obsoleto? Teme che la squadra non prenderà i compiti da sola? Potrebbe essere una buona idea discuterne durante una retrospettiva.

Sono stato uno scrum master in entrambi i tipi di ambienti (in cui ho inviato compiti agli individui e in cui gli individui svolgono compiti).

O il team Push, le risorse di sviluppo non erano intercambiabili. Il lavoro del client Windows doveva andare allo sviluppatore di Windows e il lavoro web allo sviluppatore web. Così 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à poteva essere raccolta da qualsiasi risorsa. Ma non ho potuto pianificare la capacità individuale durante la sessione di pianificazione, invece ho dovuto dipendere dalla velocità media per sapere quando era abbastanza. (Ci sono voluti ~ 3-4 sprint prima di avere una buona idea sulla velocità).

Mi sono imbattuto in un articolo interessante che delineava i pro / contro di Push vs. Pull.