Scrum master peut-il allouer des tâches?

Nous suivons scrum dans notre projet. Je vois la plupart du temps que le Scrum Master nous attribue les tâches. Cependant, j'ai lu dans de nombreux livres de mêlée que la mêlée fonctionne dans l'autre sens (l'approche «pull») et que les membres de l'équipe choisissent des tâches ou des fonctionnalités. Scrum master assignant des tâches est-il la bonne approche ou va-t-il à l'encontre de l'idéologie agile?

Selon l'article de Wikipedia sur Scrum , les tâches Sprint ne sont pas assignées par le ScrumMaster:

Les tâches du backlog de sprint ne sont jamais attribuées; les tâches sont plutôt enregistrées par les membres de l'équipe selon les besoins, en fonction de la priorité définie et des compétences des membres de l'équipe. Cela favorise l'auto-organisation de l'équipe et l'adhésion des développeurs.

De plus, la définition d'un ScrumMaster est qu'il / elle est la personne responsable de s'assurer que les gens suivent les règles du processus Scrum.

ScrumMaster La personne responsable du processus Scrum, s'assurant qu'il est utilisé correctement et maximisant ses avantages.

Le ScrumMaster n'assigne pas de tâches, de manière simple et simple. L'équipe s'auto-organise et décide de qui travaille sur ce qui est décidé par l'équipe.

C'est vrai Scrum. De nombreuses organisations peuvent bien sûr utiliser des variantes de cela, cependant.

C'est ainsi que cela est censé fonctionner, mais comme pour tout ce qui fonctionne très bien en théorie ... cela ne fonctionne pas toujours.

Il y a des dépendances, des désirs des clients et des pilotes de l'extérieur. Certaines choses doivent juste être faites avant de pouvoir travailler sur ce widget sophistiqué sur lequel tout le monde veut travailler.

Il y a des capacités de développeur de base qui conduisent de l'intérieur. Certaines choses sont tout simplement difficiles et certaines personnes sont simplement meilleures. Bien sûr, lorsque je travaille dans une chronologie infinie, je peux simplement vous laisser le comprendre; mais quand quelque chose doit être fait, l'assignation à la personne la mieux placée pour le faire le plus rapidement et le mieux est celle qui obtient le travail.

Et puis il y a des problèmes de personnalité comme le contrôle excessif de Scrum Master et / ou des développeurs qui ne peuvent pas lier leurs propres chaussures sans qu'on le leur dise. Mon équipe, par exemple, a les deux. Fonctionne simplement mieux pour tout le monde d'ignorer ce petit fait sur Scrum dans de tels cas.

En d'autres termes, ne le faites pas simplement parce que le processus le dit. Faites ce qui fonctionne. Vissez le reste.

Bien sûr, il y a aussi l'autre fait fondamental de l'existence humaine ... peut-être que vous ne savez même pas qui est le Scrum Master. Ce n'est peut-être pas la personne avec ce titre. Peut-être que vous n'en avez même pas.

Jamais.

Scrum est totalement clair à ce sujet. L'équipe de développement, en tant que groupe, est chargée de compléter les éléments du backlog Sprint. Ils ont également un contrôle total sur la façon dont ils réalisent le développement et personne n'est autorisé à leur dire comment le faire.

En tant qu'entraîneur, le Scrum Master a un rôle à jouer quand il voit que l'équipe risque de manquer les objectifs de Sprint pour une raison quelconque. Mais ensuite, il doit leur demander de comprendre comment ils vont y faire face, puis s'écarter de leur chemin.

Une autre approche pourrait être de laisser l'équipe terminer le sprint, de la tenir responsable du manque de résultats et de le laisser ensuite être discuté dans la rétrospective du sprint.

Comme toute idéologie, il y a des moments où le règlement doit être jeté ou soigneusement ignoré.

Faites preuve de jugement quant à ce qui semble approprié. Faites juste attention à ce que quelqu'un devienne de facto un chef de projet - ou pire, intimide les gens pour qu'ils fassent certaines choses.

Il y a une grande différence entre l'allocation des tâches par dictée (vous DEVEZ faire X) et l'allocation par discussion et accord. Parfois, l'accord peut être tiède.

Là encore, peut-être que l'équipe a besoin de diriger ... c'est difficile à savoir.

Cependant, je serais préoccupé par tout processus qui insiste sur le fait que vous devez suivre le processus à la lettre sans marge de manœuvre ni jugement. Un tel processus se substitue à la réflexion.

À mon avis, le scummaster ne devrait pas faire cela, les membres de l'équipe devraient eux-mêmes reprendre les tâches. Si le scrummaster ne fait que l'administration comme c'est le cas dans notre équipe c'est pas de problème. Notre Scrum Master s'assure que la Scrum Board en papier reste synchronisée avec le fichier Excel. Le rôle de Scrum Master doit être un rôle facilitateur, nous nous assurons qu'il peut faire son travail sans entrave. C'est ainsi que nous travaillons. Savez-vous pourquoi votre scrummaster fait ça? Est-ce un chef de projet qui a peur de devenir obsolète? Craint-il que l'équipe ne reprenne pas les tâches elle-même? Ce pourrait être une bonne idée d'en discuter lors d'une rétrospective.

J'ai été un scrum master dans les deux types d'environnements (où j'ai poussé des tâches vers des individus et où des individus tirent des tâches).

O l'équipe Push, les ressources de développement n'étaient pas interchangeables. Le travail du client Windows devait aller au développeur Windows et le travail Web au développeur Web. J'ai donc pu pousser les tâches vers les ressources lors des sessions de planification. J'ai également pu planifier la capacité individuelle pour savoir quand arrêter de pousser.

La méthode pull a bien fonctionné dans une équipe où n'importe quelle tâche pouvait être récupérée par n'importe quelle ressource. Mais, je ne pouvais pas faire de planification de capacité individuelle pendant la session de planification, au lieu de cela, je devais dépendre de la vitesse moyenne pour savoir quand c'était assez. (Il a fallu environ 3-4 sprints avant d'avoir une bonne idée de la vitesse).

Je suis tombé sur un article intéressant décrivant les avantages / inconvénients de Push vs. Pull.