スクラムマスターはタスクを割り当てることができますか？

私たちはプロジェクトでスクラムをフォローしています。ほとんどの場合、スクラムマスターがタスクを割り当てます。しかし、私は多くのスクラムの本を読んで、スクラムが逆に機能し（「プル」アプローチ）、チームメンバーがタスクや機能を取り上げることを読みました。スクラムマスターはタスクに正しいアプローチを割り当てていますか、それともアジャイルイデオロギーに反していますか？

スクラムに関するウィキペディアの記事によると、スプリントタスクはスクラムマスターによって割り当てられていません。

スプリントバックログのタスクが割り当てられることはありません。むしろ、設定された優先度とチームメンバーのスキルに従って、必要に応じてチームメンバーがタスクにサインアップします。これにより、チームの自己組織化と開発者の賛同が促進されます。

さらに、スクラムマスターの定義は、彼/彼女が人々がスクラムプロセスのルールに従うようにする責任があるということです。

ScrumMasterスクラムプロセスの責任者。それが正しく使用されていることを確認し、その利点を最大限に活用します。

ScrumMasterは、単純で単純なタスクを割り当てません。チームは自己組織化されており、チームが決定した内容に誰が取り組むかを決定します。

これが真のスクラムです。ただし、多くの組織ではもちろんこれのバリエーションを使用する場合があります。

それが機能するはずの方法ですが、理論的にはうまく機能するすべてのものと同じように...実際に常に機能するとは限りません。

依存関係、顧客の要望、外部からのドライバーがあります。誰もがやりたいと思っている派手なウィジェットに取り掛かる前に、やらなければならないことがいくつかあります。

内部から駆動する基本的な開発者の能力があります。難しいこともあれば、良い人もいます。確かに、無限のタイムライン内で作業するとき、私はあなたにそれを理解させることができます。しかし、何かを成し遂げなければならないとき、それを最も速く成し遂げるために最高の配置された人に割り当てることは、仕事を得ている人です。

そして、スクラムマスターを過剰に制御したり、指示されずに自分の靴を結ぶことができない開発者など、性格の問題があります。たとえば、私のチームには両方があります。このような場合にスクラムに関するこの小さな事実を無視する方が、誰にとってもうまく機能します。

言い換えれば、プロセスが言うので、ただそれをしないでください。動作することを行います。残りをねじ込みます。

もちろん、人間の存在に関するその他の基本的な事実もあります。たぶん、スクラムマスターが実際に誰なのかさえ知らないかもしれません。たぶんそれはそのタイトルの人ではないでしょう。たぶんあなたも持っていません。

決して。

スクラムはこれについて完全に明確です。開発チームは、グループとして、スプリントバックログのアイテムを完了する責任があります。また、開発をどのように進めるかについても完全に制御しており、誰もそれを行う方法を伝えることはできません。

コーチとして、スクラムマスターは、チームが何らかの理由でスプリントの目標を逃す危険があると判断した場合、それを指摘する役割を果たします。しかし、その後、彼は彼らにそれをどのように扱うのかを理解し、それから逃げ出すように頼む必要があります。

別のアプローチとして、チームにスプリントを完了させ、結果の不足について責任を負わせてから、スプリントレトロスペクティブで議論させることができます。

すべてのイデオロギーのように、ルールブックを捨てるか、注意深く無視する必要がある場合があります。

適切と思われるものについては、ある程度の判断をしてください。誰かが事実上のプロジェクトマネージャーになるか、さらに悪いことに、特定のことをするように人々をいじめることに注意してください。

口述によるタスクの割り当て（Xを実行する必要があります）と、議論と合意によるタスクの割り当てには大きな違いがあります。時々、契約は温かいかもしれません。

繰り返しますが、チームは監督する必要があるかもしれません...それを知るのは難しいです。

しかし、私は、あなたが小刻みまたは判断の余地なしで手紙にプロセスに従わなければならないと主張するすべてのプロセスについて心配するでしょう。このようなプロセスは、思考の代わりになります。

私の意見では、スカムマスターはそうすべきではなく、チームメンバー自身がタスクを拾うべきです。私たちのチームのようにスクラムマスターが管理のみを行っている場合は問題ありません。スクラムマスターは、紙のスクラムボードがExcelファイルと同期していることを確認します。スクラムマスターの役割は、私たちが彼/彼女があなたがあなたの仕事を妨げられることなく行うことができるようにすることを促進するものでなければなりません。これが私たちの仕事のやり方です。スクラムマスターがこれを行う理由を知っていますか？彼は時代遅れになることを恐れているプロジェクトマネージャーですか？彼はチームが自分でタスクを拾わないのではないかと心配していますか？これについては、回顧会で議論することをお勧めします。

私は両方のタイプの環境（個人にタスクをプッシュし、個人がタスクをプルする場所）でスクラムマスターを務めてきました。

プッシュチームの場合、開発リソースは互換性がありませんでした。Windowsクライアントの作業はWindows開発者に、Web作業はWeb開発者に任せなければなりませんでした。そのため、計画セッション中にタスクをリソースにプッシュすることができました。プッシュを停止するタイミングを知るために、個々のキャパシティプランニングを行うこともできました。

pullメソッドは、リソースによってタスクをピックアップできるチームでうまく機能しました。しかし、計画セッション中に個々のキャパシティプランニングを行うことはできませんでした。代わりに、平均速度に依存して十分であるかどうかを知る必要がありました。（速度について良いアイデアを得るまでに、3〜4スプリントかかりました）。

プッシュ対プルの長所/短所を概説する興味深い記事に出会いました。