スクラムマスターはタスクを割り当てることができますか？
私たちはプロジェクトでスクラムに従っています。ほとんどの場合、スクラムマスターがタスクを割り当てます。しかし、私は多くのスクラムブックを読んで、スクラムは逆の方法（「プル」アプローチ）で機能し、チームメンバーはタスクや機能を取り上げます。スクラムマスターがタスクを割り当てるのは正しいアプローチですか、それともアジャイルイデオロギーに反しますか？
Wikipedia Article on Scrum によると、SprintタスクはScrumMasterによって割り当てられません：
スプリントバックログのタスクは割り当てられません。むしろ、タスクは、設定された優先順位とチームメンバーのスキルに応じて、必要に応じてチームメンバーによって登録されます。これにより、チームの自己組織化と開発者の賛同が促進されます。
さらに、スクラムマスターの定義は、彼/彼女が人々がスクラムプロセスのルールに従うことを確実にする責任がある人であるということです。
スクラムマスタースクラムプロセスの責任者であり、それが正しく使用されていることを確認し、その利点を最大化します。
スクラムマスターは単純で単純なタスクを割り当てません。チームは自己組織化しており、チームが決定したことに誰が取り組むかを決定します。
これは本当のスクラムです。もちろん、多くの組織はこれのバリエーションを使用する場合があります。
それはそれが機能するはずの方法ですが、理論的にはうまく機能するすべてのものと同様に...それは常に実際に機能するとは限りません。
依存関係、顧客の要望、そして外部からのドライバーがあります。誰もがやりたいと思うその豪華なウィジェットに取り掛かる前に、いくつかのことが完了しなければなりません。
内部から推進する基本的な開発者の能力があります。難しいこともあれば、優れた人もいます。確かに、無限のタイムラインで作業しているときは、それを理解させることができます。しかし、何かが成し遂げられなければならないとき、それを最も速く成し遂げるために最も良い場所に配置された人に割り当てることは、仕事をしているものです。
また、スクラムマスターの過剰な制御や、指示なしに自分の靴を結ぶことができない開発者などの人格の問題もあります。たとえば、私のチームには両方あります。そのような場合にスクラムに関するこの小さな事実を無視することは誰にとってもより良い働きをします。
言い換えれば、プロセスが言っているので、それをしないでください。うまくいきます。残りをねじ込みます。
もちろん、人間が存在するという他の基本的な事実もあります。スクラムマスターが実際に誰であるかさえ知らないかもしれません。多分それはその肩書きを持つ人ではない。多分あなたはそれを持っていません。
決して。
スクラムはこれについて完全に明確です。開発チームは、グループとして、スプリントバックログの項目を完成させる責任があります。彼らはまた、開発をどのように行うかについて完全に制御しており、誰にもそれを行う方法を教えることはできません。
コーチとして、スクラムマスターは、何らかの理由でチームがスプリントの目標を見逃している危険にさらされているのを見たときに、それを指摘する役割を果たします。しかし、彼は彼らにどのように対処するかを理解し、それから彼らの邪魔をしないように彼らに依頼する必要があります。
別のアプローチは、チームにスプリントを完成させ、結果の欠如について責任を負わせてから、スプリント回顧展で議論させることです。
他のイデオロギーと同様に、ルールブックを破棄するか、注意深く無視する必要がある場合があります。
適切と思われるものについては、ある程度の判断を下してください。誰かが事実上のプロジェクトマネージャーになることに注意してください。ひどい場合は、特定のことをするようにいじめられます。
ディクテーションによるタスクの割り当て（Xを実行する必要があります）とディスカッションおよび合意によるタスクの割り当てには大きな違いがあります。時々、合意はぬるいかもしれません。
繰り返しになりますが、おそらくチームは指示する必要があります...
しかし、私はあなたが小刻みに動くことや判断の余地のない手紙までそのプロセスに従う必要があると主張するすべてのプロセスについて心配します。このようなプロセスは、思考の代わりになります。
私の意見では、スカムマスターはそれをすべきではなく、チームメンバー自身がタスクを拾うべきです。私たちのチームの場合のように、スクラムマスターが管理のみを行っている場合は問題ありません。スクラムマスターは、紙のスクラムボードがExcelファイルと常に同期していることを確認します。スクラムマスターの役割は、作業を妨げられずに作業を行えるようにすることです。これが私たちの仕事のやり方です。あなたのスクラムマスターがこれをする理由を知っていますか？彼は時代遅れになることを恐れているプロジェクトマネージャーですか？チームが自分でタスクを取得しないのではないかと心配していますか？これを振り返って議論することは良い考えかもしれません。
私は両方のタイプの環境（タスクを個人にプッシュしたり、個人がタスクをプルしたりする環境）でスクラムマスターを務めてきました。
プッシュチームの場合、開発リソースに互換性はありませんでした。 Windowsクライアントの作業はWindows開発者に、Web作業はWeb開発者に依頼する必要がありました。したがって、計画セッション中にリソースにタスクをプッシュすることができました。また、プッシュを停止するタイミングを知るために、個別の容量計画を行うこともできました。
Pullメソッドは、どのリソースでもどのタスクでも取得できるチームでうまく機能しました。しかし、計画セッション中に個々のキャパシティプランニングを行うことはできませんでした。代わりに、平均速度に依存して、いつ十分かを十分に知る必要がありました。 （ベロシティについて良いアイデアが得られるまでに、3〜4回のスプリントが必要でした）。
私は 興味深い記事 プッシュとプルの賛否両論の概要を見つけました。