スクラムチームの支配的なチームメンバー


22

チームメンバーが最初に彼にではなく、スクラムマスターに割り当てられている責任をとろうとする状況で、あなたは何をしますか?


5
これをpm.stackexchange.comに移動する必要がありますか?
アブデルラオフ

1
これが実際にスクラムと関係しているか、それともプログラミングに関係しているかはわかりません。「支配的なチームメンバーはチームの全員を覆い隠します」。
-ozz

5
スクラムマスターはPMでなく、スクラムプロジェクトにはPMがないはずなので、pm.stackexchange.comに移動することに同意しません。
ラディスラフMrnka

3
心配しているのはあなただけであるようです。彼に決闘を挑みます。
-JeffO

2
この質問の重要な背景を見逃しています。「支配的な」開発者は、スクラムマスターのパフォーマンスが低下し、チームのパフォーマンスを向上させようとしているため、エゴと優れたスキルを養おうとしている可能性があるため、より多くの責任を負っている可能性がありますチームへの潜在的な破壊的影響に気付いていない、多分彼はただのジャーク...または多分スクラムマスター自身が問題です。
MAR

回答:


17

スクラムチームは自己組織化されているため、もう少し支配的な人のためのスペースがあります。他の人は、彼らが取り組んでいるタスクについて彼のアイデアを彼に尋ねる必要がありますが、彼の支配は管理下に置かれなければなりません。

できること:

  • 独立しているが協力的であるように他人を動機付けます-これは、定期的に評価される期待値を設定するマネージャーや人事担当者と協力する場合に最もよく達成できます。
  • スタンドアップ、計画、および回顧中。他のチームメンバーが最初に発言できるようにします。レビュー中に、他のチームメンバーに、実装したユーザーストーリーを提示させます。
  • 他の人が最初にタスクを選択できるようにして、支配的な開発者がやりたいタスクだけを選択できないようにします。
  • 主要なチームメンバーが他の開発者と協力できるように、一部のタスクにペアプログラミングを含めます。
  • 民主的であること-チームメンバーの意見だけではプロセスを変更することはできません-スクラムは、チームが明確にコミュニケーションをとる場合のみ機能します。
  • これが役に立たない場合は、支配的なチームメンバーと話し、状況を説明する必要がありますが、スクラムにはチームリーダーがいないことに注意してください。経営陣からのサポートがある場合は、彼の仕事の安定性を脅かすこともありますが、これは最後の選択肢です。

支配的なチームメンバーが支配力を失いたくない場合、および受動的なチームメンバーがより積極的になりたくない場合は、マネージャーおよびHRからのサポートが必要になります。スクラムプロセスが管理者によって推奨されていない場合、これは問題になる可能性があります。


14

おそらく、この質問の理由は、この支配的な人のために、チームが何らかの形でパフォーマンスを下回っていると感じるためです。おそらく、チームの他のメンバーが100%貢献していないのは、その理由は何でしょうか?

マネージャーとして、あなたがそうであるなら、それはあなたのすべての従業員が彼らの役割が何であるかを確実に理解することをあなたの責任です。具体的には、それらに何が期待され、どのように評価されるかです。スクラムチームのチームメンバーとして、各人はチームの成功に対して個人的に責任を負います。したがって、この支配的なチームメンバーは、その責任において失敗していることを知る必要があり、それに応じて評価されます。

フィードバックは重要なポイントです。チーム会議があり、この人が議論を支配し、チームの残りの部分に設計とアプローチを強制し、残りの部分を受動的な役割に押し込んだ場合、彼は要件を満たしていないことを率直かつ個人的に伝える必要があります役割の。彼が自分の個人的な成果だけをこっそりと強調しているのを見つけたら、彼にそれを呼びかける必要があります。そして、個人的な成果は、チームがグループの成果を上げるのを助けるよりもはるかに価値があることを理解させる必要があります。

これらはすべて困難ですが、それがマネージャーとスクラムマスターの目的です。

これについては、他にも方法が1つあります。チームの問題にします。それらを一緒に呼び出して、彼らが達成していないことを伝えてください。その理由は次のとおりです。解決策を考え出すように依頼します。びっくりするかもしれません。


1
単に優れた答え。
ラディスラフMrnka

フィードバックに集中するのが好きです。
クリンジ

7

アルファ開発者に意見を聞いてみませんか。彼が持っている効果について全く知らないことは完全に可能です。彼を脇に連れて行って、あなたが思うことを伝えてください。「あなたは私たちの主任開発者ですが、これらの人々をあなたのレベルに引き上げる必要があります。どうすればできるかを解決するのにあなたの助けが必要ですか?」という議論をすることさえできます。彼の優位性を資産に変えてください。彼がそれを行う方法を見ることができるかどうかを確認してください。

彼がチームをどれだけうまくサポートしているかを測定し、彼らを自分のレベルに引き上げれば、彼はそれをやるだけのモチベーションを持ちます。

あなたは彼が実際にチームの利益のために働いていないことを意味します(私の推測)、すなわち彼は何らかの形で悪であり、はい、彼を削除します。しかし、賢者はかつて私に言った:無能または単純な無知がより可能性が高い場合、悪意を仮定しないでください。


それは問題を再構成する素晴らしい方法です。彼の助けを求めると、状況は完全に変わります(そして、それが全体的に恐ろしさを減らします)。
ジョーホワイト

5

彼はスクラムマスターになろうとしているようです。

あなたの立場を明確にし、それに応じて行動してください。

スクラムマスターの役割は、チームスピリットを有効にすることです。この唯一無二の人物をチームプレーヤーにできない場合は、チームから彼を削除します。

クイックノート:支配的な開発者は、受動的な開発者よりも問題はありません。


3
いい言い方ですが、チームから誰かを単純に削除することは、私がピエールと思っていたほとんどの場合で行うよりも簡単です。
オズ

@james:理由を教えてください。

まあ、人のためにプロジェクトに取り組む人が限られている。彼を別のチームに移動すると、他のチームは不便で抵抗するかもしれません。プロジェクトでの知識保持は別のものになります(知識を広めるべきだと言うのは簡単ですが、実際にはそうではありません)。それが、言うよりも言うのが簡単だという3つの非常に本当の理由です。もちろんそれができないわけではありません。もちろん、彼を解雇するつもりかもしれません:-)
オズ

1
私は英国に拠点を置いており、支配的な性格を持つことは誰かを解雇する理由ではありません。それ以上のものが必要です!
オズ

1
@Pierre-米国で言うよりも英国で人々を解雇するのはずっと難しい。しかし、悪い行動と警告のパターンを示すと、もちろん誰かが解雇されます。この特定の状況が英国から誰かを解雇するのは簡単かどうかはわかりません。私は間違っているかもしれません。
オズ

2

現在、スプリント計画はチーム全体で交代する役割です

スプリントの計画には、チーム全員が参加する必要があり、一度に1人に渡さないでください。これに正当な理由がない限り、これは深刻な問題だと思います。

あなたが言っていることが真実で客観的であるなら、あなたはあなたの手に大きな問題を抱えています:参加していない人々と真にアジャイルなプロセスを妨げる「ドミネーター」。スラムマスターとして、行動を取るのはあなた次第です。たぶん、あなたはこの状況について自信を持ってあなたのプロジェクトマネージャーを連れて行きたいと思うでしょう。


2

多くのチームはアジャイルの中核から外れており、それらを取り戻すのはあなたの仕事です。アジャイルの価値を教え、チームに再組み込む必要があります。実際、あなたは常にアジャイルな価値を教えるべきです。アジャイルのビジョンを持ち、それを明確かつ強力にします。「アジャイルをうまくやる」ことへのコミットメントを示します。

これを行うには、アジャイルマニフェストとスクラムの値を説明します。コラボレーションが彼らにとって何を意味するのか、なぜそれが重要なのかを尋ねます。アジャイルにおける信頼の役割について質問してください。これは、スクラムにチームリーダーの役割とプロジェクトマネージャーの役​​割がない理由と、個人ではなく素晴らしいソフトウェアを作成することはチーム全体の責任であるということを話す絶好の機会です。

これに関する回顧セッション全体を計画します。いくつかの価値にコミットし、次の回顧展の間にフォローアップするように彼らに依頼してください。指を向けないで、ニュートラルな方法を使用してください。

他のメンバーに安全に意見を述べることを強制する方法を導入します。何か簡単な拳-の-5は聞いたチームのサイレント声を取得するための素晴らしいです。チームが支配的な男に同意しないことは痛々しいほど明白になります。プランニングポーカーはうまく機能しますが、重要なのは、カードが表示されるにディスカッションを許可しないことです。競合を起こさずに他の人の意見を聞くのに役立つものは何でも役に立ちます。

それがうまくいけば、準備は完了です。そうでなければ、問題について彼に話してください。コーチングを使用して、問題を明確に理解するのに役立つ強力な質問をします。なぜ彼が支配的な役割を引き受けたのか、根本的な原因を突き止めてみてください。たぶん彼はチームへの信頼に欠けており(なぜ?)、成功に責任があると感じるかもしれません(なぜ?)。私は、この役割は彼が望んでいるものではなく、彼がそれを変えたいと思っている可能性が高いと思う。彼周りに来てそれを実現するかもしれません


1

おそらく、「支配的な」開発者は、チームの成果ではなく、個人のパフォーマンスによって報われるのでしょうか?

過去に、私は非常に発言力があり、明確なアイデアを持っている人々も、他の人の貢献を促進することによって(目標を通して)報われることを確認しました。

一般的に、スクラムメンバーにチームの成果ではなく、個々の貢献にしっかりと報いるのは悪い考えだと思います。

他のチームメンバーのコメントが真実であると思われる場合にのみ、すべてのチームメンバーに対してチームで360回のフィードバックを行うこともできます。


1

彼が次のスプリントのスクラムマスターになることを提案します。

責任を引き受けようとする人々は問題ではなく(彼らを独占したくない限り)、それはまさに私たちが自己組織化で達成しようとしているものです。

ちなみに、回転スクラムマスターの役割を持つチームは珍しくありません。


0

スクラムマスターの唯一のタスクは、全員がスクラムブックのルールに従ってプレイすることを確認することです。非スクラムマスターがスクラムマスターの邪魔をせずに自分でそれを行う場合、それはあなたが素晴らしい(スクラム)形状であることを示すでしょう!スクラムマスターがしなければならないことは、スクラムの観点から見るとチームの意気消沈であります。最終的には、スクラムマスターの役割を排除する必要があります。

繰り返しますが、スクラムマスターは開発プロセスには参加しません。彼は、すべての利害関係者が正しいことについて時間内にコミュニケーションを取り、スクラムを知っており、スクラムを行うためのガイダンスを提供する必要があります。彼はプロダクトオーナーでもプロジェクトリーダーでもありません。異なる何かを経験した場合、アジャイルスピリットでスクラムをやっていないかもしれません。もちろん、小さな設定では、スクラムマスターはチームメンバーまたはステークホルダーの役割の1つになる可能性があります。そして、それは、手続きの時間になったときのキャップです。リーダーシップの役割と混同しないでください。これはガイダンスの役割です。


-1

個人主義と個人のパフォーマンスを受け入れますが、受動的な個人がより参加できるように力を与えようとします。

私の経験では、一見似ているように見えるかもしれませんが、共産主義とアジャイルは同じではありません。アジャイルは、階級のない社会(チーム)ではなく、機能するソフトウェアを目指しています。

アルファ開発者に、常に最初に答えて個々の成果を達成するのではなく、尋ねたりコーチングしたりすることで、他のスキルの開発を支援できることを理解させてください。確かにあなたのアルファ開発者は良いソフトウェアを気にする人であり、それはあなたがあなた自身を失うことを許すことができないものです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.