スクラムチームの懐疑論者

私の会社は最近、アジャイルな作業方法に切り替えました。その一環として、SCRUMの使用を開始しました。私はこれに非常に満足しており、この方法は従来の方法よりも優れていると感じていますが、チームメイトの一部は同じ意見を共有していません。実際、彼らは「すべてのアジャイルなもの」について非常に懐疑的であり、それを真剣に受け取らないでください。例として、チームメイトの1人は常に会議に遅れており、実際には気にしません。管理IMOはこれに気付かないようにします（おそらく新しいため、人々がそれに慣れるには時間がかかります）。

私の質問は、チーム内で対立を起こさずにこの問題に対処する方法です。

極端な懐疑に直面したとき、私はいくつかのことを試します：

1.）TDD、継続的展開、ペアプログラミング、ユーザーとの要件収集、短い反復などの手法を示します。これらの手法をアジャイルとは呼びません。アジャイルマニフェストについてはrpりませんしかし、それは異なります; p）。チームメンバーに便利なツールとテクニックを紹介するだけで、生活が楽になります。彼らは日々の利益を見たら、アジャイルの時流に乗る傾向があります。

2.）すぐに完全なSCRUM（またはその他の）方法論に切り替えません。一度にアジャイルの小さな側面を紹介することが常に最善です。

3.）懐疑論者に同意します（ある程度）。アジャイルは特効薬ではなく、SCRUM、Kanban、Leanなども特効薬ではありません。代わりに、私は彼らと協力して、どの側面が彼らに利益をもたらすかを確認し（CIサーバーは通常、非常に簡単です）、残りを「1週間スタンドアップをして、それを確認します」を試しました。

他の方法論と同様に、SCRUMやその他のチームは、疎外するのではなく、実際にチームや組織と連携する必要があります。

だからあなたの質問に直接アクセスします。チームでそれを上げる：

「私はスタンドアップについても少し懐疑的ですが、チームとして1週間（言い訳はありません！）適切にテストを行い、それが私たちにとってうまくいくかどうかを確認するべきだと思います。思う？」

誤って実装されたスクラムの典型的なケース。

チームにスクラムが課されました。（全体）チームはそれを選択しませんでした。

実装する場合は、チームと経営陣の両方を完全にサポートする必要があります。そうしないと、まったく機能しません。

ここでは変化に対する抵抗が敵です。

最初からやり直して、チームにスクラムを提示し、質問をしてもらうことを強くお勧めします。

アイデアの販売に失敗した場合、望まない方法論を使用してそれらを強制しようとしないでください。彼らはそれを妨害するためにあらゆることをします。毎日のスタンドアップに遅れることは、あなたが得る行動の一つです。

あなたの会社にとってスクラムはお勧めできないかもしれないことに注意してください。その質問に答えることができるのは、基地で働く人々だけです。チーム。

毎日の会議の概念は、人がしていることにあまり当てはまらない可能性があります。これらの会議は無料ではありません。

重い数学のように、あなたがやっていることが長期にわたる集中力を必要とする場合、会議はあなたを混乱させ、イライラさせることができます。私は、毎週会うことを好むそのような人と仕事をしています。これは完全に合理的です。

実際、私があなたのプログラミングチームにいた場合、正直に言うと、おそらく懐疑的でしょう！私は物事に革命を起こし、プロジェクトを予定通り、予算内で、バグのないものにするための方法論の長い列を見てきました。これは最新のものです。なぜヘビ油を信じなければならないのですか？10年前、同じ人々が何か他のものをむち打っていました、数年後には新しい何かがやってくるでしょう。誤解しないでください。新しい方法論のいくつかは有用なアイデアをもたらします。残念ながら、彼らは多くの教義と愚かなアイデアももたらします。

彼が乗船しなくても本当に重要ですか？彼にいくつかのプログラミングタスクを割り当て、彼が望むように任せるだけです。彼の仕事が満足のいくものであるなら、彼に任せなさい。彼の仕事が満足できない場合は、彼を交換してください。人々がスクラムに従うことがなぜそんなに重要なのですか？

長年、私は多くの優秀なプログラマーがマネージャーが新しい方法論を導入し続けているために、辞めるか悩まされるのを見てきました。彼らはただコーディングして仕事をやりたいだけです。数年後、あなたはスクラムを呪い、最新の流行が何であれジャンプしてくれると信じています。

アジャイルを実行している場合は、作業中のバックログが必要です。スクラムを使用して、バックログから割り当てを配布します。

会議の最初に、最初に選択された（最良の）割り当てが選択されます。遅刻した人が到着したら、その日の残りを彼に渡します。

彼がプログラミングへの神の贈り物であるかどうかは関係ありません、彼は誰も望んでいないくだらない仕事を得ます。彼が別のタスクをスチールしようとする、または他の何かに取り組む場合、チーム全体が彼に寄りかかって、彼が「選択された」タスクのみに取り組むように強制する必要があります。おそらく、選択した作業に取り組んでいない場合、変更を拒否できるビルドマスターが必要です。

また、チームは目標と潜在的な報酬を設定する必要があります。チームとして投票して、参加していない人に報いることはできません。これは、経営陣がアジャイルチームに与えた所有権の量によって異なります。チームを傷つけ、チームの成功を妨げている人々の管理を思い出させる。

彼が時間通りに現れれば、彼はプロセスに参加できることを彼に思い出させる。

スクラムチームは自己組織化されることになっています。スクラムは、すべてに極度の透明性を実装することでも機能します。

したがって、明らかな答えは、スクラムマスターが会議を呼び出し、問題を説明します（ただし、チームの全員が既に問題の内容を正確に把握しているため）彼らはそれについてやろうとしている。それから彼は隅に座って口を閉じたままにします。

明らかに、これはスクラムの新しいチームです。そのため、重要なことは、スクラムマスターがチームが出した答えを受け入れなければならないということです。彼がそれらを無効にしたり、ソリューションに彼自身のアイデアを押し付けたりすると、チームが自己組織化を許可されているというチームとの信頼を破壊します。チームが何もしないことを決定する可能性があります。

いずれにせよ、この問題はスプリントの回顧展でレビューされるべきであり、彼らが思いついた解決策の有効性について議論することができます。

「チームの競合」を回避することは、要因となることすらありません。

チームメイトを解雇すれば、チーム内で論争を引き起こすことはありません。

古い作品を閲覧し、ウォーターフォールアプローチが過去に何度もあなたを失望させた方法の例をいくつか掘り下げてください。次に、チームメイトにケースを提示します。常識を垣間見ると、彼は光を見ます。

プログラミングは精密な活動であるため、まれな個人は難しい事実を受け入れないでしょう。少なくとも、理論的には。

切り替えを決定したのは誰で、その理由は何ですか？それらの決定に懐疑的な人たちがいるのか、それとも決定が下されたのでしょうか？

新しいメソッドの実装が厳格すぎたり、速すぎたりしていますか？古い方法を使用して、良い（必ずしも完璧ではない）製品を出しましたか？懐疑論者にどのように利益をもたらすかを実証しましたか？デモできますか？「光を見て」いる人々は、それが彼ら、チーム、そして会社にどのように利益をもたらすかについて懐疑的な人々に示しましたか？

おそらくあなたは彼らに信者の言葉だけですべてを受け入れるように頼んでいるのでしょう。これらの懐疑論者は、以前に新しい方法論を採用しており、実現した場合にはメリットがなかった可能性があります。

たぶん、あなたはあなたの新しい手順を使って、信者だけがそれに取り組んでいるプロジェクトを1つか2つ行うことができます。実際の測定を行い、懐疑論者に実際のメリットを示します。懐疑論者と彼らの古いやり方と信者と彼らの新しいやり方との間に少しの競争を設定することさえあるかもしれません。

もちろん、懐疑論者が勝ったらどうしますか？

チームミーティングを開催して、会社がSCRUMに切り替えた理由を話し合い、理解し、SCRUMが現在の運用モードに付加価値をもたらすと考えていることを全員が特定できるようにします。時々、企業は骨の折れる切り替えを行います（私はスクラム会議に参加して、誰も本当に耳を傾けず、誰もが昨日やったことをガラガラと鳴らします。これらのチームは、通常、私と一緒に」とそこにぐるぐる回っています。それは単なる時間の無駄です）、だからあなたに最適なものを取る。

退役軍人は通常、現在の働き方を変える可能性のあるあらゆるものに対して多くの抵抗を持っています。この場合、私はその人と1：1を持っているか、彼をスクラムマスターにします:)。一度責任を与えれば、彼らはそれで平和を見つけるか、それが価値を追加していないので完全にそれを廃止します。両方とも勝ちです。