チームメンバーにより多くの意思決定力を与えることは非常に長い議論につながり、最終的な発言権を持つ人がいないため、進行を妨げました
現在、私たちはスクラムを使用しています。ただし、私たちのスクラムマスターは、スクラムプロセスのファシリテーターではなく、プロジェクトマネージャーとして行動することがあります。チームメンバーが自分でタスクをプルする時間の約半分ですが、スクラムマスターがタスクをチームメンバーに割り当てる時間の半分です。
自己組織化チームを全面的に採用してほしい。しかし、チームメンバーにもっと意思決定力を与えようとすると、チームメンバー間の議論が非常に長くなり、最終決定権を持つ人がいないため、これらの議論は進歩を妨げることになります。
自己組織化スクラムチームとの議論を最小限に抑える方法があると思いますか？
最終決定権を持つ人は誰もいないので、これらの議論は進歩を妨げるでしょう。
そこにあなたの問題があります。誰かが最終的な意思決定権限を持っている必要があります。それを実現する方法を考え出してください。
また、少し非公式の議会手続きを採用することを検討することもできます。会議をハイジャックする人々は新しい問題ではなく、すでに既知の解決策があります。
ディスカッションのタイムボックス化を開始します。最後に、投票してください。ネクタイ？公平な投票を提供できる他の誰かを連れてきてください。ただし、規模の決定に「ニワトリ」を関与させることは実際には推奨されていません。
その中心にあるのは、チーム内に何らかの毒性があるようです。どうして？それは最初に良い質問かもしれません。それをあなたのスクラムマスターに持ってきてください。たぶん誰かが理想と現実を混同しているのでしょう。
また、PM/PO（理想的）またはSMの最終決定権を与えることもできます。他の人が提示した意見や事実を比較検討するのは彼らの責任です。
自己組織化スクラムチームとの議論を最小限に抑える方法があると思いますか？
それはスクラムマスターの仕事の一部です。チームに効率的かつタイムリーに意思決定をしてもらいます。
率直なアプローチは、誰か（スクラムマスターまたはその他）に最終決定権を持たせることです。しかし、それは（私見）権力の乱用です。より良いアプローチは、例えばチームが決定を下すのを助けることです：
- 決定が必要なとき（今、30分、明日、1か月）にチームに同意してもらいます。これは合理的である必要があり、人為的な締め切りを強制しないでください（アジャイル：可能な限り合理的な瞬間に決定を下します）。
- 問題の重要性と、それについて議論するのにどれだけの時間を費やす価値があるかについて、チームに同意してもらいます。私はそれを自転車小屋の限界と呼んでいます。これは厳密な制限ではありませんが、最終的には重要ではないことについて議論するために1日を費やすことは、自分たちの時間を最大限に活用することではないことを理解してもらいます。 （それの楽しみのための議論は別の話です、それを殺さないでください！）
- 締め切りまでに答えに取り組むように彼らに言いなさい、さもなければあなたは決定を下すつもりです（あなたの決定がどうなるかを彼らに言わないでください）
- 実際にそれを行います。そして、その契約に固執します。
それがスクラムマスター対チームプレーであることを理解してください。自分が満足しているよりも多くの決定を下すことになるかもしれませんが、その重みに値するチームは、少なくともいくつかの決定を所有し、強制される前にそれに取り組むことを理解するでしょう。 。
多くの人にとって、タスクの割り当てをプログラマーが制御できるようにすることは特権であるため、ビジネス上の制限の下で操作することを確認する必要があります。あなたの場合、それは決定する時間の長さです。
うまくいけば、誰もがより多くの練習でこれで良くなるでしょう。あなたは時間制限を設定することができ、それからPMはただちに裁定を下します。
また、あなたの会社は、プログラマがPMよりも多くの時間をかけてタスクを割り当てることができるようにするほうが、タスクがより正確でチームの士気が向上し、おそらく全員に責任を持たせることができるため、より適切であるかどうかを判断する必要があります。
いくつかの測定により、実際に誰がより良い割り当て、推定などを行うかを決定できます。
編集：チームメンバーがこの時間を使用して、技術的/哲学的な議論を開始したり、場合によっては議論に参加したりしないようにします。他の会議を公式または非公式に手配して、システムからこれを取り除くのを助けます。
まず、SMが最終決定を下すべきであるという他の回答で述べられている意見に強く反対します。スクラムマスターのタスクは
多くの場合、障害をチームに提示することで、障害を回避します。そうしないと、障害を無視する可能性があります。
チームが良い（スクラム）チームになるのを助けるために。
彼らの手から決定を下すことは、まったく間違ったことです。
代わりに、次の方法で問題にアプローチします。
観察：実際の問題は何ですか？可能性は
チーム内での対立、絶え間ない反対に現れる
したがって、十分な情報がないため、決定の適切な根拠がない
思考が間違っているか、少なくとも最適ではないと判断する責任を負うことへの恐怖
現在：チームに問題を認識させます。動作の結果を明らかにします。 POは、この決定不能がもたらす損害を提示したいと思うかもしれません。また、POはチームへの信頼を示し、チームはその信頼に値する行動を取る必要があることも明確にする必要があります。
チームに問題を解決させます。モデレートされたディスカッション（通常は回顧展）で、チームは解決策の提案を考え出し、それを決定する必要があります。
実際の解決策は次のとおりです。
たとえば、経験豊富な開発者に10分の1の票を与えるなど、関係を断ち切る方法を備えた民主的な投票。
特定の種類の決定を下すチームメンバーを決定する（おそらく他の人の議論を聞いた後）
タイムボックスの決定
明確なフェーズを持つことにより、適切に決定を準備します。情報の収集、議論、決定
同意による決定、つまり、誰もが解決策を探すわけではありません（または大多数が同意しますが、誰もが一緒に暮らせる解決策を探します）
各チームの誰かがいくつかの調停スキルを学ぶ必要があります。スクラムマスターは論理的な選択ですが、彼である必要はありません。あなたはあなたの会社にクラスを教えるために人々を雇うことができます。グループを効果的にコンセンサスに導くために、誰かが決定権を持っている必要はありません。ちなみに、誰かが効果的に決定を下す権限を持っている場合でも、チームがその権限を控えめに使用すると、チームはよりスムーズに機能し、代わりに調停スキルを使用してできるだけ頻繁に合意に達します。
このトピックはここの投稿には大きすぎます。また、ある程度の自然な才能と多くの練習が含まれますが、基本的なヒントがいくつかあります。
- 他の回答が述べているように、あなたの決定をタイムボックス化することに事前に同意してください。
- 理解する方法あなたは決定を下そうとする前に決定を下します。最終発言者を決定するための可能な方法は次のとおりです。
- 過半数の投票。
- 交代で。
- 失うものが最も多い人。
- 最近コードに触れた人。
- そのコードに最も頻繁に触れる人。
- その特定の問題の研究に最も時間を費やした人。
- 顧客の要求を最もよく理解している人。
- マネージャーまたはテクニカルリード。
- 妥協案を提案します。
- 競合するアイデアを提案し、それぞれが最終製品を作成する前にレビューのために概念実証を提出します。
- 多くの場合、情報が不足しているため、決定には異論があります。不足している情報を正確に把握し、決定を下す前にそれを見つける方法を提案します。
- 少人数のグループで、または双方で個別に会って、懸念を打ち出し、大規模なグループでそれを試みる前に問題の核心にたどり着きます。
- 取るに足らない詳細について、バイクシェディングからチームを遠ざける。大規模な決定のみに焦点を当てることを提案し、実装を行う個人に詳細を任せます。
- 同意する領域を指摘し、それだけに基づいて続行できるかどうかを確認します。
- 大規模な新しいプロジェクトを実施するときに、すべてのシステムから苦情を取り除くために、たまたま口論が必要な場合があることを理解してください。全員の懸念が聞かれ、検証されていることを確認し、ボランティアに不確実性を調査するよう依頼してから、2回目の会議を開きます。ほとんどの場合、2回目の会議に来る人は少なく、物事を成し遂げたいという気分になります。
これは非常に大きな質問であり、単なるスクラムよりもはるかに大きいものです。それはチームプレーの核心に達します。個人にもっとコントロールを与えるという考えは、赤テープを取り除くことによって彼らをより効率的にすることです。ただし、トレードオフがあります。赤いテープが邪魔になると、誰もが同じ目標に向かって非効率的に行進しています。官僚的形式主義を取り除けば、誰もが効率的に行進しますが、自分の目標に向かって進みます。すべての個人にプロジェクト全体の目標の良い意味を教え込んだ場合、これはうまく機能します。個人が最終的な方向性に同意しない場合、ビッカースが始まります。
明白な「チームの目標をもう少し統一する」以外に、2つのテクニックをお勧めします。1つは、官僚的形式主義をゆっくりと取り除くことです。チームに変更に対応する時間を与え、チームが自分自身を再調整できるかどうかを確認します。開発ルールの突然の変更は、段階的な変更よりも慣れるのがはるかに困難です。 2つ目は、問題をより高い視点から攻撃することです。 「ちらつきが見られる場合は、全員が落ち着くまでお役所仕事が戻ってきます」などの問題をメタコントロールできるかどうかを確認してください。
私が持っている最後のアドバイスは、頭を直接突き合わせている2人のチームメンバーに決して近づかないことです。定義上、彼らはバッティングヘッドモードにあり、あなたが物事を修正しようとするときに彼らはあなたとバッティングヘッドを気にしません。手動で反対を押しつぶして決定を下すのではなく、常に反対の立場からそれらを移動するように努めてください。
私も実際にスクラムを使って仕事をしています。
私たちはタスクを自己組織化し、必要に応じてスクラムマスターが最終決定権を持ちます。そんなに簡単です！
いくつかの指示に従うようにしてください：
- タスクを割り当てるときにチームが同意する必要があります
- 彼らが同意できない場合は、無限の議論で時間を無駄にしないでください（決して議論しないでください！）。スクラムマスターに持っていってください。
- スクラムマスターの決定を信頼してください。全員が同じ船に乗っています。
これらのヒントがお役に立てば幸いです。