非生産的なスクラムチームに対処するにはどうすればよいですか？

バックストーリー：
私は過去3年間このチームの一員として働いていましたが、今回は3つの異なるスクラムマスターがいます。

スクラムマスターの変更とショーの運営方法のため、原則が一貫して実施されておらず、スクラムマスターの1人がアジャイルを信じない人だったため、私のチームはスクラムのアイデアに無感覚になりました。開発と企業の決定に従うための初心者としてのイベントとアーティファクトの保持。

私のチームメンバーは、スクラムイベントを行うときにイライラして退屈し、特に一人はこのことについて非常に口頭で話します。

現在：
2か月前、会社はアジャイルとその原則に専念するために、私のチームのスクラムマスターを任命しました。

私は、チームメンバーがスクラムを実行したくないという大気圧の下で非常に苦しんでいます。

前述したように、彼らは全体のプロセスに悩まされており、プランニング、レトロスペクティブ、およびデイリースクラムを効果的にするために必要な会話に参加していないため、私にとって非常に困難です。

彼らにとって、計画は時間の浪費です。なぜなら、私たちはオーバーフローを新しいスプリントに移し、とにかく作業を完了しないからです。

振り返ってみると、彼らは「スクラムをやめる」と言いたいと思うだけです。一人はそうしますが、他の人は黙っており、私は毎回これに対処しなければなりません。

デイリースクラムもまた、彼らにとっては時間の無駄です。彼らは「昨日はタスクXに取り組みましたが、今日もまたタスクXに取り組みます」と述べています。そしてほとんどの場合、彼らは冗談を言って冗談を言った。

これらのイベント中に彼らがどのように時間を過ごしたかということになると、私は非常に大きくなりました。しかし、私はこれに情熱を傾けており、彼らはもう気にしないので、内側で死にかけています。

今日、私に常に反対している人は、「彼らはこのスプリントのためにコミットしたことだと言った」と言うのをやめるように言った。次のスプリントでクォータを埋めます。実際にKanBanを実行します。

なぜ彼がこれを言うのか理解していますが、彼とチームの他の全員が気にしないので、これがそうであることを理解していないようです。障害を処理するのではなく、単に機能します。彼らは障害について文句を言いますが、それらについては何もしません。そして、私が彼らを助けようとするとき、彼らはそれをすくい取るだけです。

かつて彼らは気にかけていましたが、過去2年間で彼らの意欲は多少なりとも底に落ちました。

これらの会議中に冗談を言ったり時間を無駄にしたりすると、会社に多額の費用がかかることを彼らに見せることができますか？

失敗したソフトウェアプロジェクトに関する多くの統計を聞いたことがありますが、失敗は技術的な性質のものではないという結論に達しました。技術的な問題は何百もの技術的な解決策で解決できますが、スクラムを使用して職場の雰囲気の問題を解決することはできません。

ここでの私の提案は、これを技術的な問題として見ることを完全にやめることです。それはスクラムではなく、毎日のスタンドアップ、スプリント、回顧展、その他のようなものではありません。あなたはあなたのチームと連絡を取り、あなたとあなたの上司だけでなく彼らを満足させる効果的な働き方を見つける必要があります。

彼らがデイリーが悪い考えだと思うなら、あなたは彼らにデイリーをするように言って、彼らにあなたの推論をパンチしようとするべきではありません。デイリーがあなたに提供するものが何であるかを自分で考えてください。チームがこれらの利点も重視しているかどうかを確認してください。彼らがあなたの理解を共有しない理由を見つけてください-彼らの視点を理解するときではなく、彼らに何かを納得させるときではありません。次に、日刊紙が実際にチームに役立つかどうか、または他のメカニズムを使用してより多くを達成できるかどうかを確認します。スクラムマスターの面白いところは、彼らが彼らのチームの召使であるということです-あなたはスクラムを完全に廃止することで彼らに最高のサービスを提供できるでしょう。

要約すると、スクラムに集中するのをやめ、代わりにアジリティの基本に戻りましょう。アジャイルマニフェストで最初から始めたいと思うかもしれません：プロセスとツールよりも個人と相互作用を大切にします。

私の経験では、幻滅したチームは効果的な回顧を行うことから始める必要があります。私の意見では、レトロスペクティブがアジャイルプロセスの唯一の必須部分である理由です。他のすべては、回顧を通じて変更される可能性があります。

効果的な回顧では、問題について不平を言うだけでなく、それらの問題の少なくとも1つを選択し、考えられる解決策を特定し、次の反復でその解決策を試します。次の回顧展では、そのソリューションがどのように機能したか、または機能しなかったかについて話し、必要に応じてさらに調整するか、作業する別の問題を選択します。

チームメンバーがプロセスに実際の変化をもたらす力を持っているとわかると、彼らは積極的に関与するようになります。

レトロスペクティブプロセスは、アジャイルが得意な企業のすべてのチームを訪問する場合、全員がやや異なる方法でそれを行う理由です。カンバンを行うチーム、XPを行うチーム、月曜日、水曜日、金曜日のスタンドアップのみを行うチームがあります。

あなたのチームが二日酔いに対処する方法を好まない場合は、いくつかの異なるアプローチをブレインストーミングします。振り返りを常に聴き、解決策を試すだけで、非常に消極的な開発者に勝ちました。

それでは大まかに始めましょう-問題の大部分はあなたにあります-あなたは聞きますが、あなたは聞きません。あなたのチームは問題点を明確に伝えています。チームを非難するのではなく、それらに対処する必要があります。

計画中

彼らにとって、計画は時間の浪費です。なぜなら、私たちはオーバーフローを新しいスプリントに移し、とにかく作業を完了しないからです。

まさに。タスクに常に適切な時間を割り当てず、タスクが常に過小評価されている場合、非常にマイナスの影響があります。

• 開発者は、常にプレッシャーにさらされているように感じます。
• 「時間内に何もできません」。
• このプロセスは機能しないため、彼らはそれを時間の無駄だと考えています。

解決策：次の組み合わせを使用して推定値を修正します。

• ストーリーポイント（時間とリスクの組み合わせとして）。
• 55 SPを超えるタスクをスプリントに許可しない
• 比較推定
• エビデンスベースのスケジューリング

これの基礎として、前のタスクを完了するために実際にかかった時間を絶対に追跡する必要があります。これには、テスト、ドキュメントの作成、テストの作成、エンドユーザートレーニング、統合作業、展開が含まれます。等

特定のタスクの合計時間を取得したら、それらの以前のタスクに基づいて予想時間を設定できます。

与えられたタスクが以前のタスクの選択よりも複雑または簡単に感じられるかどうかをすべてのメンバーに尋ね、それに基づいて割り当てられたタスクの数を調整します。

あなたが以前にSPを使用したことがない場合、私のアドバイスは、ガイドラインとして神の仕事に真の1時間= 5SPから始めることです。通常の開発環境では、1日あたり6個になる可能性があるため、1日あたり最大 30SPになることに注意してください。ボードに乗るまでに2日以上かかるタスクを許可しないでください。理想的には、私の経験では、1日に2つのタスクが必要です。

計画を正しく行わないと、スクラムアクティビティの残りの部分が時間の無駄になります（計画を含む）。

回顧

振り返ってみると、彼らは「スクラムをやめる」と言いたいと思うだけです。一人はそうしますが、他の人は黙っており、私は毎回これに対処しなければなりません。

Daily beatings will continue until morale improves!過去の仕事の2つを思い出させます。障害を除去しない場合、これは時間の無駄であることが正しいです。

繰り返しますが、人々が実際に言っていることに耳を傾けます。振り返り中に提起された苦情が対処されていない場合、なぜそれらを実行するのが面倒なのでしょうか？

そう：

• コミュニケーションを改善するために、Six Thinking Hatsのテクニックを検討してください。
• Retrospectiveに費やす時間を最大30分短縮します。
• レトロスペクティブ中に提起された苦情が次の苦情の前に対処されるようにします。

デイリースクラム

デイリースクラムもまた、彼らにとっては時間の無駄です。彼らは「昨日はタスクXに取り組みましたが、今日もまたタスクXに取り組みます」と述べています。そしてほとんどの場合、彼らは冗談を言って冗談を言った。

ここには2つの問題があるように思えます。SCRUM会議が長すぎることと、計画とタスクの作成が面倒です。

両方とも、スクラム会議が時間の無駄であるように聞こえます。

スクラム長の場合：

• 最大15分間試してください。
• みんな立ち上がってみてください。
• 固定式：
  • 昨日は何をしていましたか。
  • 今日は何を計画していますか。
  • チームメンバー（あなたではありません！）がタスクについて知っておくべきこと、タスクに与える影響。
• あなたがそれらに対処するつもりがない場合、障害に悩まないでください。

これは、あなたの計画があなたの状況を損なうことの2番目の証拠です。もしあなたが報告する特別なものが何もないなら、それは通常タスクが大きすぎて、あなたが言えることはすべて私がそれに取り組んでいることを意味します：

• タスクを箇条書きに分けます。
• タスクが1日未満で済むように十分に小さいことを確認してください。理想的には、IMOタスクは約3時間持続し、約13 SPに相当する必要があるため、ほとんどの条件で1日2回行うことができます。

チームに対処する

今日、私に常に反対している人は、「彼らはこのスプリントのためにコミットしたことだと言った」と言うのをやめるように言った。次のスプリントでクォータを埋めます。実際にKanBanを実行します。

彼は正しい。あなたは間違っている。ろくでなしのSCRUMやカンバンのバリエーションを行っています。彼らのせいではありません。

なぜ彼がこれを言うのか理解していますが、彼とチームの他の全員が気にしないので、これがそうであることを理解していないようです。

まったく理解できないと思います。彼らは以前よりも思いやりが少ないかもしれませんが、彼らを責めることは何も改善しないだけでなく、状況を悪化させるだけかもしれません。それが岩の底だった場合、彼らは実際に掘り始めるかもしれません。

障害を処理するのではなく、単に機能します。

そして、ここで私は仕事をすることが彼らの仕事のすべてであると思った。誰が障害に対処することになっていたのだろうか…。スクラムマスター。それはあなたの仕事です。何が悪いのか教えてくれます。あなたはそれを修正します。その逆ではありません。

これがおそらく、レトロスペクティブで多くの問題を抱えている理由です。

これらのミーティング中に冗談を言ったり、ジャークを回したりすると、会社に多額の費用がかかることを彼らに見せることができますか？

役に立たない会議を停止し、代わりに彼らはwatercoolerの周りに冗談を言うでしょう。士気を改善するbe打についてのパラグラフも参照してください。彼らが防御メカニズムとしてユーモアを使用している場合、いくつかの深刻な問題があります。

冗談を言う-反対ではなく、あなたのチームとの仕事のように。（fuuuuuuckが会社のお金を気にしているのは誰ですか？あなたは今株主ですか？）

要約する

あなたの悪い計画は、SCRUMの他の部分を失敗させ、参加するすべての人を悲惨なものにしています。彼らは何も変わらず、何も対処されず、彼らの苦情が聞かれないことを理解します。

計画を改善すると、フローと士気が向上します。

障害を取り除いて仕事をすれば、チームはより速く進歩します。彼らにあなたが彼らを助けるためにあなたがすべきと思うことを尋ねてください。

最も重要なこと：あなたの人々に耳を傾けます。彼らはすでにあなた（そして私）に何が問題なのかを話しました。

幸運を！

主要なアジャイル原則の1つは、戻って、間違っているものはすべて修正することです。これには、コードのリファクタリングとバグ修正だけでなく、開発プロセスの修正も含まれます。

それでは、どうしてチームとミーティングをして、開発プロセスをどのように改善できるかを見てみませんか？つまり、スクラムやスタンドアップミーティングはありません。

また、アジャイルマニフェストの原則の1つである「プロセスとツールに対する個人と相互作用」を破っています。

一方、反復的な開発が悪いとチームが考えている場合は、間違っている可能性があります。1回の反復で計画したすべてを完了しなくてもかまいません。次の反復にいつでも移動できます。また、物事を「含む必要がある」、「持っている必要がある」などとマークする理由でもあります。新しい機能を提供する限り、あなたはそれをうまくやっています。

ほんのわずかな暴言：私は以前の会社と現在の会社で、スタンドアップミーティングを行いました。私の経験からは、30分以上のステータスレポート会議に変わるたびに情報がほとんどまたはまったく提供されないため、時間の無駄です。人々は自分の問題について話しますが、正直言って私は気にしません。
私の前の会社では、彼らは賢く、スタンドアップでこの問題を認識し、人々が不平を言い始めた直後にそれらを止めました。

あなたはスクラムについては本当に良いビデオを見たい場合は、「参照-スクラムを忘れた土地ロバートC.マーティン」。

優先事項として、引き継がれ続けるタスクを見ていきます。目標を達成しないことは非常に意気消沈します。コミットしすぎていますか？分解すべきファットログはありますか？制御できないボトルネックはありますか？「完了」の明確な定義はありますか？要件は明確ですか？開発者1人あたりの時間は妥当ですか（管理、スタンドアップ、計画、回顧、キーボードブレーク、非プロジェクト作業を考慮に入れます）。

次に、機能していないものはすべて捨てます。価値のないプロセスはただの泥棒です。スタンドアップは、集中しておらず、チームに価値をもたらさない場合、膨大な時間を消費する可能性があります。時間は他の場所で費やす方が良いかもしれません。チームが大きすぎる場合は、チームを分割することも検討してください。

チームの動機付けとなるものを把握してください。回顧を行い、さらに重要なことに、出力に基づいて行動します。成功を祝うだけでなく、失敗を見ることも同様に重要です。

最後に、ブランドを傷つけた可能性のあるスクラムマスターのアプローチを評価することもできます。私は有毒なスクラムマスターの下で働いていましたが、それを知っていようといまいと、発生したすべての問題がワークロードに追加されていました。最終結果：問題は無視され、全員が小さなチームワークで自分の小さなエリアで作業しました。

チームがスプリントを効果的に閉じる（少なくとも80％のストーリーのように）スプリントを超えるスプリントは、私ができる最も重要なことの1つです。チームが常に欠落している場合は、推定値を調整する必要があることを明確に示しています。

開発者が見積もりについてより現実的になるのは非常に難しいかもしれませんが、チームはこれを受け入れる必要があります-私は1年間スプリントを閉じなかったチームで働いていました（スプリントの50％未満を一貫して閉じます） 、常に見積もりを下回っており、すべての計画/回顧において、自分の見積もりが悪いと言っている孤独な声でした。おそらくそれよりも外交的にはそれが基本的な感情でした）-あなたがそのポジションにいるとき、あなたが実際にKonBonをしているので、あなたがそれを呼ぶもの。ある時点で、彼の意見は状況によって検証されます。それ'

ある時点で、物事をリセットする必要があります。システムを稼働させるために、チームが見積もりを大幅に過大補償する必要があります。チームが一貫してストーリーを閉じ始めると、アジャイルプロセスは主に常識であり、何らかの形でアジャイルプロセスを実現しないと、生産性に有害であることに気付くはずです。しかし、「コミットメント」と「スプリントの目標」が一貫して達成されない場合に発生する真剣に受け止められない限り、全体は偽物であり、チームの生産性を損なうことになります。

大幅に異なるスプリント（見積もり、計画、コミットメントなど）で人々を買収することは困難です。そのチームでは、2つの要因により最終的にそれを達成しました。1つは、JIRAからデータを収集して、「言い訳はありません。数値は常に1方向にずれています。修正する必要があります。レトロで言い訳はしたくないです。そして、もう1つは、最終的に次のように説明した経営陣の上位からのプレッシャーでした。「このプロセスのポイントは、開発タイムラインを予測可能にすることです。それに関係なく、スプリントは私たちの仕事を正確に反映する必要があります。経営陣は、実際のアウトプットに対するよりもコミットメントに対する私たちの成功をよりよく認識しています。何もしない。この時期からさらに削除された人々は、彼らがあなたの失敗を見ているだけであり、レトロであなたがする言い訳は彼らの範囲内にあるものでさえなく、彼らはあなたが失敗しているのを見るだけです。

最終的に私たちのチームは牽引力を獲得し、物事はずっとスムーズかつ低調になり始め、見事に、プロセスが実際に機能し始めてから、より高い出力を得るようになりました。tl; dr-スプリントのクローズを開始するために必要なことは何でも行い、比較的高い成功率で。そうしないと、チームのカーマジオンは、結果によってスクラムに対する抵抗力を検証し続け、最終的にはあなたのプロセスが実際にはすべての人の時間の無駄であり無駄であると正しくなります。

スクラムマスターとして、チームのコーチを指導し、生産性を高めます。スクラムフレームワークはそこに到達するための強力なツールですが、スクラムフレームワークが単独で目標になることは絶対にありません。そうでなければ、Cargo Cultを実行しています。

Cargo Cultを3年間やっているようで、人々はそれが恐ろしいプロジェクト管理方法論であることに気付きました。良いニュースは、あなたが賢い人々を持っているということです、彼らはそれを正しくしました。残念ながら、あなたの会社の何人かの人々はそれをスクラムと呼んでいますが、あなたは再び賢い人々を持っています、彼らはチームのしていることはスクラムと呼ばれないことさえあなたに話しました。

計画は時間の無駄に過ぎません。なぜなら、私たちはオーバーフローを新しいスプリントに移し、とにかく作業を完了しないからです。

まさに。なぜわざわざ？答えを見つける必要があります。あるいは、計画とスプリント自体を変更して、計画のポイントが必要です。それか、無意味なスプリントプランニングでみんなの時間を無駄にするのを止めましょう。優れたスプリントプランニングを実行することは簡単ではないため、会社にスクラムマスタートレーニングを依頼することができます。

回顧中[...]他の人は沈黙しており、私は毎回これに対処しなければなりません。

レトロスペクティブごとに同じ問題を扱っている場合、人々はレトロスペクティブ中に話すことさえ（もう？）気にしません。それは時間の無駄です。あなたまたはチームが何らかの形で回顧展で提起された問題に対処できない限り、会議はチームの士気をくじくだけです。レトロスペクティブで提起された問題に対処する必要があり、次のレトロスペクティブまでに進展がなければなりません。

デイリースクラムもまた、彼らにとっては時間の無駄です。彼らは「昨日はタスクXに取り組みましたが、今日もまたタスクXに取り組みます」と述べています。

確かに、同じタスクを数日間行うだけで全員の時間を無駄にするのはなぜですか？彼らは絶対に正しいです、デイリースタンドアップは確かに無意味です。スタンドアップは、それぞれが半日以内に完了することができる多くのタスクで密接なコラボレーションを促進します。タスクがそのように分解できない場合（壊れたスプリントプランニングのため、または実際にタスクがスクラムにうまく適合しないため）、5分間のデイリースタンドアップミーティングを開催することはあまり意味がありません（ 5分以内ですか？）。

「スプリントを完了することはありません。次のスプリントで新しいタスクを取り込んでクォータを埋めます。実際にKanBanを実行するので、それを言うのはやめてください。」

なぜ彼がこれを言うのか理解していますが、彼とチームの他の全員が気にしないので、これがそうであることを理解していないようです。

いいえ、あなたは彼がこれを言う理由を絶対に理解していません。障害の根本的な原因-あなたが解決する必要がある-間違っています。彼らは、チームのプロジェクト管理のやり方が悪いので気にしません。Cargo Cultをやり、Cargo Cultをより難しくすることは、現在の最悪のプロジェクト管理手法の1つであるCargo Cultであることを止めるものではありません（あなたの防衛では、最も広く使用されています）。

これについて何ができますか？

1. 彼らの懸念に耳を傾けてください。繰り返しますが、あなたはあなたが賢い人々を持っているということに恵まれています。

2. 彼らが障害を解決するのを助けてください。

そして、それだけです。スプリントプランニング、デイリースクラム、レトロスペクティブを変更してチームにとって価値のあるものにする方法を試してみる必要があります。スクラムラベルを削除したい場合でも、これら3つの会議は同じ頻度で同じ目的で行われます。そこにプロジェクト管理方法論。実験の方法（頻度、コンテンツ、会議の主催者、時間、期間など）については、驚くほど簡単です。チームに尋ねてください。あなたが彼らにあなたのアイデアを強制することを許可する必要がある場合、彼らにあなたのアイデアを強制しないでください（彼らがいくつかに同意できると仮定して）。

あなたがコントロールを失うことを恐れている場合は、事前にいくつかの境界を設定してください、例えば：

• 会議のラベルは同じままです。
• 会議は引き続き行われ、会議の頻度は2倍以上変更することはできません。
• 現在実験中であるため、変更は2つのスプリントだけ継続します。その後、古いパターンに戻ります（スプリント期間を2倍にしたい場合にあいまいさを避けるために、数週間で時間を与えてください）。

私は誰もがアジャイル宣言から同じ行を引用していると思います。私も同じことをします。「プロセスとツールに対する個人と相互作用」。

SCRUMマスターとしてSCRUMを使用してジョブを実行したい場合は、1人の個人が別の個人とやり取りするときにそれらにアプローチする必要があります。プロセスを改善する方法についてブレーンストーミングを開始します。たぶん、あなたは彼らにSCRUMを好きになるように説得することができます。たぶん、彼らはあなたに別のプロセスを使うように説得することができます。確認してみましょう！

チームは、現在のシステムが仕事をしていないことを既に認識しているようです。仕事ができると信じるように彼らを励ますことができますか？いくつか例を挙げます。スプリントがいっぱいになりすぎて、常に漏れる場合は...停止します。それはあなたのSCRUMチームです。過剰なコミットをやめさせます。経営陣を押し戻して、呼吸の余地を確保してください。目的に合わせてSCRUMを使用します。これを使用して、プロセスから価値を失いそうなほどにプッシュしていることを管理者に提示します。管理者がSCRUMをプロセスとして必要とする場合は、SCRUMを取得して、修正に必要なスペースとエネルギーの構築を支援してください。SCRUMマスターとしてのあなたの仕事は、チームが生産的になるように問題を解決することです。

別の便利なアプローチは、古いプロセス内で新しいプロセスを生成することです。役に立たない方法でSCRUMを実行し続けますが、スケジュールのごく一部を控え、「スケジュールのこの部分では、ツールを適切に使用する方法を考えます」と言います。そこに行き過ぎないでください。メトリックを使用します。そこにあるすべての会議に集中してください。「SCRUM」プロジェクトの残りの部分は、あなたとあなたのチームが「ソフトウェアを開発し、他の人がそれを行うのを支援することにより、ソフトウェアを開発するより良い方法を発見します」。時間が経つにつれて、このバケットに大切なタスクをどんどん入れていくと、古いバケットはゆっくりと消滅します。すぐに、あなたは活気のあるソフトウェア開発環境を手に入れ、誰も賢くありません。

またはそれらを組み合わせて一致させます。私はアンチスクラムのプログラムに取り組みました。クライアントは、プロセス中の任意の時点で新しいタスクを追加し、すぐにそれらを実行することを望んでいました。（これは実際には正気のリクエストでした：彼らの仕事は非常に不安定で、彼らはしばしば迅速なサポートを必要としました...それは私たちが支払われたものです）。もちろん、「スプリントで約束したときにXが実行されない理由」の問題に対処する方法を理解する必要がありました。私たちのソリューションは、実際には2段階のプロセスを構築することでした。適切な優先順位付けのために、長期タスクがSCRUMに配置されました。短期間のタスクは、クライアントと開発者間の緊密な相互作用に焦点を当てた自作のプロセスに入れられました。クライアントはこの短期的なプロセスを使用して私たちをプッシュすることを歓迎しているが、そうすることはスプリントをプッシュすることを理解していることが理解されました sタイムライン。彼らは、彼らが引き起こしたスケジューリングの問題を同時に聞き取り、対処することなく、リクエストを追加することを禁じられていました。結果？動いた。ほとんどのタスクは、本来あるべきようにSCRUMプロセスに入れられ、緊急事態はシームレスに相互作用しました。態度は「お客様になりたい場合は、SCRUMストーリーに沿って立ちましょう。パートナーになりたい場合は、お気軽にご来店いただき、このレベルの製品をお使いください。 ！」

私が本当に知っているからだ。上位スケジュール管理で問題が発生し、優先順位を設定できず、リリース日を延期せずにアイテムを追加する意欲があります。

以前は、このように機能する方法論はないと言っていましたが、カンバンを見たことがあるので、カンバンは気にする必要がないからです。オーバーコミットしても機能し続けます。結果をより速くもたらすことはできませんが、キュー内のバックアップを個人に配置することは許可されていないため、管理の問題は管理にかかっています。フィードバックレポートには過負荷が表示されますが、これは正しいです。

スクラムマスターのこの変更とショーの実行方法のため

まあ、これはあなたの問題かもしれません。スクラムマスターはショーを運営するためにそこにいません。彼はプロジェクトリーダーではありません。彼は、すべての利害関係者がコミュニケーションを取り、操作が透過的であることを確認します。

チームはどこから来ているのだろうかと思っています。スクラム（必然的なスクラムマスターを含む）がドロップされる前に、彼らは多かれ少なかれ自律的だったのでしょうか？そもそもスクラムが導入されたのはなぜですか？それは何を解決するはずでしたか？

スクラムはガイダンスを提供することになっており、あなたのチームは、彼らがそれを決して有用なものとして経験していないことを明らかにしています。彼らはガイダンスを気にせず、不適切な時間の無駄だと考えています。少なくとも1人の意思決定者が、とにかくガイドされる必要があると考えているようです。誰？どうして？彼らはポイントを持っていますか？

これはソフトウェアに限らない問題です。

どんな職場環境でも、性格や能力が異なる人がいます。たとえスクラムが完璧な方法であったとしても、その性格と能力のために、スクラムに反対する人がまだいるでしょう。

開発者は困難なタスクを合理的に処理します。これを可能にするために、各開発者は、スクラムのようなものに対する嫌悪感として現れるかもしれないそのようなことを処理する彼の方法を持っています。すべての開発者がまったく同じ方法でゼロからトレーニングされた場合、1つのパターンを使用する方がはるかに簡単かもしれませんが、そうでない場合は開発者側または管理側での適応が必要です。

さらに、独立した思想家（開発者や他の専門家）は、自分の仕事であり、意見の衝突が起こりやすいため、物事のやり方を教えられることを嫌います。スクラムは、通常、目の前の各問題に応じて分析し、行動する論理的思想家にとっては無意味な儀式のように思えます。

以下は、問題がどこにあるかを示唆しているようですが、それが何であるかではありません。これ以上のものは間違いなくあります。開発者が試みたが阻止されたと仮定することしかできません（経験不足）。開発者が何かを修正したいのに何度も見たことがありますが、体系的なもの（管理、会社の方針など）が不可能に近いので、あきらめます。彼らは本当に気にしないか、助けにはならないだろうと信じていることだけを気にしないのでしょうか（おそらく経験不足）。

なぜ彼がこれを言うのか理解していますが、彼とチームの他の全員が気にしないので、これがそうであることを理解していないようです。障害を処理するのではなく、単に機能します。彼らは障害について文句を言いますが、それらについては何もしません。そして、私が彼らを助けようとするとき、彼らはそれをすくい取るだけです。

かつて彼らは気にかけていましたが、過去2年間で彼らの意欲は多少なりとも底に落ちました。

これらのミーティング中に冗談を言ったり、ジャークを回したりすると、会社に多額の費用がかかることを彼らに見せることができますか？

何かが他の人々に押し付けられている場合、その方法を強制してその利点を説得するのは人々次第です。人々に物事を強制することを本当に信じてはいませんが、どんな状況でも、みんなに耳を傾け、現在の環境に合う方法を開発することをお勧めします。

スクラムには弱点がないわけではありません。もちろん私は自分で話すことができますが、開発者は正当な理由でそれを嫌っていると思います。私の正直な意見では、それを試みてはならないと思います。

理由を理解するには、すべてのスクラムマスターがスクラムについて知っておくべきことを読んでください。それは、私が書いた、まだすべては、私が唯一のようにまとめることができます私の経験の代表が存在していない純粋な恐怖。

私の場合、特にポイント5で苦しんでいました。基本的に、スクラムは私を子供であり敗者として扱っていました。今、私は同僚を助ける機知に富んだ共同開発者です…私が何を好むのも不思議ではありません！

私は今、新しい（スクラムではない）ボスを持っています。それはただ歩き回って人々と話すだけで、とても感謝しています！これが機能する理由の一部は、開発者間のコミュニケーションのためにチャットルーム（最も重要なものを使用している）も用意していることです。誰かが議題を持っている場合、私たちはそこにそれを取る。ミーティングは、開発者との特別な話し合いのためだけのものであり、自分で人為的な毎日の締め切りを課すためのものではありません。

あなたは多くの素晴らしい答えを得ました。役に立つかもしれないいくつかのポイントがあります：

方法論の変更は難しい

「これが私たちのやり方です」というinertia性の下で、期限やビジネスニーズの圧力に逆らって作業しているため、ワークスペースでは大きな課題です。

あなたのチームは計画にもっと多くの時間を費やす必要があると結論付けるのはかなり正しいです。その計画はあなたの時間は現在得意ではなく、改善する必要があるものです。問題は、新しいルールを口述するだけではそこに到達できないことです。新しいルールは、大きな助けになる前に新しい負担となります。そして、それらがすぐに大きな価値を提供しなければ、協力よりも回避を得るでしょう。

このトピックについては、Roy Osheroveを強くお勧めします。彼はの簡単な要約持って計画し、あなたの会社での効果の変更方法を、彼はにはるかに大きな深さで話題になり、このビデオ。

Osheroveの基本的な見解は、次のすべての課題に対処する必要があるということです。

個人的な動機： なぜ誰かが特定の行動をするよう気にする必要があるのですか？
個人的能力： 彼らは文字通りそれをすることができますか？
社会的動機： この行動に対する仲間からのプレッシャーはありますか？
社会的能力： 周りの人が私の行動をサポートし、助けが必要なときに助けてくれますか？
構造的動機：良い行動と悪い行動に対する報酬と罰はありますか？
構造的能力： 物理的環境はこの動作をサポートしていますか？

タスクを分解することを学ぶ必要があります

あなたのチームは、「昨日はタスクXに取り組んでいたが、今日もそのタスクに取り組む」と感じており、タスクが1週間遅れているという意味で正しいようです。

ここで本当に役立つのは、タスクを小さなコンポーネントに分解する方法を学ぶことです。探しているのは、「OK、タスクXに取り組んでいますが、タスクXでは具体的に今日何に取り組んでいますか？」という質問に対する答えです。

いくつかの答えは次のとおりです。

• 私はこのクラスのレガシーコードを学んでいます。
• 症状が（症状）であるバグを修正しています。
  • これがしばらく時間がかかっている進行中のバグである場合：「今日私がしようとしているのは...（計画）」
• このインターフェイスを変更する必要があります。
• 私はテストを書いています。
• 未テストのコードを統合しています。

...などなど。1日または1週間で実際に何ができるかを観察できることは、アジャイルの大きな利点の1つです。しかし、それは実際には、個々の日の解決を検討する必要があることを意味します。準備ができたらいつでも準備できるモノリシックなタスクXではありません。

完了と配信

1つの一般的な問題（アジャイル、および一般的な職場計画）では、期限は開発者ではなく管理者から来る傾向があるということです。その期限は、実際の作業とは離婚している可能性があります。特に、できる限り迅速に納品することが望まれます。

問題は、「できるだけ早く配信」が非常に混oticとしたプロセスであるということです。角を切ることを奨励します。「迅速で汚れた」コーディング; ガイドラインを無視する; 自分の後片付けをしません。「試してみて、うまくいくかどうかを確認します。はいなら、配達します。いいえなら、他のことを試してください」という考え方を奨励します。

あなたがあれば一方ているあなたは計画とテストなど、あなたが道標とセーフティネットの束を設定している程度厳格なら、系統的に取り組んでいます。時間がかかる可能性があります-即時配信を促進していないものに多くの時間を費やしており、まだこの種のワークフローがあまり得意ではないかもしれませんが、はるかに揮発性が低くなります。

自問すべきことの1つは、開発者が実際に必要とするニーズに応じて、スプリントの目標を設定しているということです。それとも、管理者が締め切りを設定し、開発者がスプリントのようなスケジュールにコミットすることを試してみることはできますか？

開発者が物事を計画する時間を与えられていない場合、または信頼できる計画に従って作業している場合、有用な見積もりを行うことができないのも不思議ではありません。:)

これは不評な意見かもしれませんが、あなたはそれについて何もできないかもしれません。

チームの存在とリーダーの流動の年月をかけて、本当にチームに不満を持っていた人々が去ったと想像できます。あなたが持っているのは、文句を言うかもしれないが、状況を改善するために実際に努力をすることに興味がない人々の残骸です。誰にも邪魔されずに8時間のハッキングコードを費やし、一日の終わりに帰宅したいだけです。ここにあるものは、深刻な動機付けの問題のようです。そして、その問題を解決するのはスクラムマスターの仕事ではありません。それはそれらの人々に支払っている人の問題です。

これが本当に当てはまる場合、実際のオプションのみが現在のチームを取り除き、ゼロからやり直すことです。チームで最高だと思う人を1人か2人残して、残りのチームを解雇するか、別のチームに移動するかもしれません。少なくともこの可能性について上司と話し合う必要があります。