逆効果のスクラムチームにどのように対処しますか？
バックストーリー：
私は過去3年間このチームの一員として働いており、今回は3つの異なるスクラムマスターがいて、すべてが異なる方法で実行されています。
スクラムマスターのこの変更とショーの実行方法のため、原則が一貫して適用されておらず、スクラムマスターの1人がアジャイルを信じない人であったため、私のチームはスクラムのアイデアに無感覚になりました開発と、会社の決定に従うための初心者としてのイベントとアーティファクトの保持。
今、私たちのチームメンバーは、スクラムイベントを行うとうんざりして退屈し、特に1人の人がこれについて非常に口頭で言っています。
現在：
2か月前、アジャイルとその原則への取り組みに専念していたため、会社は私にチームのスクラムマスターを任命しました。
チームメンバーがスクラムをやりたくないという大気圧の下で、私は非常に苦しんでいます。
前述のように、彼らは計画全体、回顧、および毎日のスクラムを効果的にするために必要な会話に携わっていないので、プロセス全体に悩まされ、私にとって非常に困難になっています。
彼らにとって、プランニングは時間の無駄です。なぜなら、私たちはオーバーフローを新しいスプリントに移すだけで、とにかく作業を完了しないからです。
振り返りの最中、私は彼らが「スクラムをやめる」と言いたがっているように感じるだけです。一人はそうしますが、他の人は黙っていて、私は毎回これに対処しなければなりません。
デイリースクラムは、話をしたり、その日を計画したりする必要がないので、再び彼らにとって時間の無駄です。彼らは単に「私は昨日タスクXに取り組み、今日もそのタスクに取り組みます」と述べています。そして、ほとんどの場合、私はより厳しいものになるまで彼らは冗談を言っています。
彼らがこれらのイベント中にどのように時間を費やしたかということになると、私は非常に大規模でした。しかし、私はこれに情熱を持っていて、彼らがもう気にしないので、私は内面で死にかけています。
今日、私に常に反対している人は、「これは彼らがこのスプリントのためにコミットしたことだと言った」と言うのをやめるように言いました、なぜなら彼の言葉では、「スプリントを完了することは決してないからです。次のスプリントで割り当てを埋めます。実際にはかんばんを使用しているので、それをやめます。」
私は彼がこれを言う理由を理解しますが、彼とチームの他の誰もが気にしないので、彼がこれがそうであることに気づいていないようです。彼らは障害に対処するのではなく、単に機能します。彼らは障害について不満を述べますが、何もしません。そして私が彼らを助けようとするとき、彼らはそれをすくめるだけです。
彼らは、いまいましいことをしていましたが、過去2年間で、彼らの意欲は、多かれ少なかれ岩の底にまで減少しました。
これらの会議中に冗談を言ったり時間を無駄にしたりして、会社に多額の費用がかかることを、どうやって彼らに見せることができますか？
失敗したソフトウェアプロジェクトに関する多くの統計を聞いたことがありますが、失敗は技術的な性質のものではないという結論に達しました。技術的な問題は何百もの技術的解決策によって解決できますが、スクラムを使用して職場の雰囲気で問題を解決することはできません。
ここでの私の提案は、これを技術的な問題と見なすことを完全にやめることです。それはスクラムではなく、毎日のスタンドアップ、スプリント、回顧展、またはそのような何かについてではありません。あなたはあなたのチームと連絡を取り、彼らとあなたとあなたの上司を満足させる効果的な働き方を見つける必要があります。
彼らがデイリーズを悪い考えだと思うなら、デイリーズをするように彼らに言って、彼らにあなたの推理をパンチしようとするべきではありません。デイリーズがあなたに提供するものは何かを自分で考えてください。チームがこれらの利点も評価しているかどうかを確認してください。彼らがあなたの理解を共有しない理由を見つけてください-彼らの見解を理解するのではなく、何かを彼らに納得させるのではありません。次に、デイリーズが実際にチームに役立つかどうか、または他のメカニズムでさらに達成できるかどうかを確認します。スクラムマスターの面白い点は、彼らがチームのしもべであるということです。スクラムを完全に廃止することで、彼らに最善を尽くすことができます。
要約すると、スクラムに集中するのをやめ、代わりにアジリティの基本に戻ります。最初から アジャイルマニフェスト から始めたいと思うかもしれません。
私の経験では、幻滅したチームは、効果的な回顧を行うことから始める必要があります。それが、私の意見では、遡及がアジャイルプロセスの唯一の必須の部分である理由です。他のすべては、遡及を通じて変更される場合があります。
効果的な回顧では、問題について不満を言うだけでなく、それらの問題の少なくとも1つを選択し、それに対する可能な解決策を特定してから、次の反復でその解決策を試します。次の回顧展では、そのソリューションがどのように機能したか、または機能しなかったかについて話し、必要に応じてさらに調整するか、取り組むべき別の問題を選択します。
チームメンバーは、プロセスに実際の変化をもたらす力があることを確認すると、より積極的に関与するようになります。
遡及的なプロセスがあるため、俊敏性に優れた会社のすべてのチームにアクセスすると、チームはやや異なる方法でそれを行います。カンバンを行うチーム、XPを行うチーム、月曜日から金曜日までスタンドアップのみを行うチームがあります。
チームが二日酔いにどう対処するかが気に入らない場合は、いくつかの異なるアプローチをブレインストーミングしてください。私は勝手にvery消極的な開発者だけを振り返って回顧し、解決策を試してみました。
さて、大まかに始めましょう-問題の大部分はあなたにあります-聞こえますが、あなたは聞きません。あなたのチームは問題が何であるかをはっきりとあなたに伝えています。チームを非難するのではなく、それらに対処する必要があります。
計画
彼らにとって、プランニングは時間の無駄です。なぜなら、私たちはオーバーフローを新しいスプリントに移すだけで、とにかく作業を完了しないからです。
丁度。タスクに正確な時間を割り当てることに一貫して失敗し、それらが常に過小評価されている場合は、非常に悪い影響があります。
- 開発者は常にプレッシャーにさらされているように感じます。
- 「間に合わない」.
- プロセスが機能しないので、彼らは当然それを時間の無駄だと考えています。
ソリューション：次の組み合わせを使用して推定を修正します：
- ストーリーポイント（時間とリスクの組み合わせとして）。
- 55 SPを超えるスプリントにタスクを許可しない
- 比較見積もり
- エビデンスベースのスケジューリング
これのベースとして、前のタスクを完了するために実際にかかった時間を絶対に追跡する必要があります。これには、テスト、ドキュメントの作成、テストの作成、エンドユーザーのトレーニング、統合作業、展開が含まれます。 。等.
特定のタスクの合計時間がわかったら、それらの以前のタスクに基づいて予想時間を決めることができます。
与えられたタスクが以前のタスクの選択よりも複雑か簡単かをすべてのメンバーに尋ね、それに基づいて割り当てられたタスクの数を調整します。
以前にSP=を使用したことがない場合、私のアドバイスは、1時間の本当の正直な作業= 5SPをガイドラインとして開始することです。通常の開発環境では、 たぶん1日あたり6つなので、30SP /日max。2日以上かかるタスクは決して許可しない理想的には、私の経験では、1日に2つのタスクを実行する必要があります。
計画を正しく行わないと、残りのスクラムアクティビティは時間の無駄に見えます（計画を含む）。
レトロスペクティブ
振り返りの最中、私は彼らが「スクラムをやめる」と言いたがっているように感じるだけです。一人はそうしますが、他の人は黙っていて、私は毎回これに対処しなければなりません。
Daily beatings will continue until morale improves!と過去の2つの仕事を思い出します。障害を取り除かなければ、それは正しいことです。これは時間の無駄です。
繰り返しになりますが、人々が実際に言っていることを聞いてください。振り返り中に提起された苦情が扱われていない場合、なぜそれらを行うのが面倒なのですか？
そう：
- コミュニケーションを改善するために、シックスシンキングハットのテクニックを検討してください。
- Retrospectiveに費やす時間を最大30分まで減らします。
- ふりかえりの間に提起された苦情が次の苦情の前に処理されることを確認してください。
デイリースクラム
デイリースクラムは、話をしたり、その日を計画したりする必要がないので、再び彼らにとって時間の無駄です。彼らは単に「私は昨日タスクXに取り組み、今日もそのタスクに取り組みます」と述べています。そして、ほとんどの場合、私はより厳しいものになるまで彼らは冗談を言っています。
ここで2つの問題があるように聞こえます。SCRUMミーティングが長すぎることと、計画とタスクの作成が面倒です。
どちらもスクラムミーティングは時間の無駄のように聞こえます。
SCRUMの長さ：
- 最大15分間お試しください。
- みんな立ち上がってみてください。
- 固定式：
- 昨日は何をしていましたか。
- 今日は何を計画していますか。
- チームメンバー（あなたではありません！）がタスクについて知っておくべきこと、それがチームにどのように影響するか。
- あなたがそれらに対処するつもりがないなら、障害を気にしないでください。
これは、あなたの計画があなたの状況を損なうことの2番目の証拠です-あなたが報告する特定のものを何も持っていない場合、それは通常、タスクが大きすぎ、あなたが言うことができるすべては、私がそれに取り組んでいたことを意味します。
- タスクを箇条書きに分類します。
- タスクが1日もかからないほど小さいことを確認します。理想的には、IMOのタスクは約3時間続き、約13 SPに相当する必要があるため、ほとんどの状況で1日2回実行できます。
チームとの取引
今日、私に常に反対している人は、「これは彼らがこのスプリントのためにコミットしたことだと言った」と言うのをやめるように言った、なぜなら彼の言葉では、「スプリントを完了することは決してない。次のスプリントで割り当てを埋めます。実際にはかんばんを使用しているので、それをやめます。」
彼は正しいです。あなたは間違っている。かんばんの粗雑なスクラムやバリエーションを行っています。彼らのせいではありません。
私は彼がこれを言う理由を理解しますが、彼とチームの他の誰もが気にしないので、彼がこれがそうであることに気づいていないようです。
まったく理解できないと思います。彼らは以前よりも思いやりが少ないかもしれませんが、彼らを非難することは何も改善しないだけでなく、状況を悪化させるだけかもしれません。それが岩の底だった場合、彼らは実際に掘り始めるかもしれません。
彼らは障害に対処するのではなく、単に機能します。
そしてここで私は仕事をすることが彼らの仕事のすべてであると思った。誰が障害に対処することになっていたのだろう……。スクラムマスター。それはyourの仕事です。彼らはあなたに何が悪いのかを教えてくれます。あなたはそれを修正します。その逆ではありません。
おそらくこれが、回顧展で多くの問題を抱えている理由です。
これらのミーティング中に冗談を言ったり、ジャークをぐるぐる回ったりすると、会社に多額の費用がかかることをどのように彼らに見せることができますか？
無駄な会議を止めれば、代わりにウォータークーラーの周りで冗談を言うでしょう。士気を向上させる暴力についての段落も参照してください。彼らが防御メカニズムとしてユーモアを使用している場合、あなたはいくつかの深刻な問題を抱えています！
冗談を言う-チームとの仕事のように。 （fuuuuuuckが会社のお金を気にしているのは誰ですか？あなたは今株主ですか？）
要約するには
あなたの悪い計画はSCRUMの他の部分を失敗させ、参加するすべての人が惨めです。彼らは何も変化せず、何も対処されておらず、彼らの不満は聞かれていません。
計画を改善すると、流れと士気が向上します。
障害を取り除く仕事をしてください。そうすれば、チームはより速く進歩します。彼らを助けるために何をすべきか彼らに彼らに尋ねなさい。
最も重要なこと：あなたの人々の言うことを聞いてください。彼らはすでにあなた（そして私）に何が問題なのかを話しました。
幸運を！
主要なアジャイルの原則の1つは、戻って、何が間違っていても修正することです。これには、コードのリファクタリングとバグ修正だけでなく、開発プロセスの修正も含まれます。
では、チームとミーティングをして、開発プロセスをどのように改善できるか見てみませんか？それが意味するなら、スクラムやスタンドアップミーティングはありません。
また、あなたは アジャイルマニフェスト ：「プロセスとツールに対する個人と相互作用」の原則の1つを破っています。
一方、反復的な開発が悪いとチームが考えている場合は、おそらくそれは間違っています。 1回のイテレーションで計画したすべてを完了しなくても問題ありません。いつでも次のイテレーションに移動できます。そのため、「含む必要がある」、「持つ必要がある」などのマークを付けます。新しい機能を提供している限り、問題はありません。
ほんの少しの怒り：私の以前の会社と現在の会社では、私たちはスタンドアップ会議をしましたが、それでもします。私の経験からすると、30分以上のステータスレポートミーティングになるたびに膨大な時間を浪費しており、ほとんどまたはまったく情報を提供していません。人々は彼らの問題について話しますが、正直言って私は気にしません。
私の前の会社では、彼らは賢く、スタンドアップでこの問題を認識し、人々が不平を言い始めた直後に彼らを止めました。
スクラムに関する非常に優れたビデオを見たい場合は、「 Robert C. Martin-The Land that Scrum Forgot 」を参照してください。
私が優先するように、私は引き継がれていくタスクを見てみます。目標を達成できないことは、非常に意気消沈します。コミットしすぎですか？分解する必要があるファットログはありますか？あなたのコントロールの外にボトルネックはありますか？ 「完了」の明確な定義はありますか？要件は明確ですか？開発者あたりの時間は妥当ですか（つまり、管理者、スタンドアップ、計画、回顧、キーボードブレーク、非プロジェクト作業を考慮に入れます）。
次に、機能していないものはすべて破棄します。価値のないプロセスは、時間の盗賊に過ぎません。スタンドアップは、焦点を合わせておらず、チームに価値を提供しない場合、膨大な時間を費やす可能性があります。時間は他の場所で過ごす方がよいでしょう。多すぎる場合は、チームを分割することも検討してください。
チームをやる気にさせているものを把握するようにしてください。過去を振り返り、さらに重要なことに、出力に基づいて行動します。成功を祝うだけでなく、失敗を見ることも同様に重要です。
最後に、いわばブランドに損害を与えた可能性がある前に行ったスクラムマスターのアプローチを評価することもできます。私は有毒なスクラムマスターの下で働いたことがあります。その前に、あなたがそれを知っていてもいなくても、発生したすべての問題がワークロードに追加されていました。最終結果：問題は無視され、全員がチームワークをほとんど使わずに自分の小さな領域で作業しました。
私の意見では、スプリントよりもスプリントを効果的に（少なくとも80％のストーリーを閉じるように）スプリントを閉じるようにすることは、1つの最も重要なことです。チームが一貫して欠けている場合は、見積もりを調整する必要があることを明確に示しています。
チームはこれを受け入れる必要がありますが、開発者が見積もりについてより現実的になるようにするのは非常に難しい場合があります-私は1年間スプリントを閉じなかったチーム（一貫してスプリントの50％未満しか閉じない）で作業しました、常に見積もられていて、すべての計画/回顧において、私はあなたの見積もりが悪かったと言っている唯一の声でした、あなたは愚かに過度に自信を持っています多分それよりも外交的にはそれが基本的な感情でした）-あなたがその立場にあるとき、私はあなたが実際にKonBonをやっているので、プロセスは時間の無駄だと言っているあなたのチームの殺害に完全に同意しますあなたがそれを何と呼ぶか。ある時点で、彼の意見は状況によって検証されます。その慣性を克服するのは難しいですが、それができない場合は、チームが成功することはないと思います。
ある時点で、物事をリセットする必要があります。システムを稼働させるためだけに、チームに見積もりを大幅に補正しなければなりません。チームが一貫してストーリーをクローズし始めると、アジャイルプロセスは主に常識であり、何らかの形でそれを具体化しないと生産性に害を及ぼすことを理解する必要があります。しかし、「コミットメント」と「スプリントの目標」が真剣に受け取られない限り、それらが一貫して達成されない場合に発生します。その場合、全体は偽物であり、チームの生産性のドレインになります。
大幅に異なるスプリント（見積もり、計画、コミットメントなどの観点から）で人々を引き込むことは困難です。そのチームでは、2つの要因により最終的にそれを達成しました。 1つはJIRAからデータを収集していて、「これには言い訳はありません。数字はずれています。常に一方向にずれています。修正する必要があります。言い訳をレトロにしたくありません。合計する数」-そしてもう1つは、私が最終的に次のように説明する、管理におけるより高い圧力からの圧力でした...「このプロセスのポイントは、開発のタイムラインを予測可能にすることです。それとは関係なく、良いスプリントは、私たちのボードが私たちが成し遂げることを正確に反映する必要があります。経営陣は、実際のアウトプットよりもコミットメントに関連して私たちの成功をより意識しています。すべてのスプリントの半分を何もせずに作業を完了しているように見える出力です。この時間からさらに削除された人々は、あなたが失敗しているのを見ているだけであり、レトロで行う言い訳は均一ではありません彼らの権限の何か、彼らはあなたが失敗するのを見るだけですg。」
結局、私たちのチームは牽引力を得て、物事はよりスムーズで低くなり始めました、そして、プロセスが実際に機能し始めると、私たちはさらに高い出力を持ち始めました。したがって、tl; dr-スプリントのクローズを比較的高い成功率で開始するために必要なことをすべて実行します。あなたがそうしていなければ、あなたのチームの呪いはスクラムに対する彼の抵抗を結果によって検証し続け、最終的にあなたのプロセスは実際には単なる偽りであり、みんなの時間の浪費であることは正しいでしょう。
スクラムマスターは、チームを指導し、より生産的になるように指導します。スクラムフレームワークはそこに到達するための強力なツールですが、スクラムフレームワーク自体が絶対に目標にならないようにする必要があります。それ以外の場合は Cargo Cult 。
Cargo Cultを3年間行っているようですが、人々はそれが恐ろしいプロジェクト管理方法論であることに気づきました。良い知らせはあなたは賢い人たちです、彼らはそれを正しく理解しています。残念ながら、社内の一部の人々はそれをスクラムと呼んでいますが、あなたは賢い人々を持っています、彼らはチームが何をしていないのかさえあなたに伝えましたスクラムと呼ばれる。
私たちはオーバーフローを新しいスプリントに移すだけで、とにかく作業を完了しないので、計画は時間の無駄です。
丁度。なぜわざわざ？答えを見つける必要があります。または、計画とスプリント自体を変更して、計画に意味を持たせる必要があります。それか、無意味なスプリント計画でみんなの時間を無駄にしないでください。優れたスプリント計画を実行するのは簡単なことではないため、スクラムマスタートレーニングを送るように会社に依頼することができます。
レトロスペクティブの間、他の人は黙っていて、私は毎回これに対処しなければなりません。
すべての回顧展で同じ問題に対処している場合、回顧展で発言することを人々が気にすることはもうありません（もう？）。それは時間の無駄です。あなたやチームがレトロスペクティブで提起された問題に何らかの形で対処できない限り、会議はチームの士気を低下させるだけです。回顧展で提起された問題に対処する必要があり、次の回顧展までに進展が見られるはずです。
デイリースクラムは、話をしたり、その日を計画したりする必要がないので、再び彼らにとって時間の無駄です。彼らは単に「私は昨日タスクXに取り組み、今日もそのタスクに取り組みます」と述べています。
確かに、同じタスクを何日も続けているのに、なぜみんなの時間を浪費するのでしょうか。彼らは絶対に正しいです、デイリースタンドアップは確かに無意味です。スタンドアップは、それぞれが半日以下で完了することができる多くのタスクでの緊密なコラボレーションを促進します。タスクをその方法で分解できない場合（スプリント計画が壊れているため、またはタスクが実際にスクラムに適合しないため）、5分間の毎日のスタンドアップミーティングを開催する意味はあまりありません（ 5分以内ですよね？）。
「スプリントを完了することは決してありません。タスクを移動し、次のスプリントで新しいタスクを取り込んで割り当てを埋めるだけです。実際にはカンバンを実行しているので、そのことをやめます。」
私は彼がこれを言う理由を理解しますが、彼とチームの他の誰もが気にしないので、彼がこれがそうであることに気づいていないようです。
いいえ、あなたは彼がこれを言う理由を絶対に理解していません。障害の根本的な原因-解決する必要がある-が間違っています。チームのプロジェクト管理慣行が悪いので、彼らは気にしません。 Cargo Cultを実行し、Cargo Cultをより難しくすることを気にしても、それがCargo Cultであることを止めることはありません。
これについて何ができますか？
彼らの懸念に耳を傾けます。繰り返しますが、あなたはそれに恵まれていますあなたは賢い人です。
彼らが障害を解決するのを手伝ってください。
そして、それだけです。チームにとって価値のあるものにするために、スプリントプランニング、デイリースクラム、レトロスペクティブを変更する方法を実験する必要があります。スクラムラベルを削除したい場合でも、同様の頻度で同じ目的でこれらの3つの会議を他のすべてで行うことができます。プロジェクト管理方法論があります。実験の方法（頻度、コンテンツ、会議の主催者、時間、期間など）については、驚くほど簡単です：チームに尋ねますあなたに彼らにあなたのアイデアを強制するようにさせるべきであるならば、彼らにあなたのアイデアを強制しないでください（彼らがいくつかに同意できると仮定します）。
あなたがコントロールを失うことを恐れているなら、事前にいくつかの境界を設定してください、例えば：
- 会議のラベルは変わりません。
- 会議は引き続き行われ、会議の頻度は2倍を超えて変化することはありません。
- 現在実験中であるため、変更は2つのスプリントの間しか持続せず、その後、古いパターンに戻ります（スプリント期間を2倍にする場合のあいまいさを避けるために、週単位で時間を与えることをお勧めします）。
誰もが アジャイルマニフェスト から同じ行を引用していると思います。私も同じことをします：「個人とプロセスとツール上の相互作用」。
SCRUMマスターがSCRUMを使用してジョブを実行したい場合は、ある個人が別の個人と対話するように、SCRUMにアプローチする必要があります。プロセスを改善する方法についてブレーンストーミングを開始します。たぶん、あなたはスクラムを好きになるように彼らを説得することができます。多分彼らはあなたに別のプロセスを使うように説得することができます。確認してみましょう！
チームは、現在のシステムが仕事をしていないことをすでに認識しているようです。あなたは彼らがそれが仕事をすることができると信じるように彼らを励ますことができますか？あなたはいくつかの例に言及します。常に漏れるようにスプリントをオーバーフィルしている場合は、停止します。それはあなたのスクラムチームです。彼らが過熱を止めるのを手伝ってください。少し余裕を持たせるために、管理を押し戻してください。 SCRUMを使って何が良いのかを確認してください。これを使用して、プロセスから価値を失っているほど激しく推進していることを経営陣に提示します。管理者がSCRUMをプロセスとして必要とする場合は、修正するために必要なスペースとエネルギーの構築を支援してもらいます。 SCRUMマスターとしてのあなたの仕事は、チームが生産的になることができるように問題を解決することです。
別の有用なアプローチは、古いプロセス内に新しいプロセスを生成することです。同じように役に立たない方法でSCRUMを実行し続けますが、スケジュールのほんの一部を切り離して、「このスケジュールのこの部分では、ツールを適切に使用する方法を理解するつもりです」と言います。そこに過度にコミットしないでください。メトリックを使用します。そこでのすべての会議に焦点を当てます。 「SCRUM」プロジェクトの残りの部分は、あなたとあなたのチームが「それを実行して他の人がそれを行うのを助けることによってソフトウェアを開発するより良い方法を発見する」間、管理を幸せに保つための盾として使用します。時間の経過とともに、重要なタスクをこのバケットに入れることが多くなり、古いバケットはゆっくりと死んでいきます。すぐに、あなたは活気のあるソフトウェア開発環境を手に入れました、そして誰も賢明ではありません。
またはそれらを混ぜて一致させます。私はアンチスクラムであるプログラムに取り組みました。クライアントは、プロセス中の任意の時点で新しいタスクを追加して、すぐに対応できるようにしたいと考えていました。 （これは実際にはまともな要求でした。彼らの仕事は非常に不安定で、しばしば迅速なサポートが必要でした...それは私たちが支払われたものです）。もちろん、「スプリントで約束したときにXが実行されない理由」の問題に対処する方法を理解する必要がありました。私たちのソリューションは、実際には2段階のプロセスを構築することでした。適切な優先順位付けのために、長期タスクがSCRUMに入れられました。短期間のタスクは、クライアントと開発者の間の緊密な相互作用に焦点を当てた自家製のプロセスに入れられました。クライアントはこの短期的なプロセスを使用して私たちをプッシュすることを歓迎されていましたが、そうすることはスプリントのタイムラインをプッシュすることを理解し、同時に彼らが引き起こしたスケジュールの問題を聞いて対処することなくリクエストを追加することは禁止されていました。結果？動いた。ほとんどのタスクは本来あるべきようにSCRUMプロセスに入れられ、緊急事態はそれらとシームレスに相互作用しました。 「お客様になりたい場合は、SCRUMストーリーに合わせて立ち上がってください。パートナーになりたい場合は、気軽に来て、日々のレベルでこの製品を機能させてください。 ！」
私が本当に知っているので、私はこれを言います。オーバースケジュール、優先度を設定できない、さらにアイテムを追加する意思があるが、リリース日を押し戻さないという経営幹部の問題があります。
以前は、このように機能する方法論は存在しないと言いましたが、今ではかんばんを見たことがあるので、それができると言いましたが、それはかんばんが気にする必要がないためです。オーバーコミットしても機能し続けます。結果が速くなることはありませんが、キュー内のバックアップを個人に配置することはできないため、管理の問題は管理にかかっています。フィードバックレポートには過負荷が表示されますが、これは正しいです。
スクラムマスターとショーの実行方法のこの変更のため
まあ、これはあなたの問題かもしれません。スクラムマスターはショーを運営するためにそこにいるわけではなく、プロジェクトリーダーではありません。彼は、すべての利害関係者がコミュニケーションを図り、業務が透明であることを確認するためにそこにいます。
私はチームがどこから来ているのかと思っています。スクラム（避けられないスクラムマスターを含む）が彼らに降ろされる前に、彼らは多かれ少なかれ自律的でしたか？なぜスクラムが最初に導入されたのですか？それは何を解決することになっていたのですか？
スクラムはガイダンスを提供することになっていますが、あなたのチームはそれが何らかの形で役に立たないことを彼らが経験していないことを明らかにしています。彼らはガイダンスを気にしません、彼らはそれを不適切な時間の無駄だと考えています。どうやら、少なくとも1人の意思決定者はとにかく彼らを導く必要があると考えています。 WHO？どうして？彼らはポイントを持っていますか？
これはソフトウェアに限らない問題です。
どのような職場環境でも、性格や能力が異なるさまざまな人がいます。たとえスクラムが完璧な方法であったとしても、彼らの性格と能力のためにスクラムに反対する人はまだいます。
開発者は合理的な方法で難しいタスクを処理します。これを行うことができるようにするために、各開発者は、スクラムのようなものへの嫌悪として現れるかもしれないそのようなことを処理する彼の方法を持っています。すべての開発者がまったく同じ方法でゼロからトレーニングされた場合、1つのパターンを使用する方がはるかに簡単ですが、それ以外の場合は開発者側または管理者側での調整が必要です。
さらに、独立した思想家（開発者やその他の専門家）は、自分の仕事であり、意見の衝突が起こりやすいため、方法を教えられるのを嫌います。スクラムは、論理的な思想家にとっては、意味のない儀式のように思えるかもしれません。
以下は問題がどこにあるかを示唆しているようですが、それが何であるかではありません。確かにこれ以上のものがあります。私は（経験から）、開発者が試みたが阻止されたとしか想定できません。開発者が何かを修正したいが、体系的なもの（管理、会社のポリシーなど）によってほぼ不可能になり、あきらめる場合が何度もありました。彼らは本当に気にしないのか、彼らが役に立たないと信じている何かをすることだけを気にしないのか（おそらく経験から）。
私は彼がこれを言う理由を理解しますが、彼とチームの他の誰もが気にしないので、彼がこれがそうであることに気づいていないようです。彼らは障害に対処するのではなく、単に機能します。彼らは障害について不満を述べますが、何もしません。そして私が彼らを助けようとするとき、彼らはそれをすくめるだけです。
彼らは、いまいましいことをしていましたが、過去2年間で、彼らの意欲は、多かれ少なかれ岩の底にまで減少しました。
これらのミーティング中に冗談を言ったり、ジャークをぐるぐる回ったりすると、会社に多額の費用がかかることをどのように彼らに見せることができますか？
何かが他の人に押し付けられている場合、その利点を納得させる方法を人に強制するのは人次第です。私は人に何かを強制することを本当に信じていませんが、どんな状況でも好きなように、みんなの声に耳を傾け、現在の環境で機能する方法を開発することをお勧めします。
あなたは多くの素晴らしい答えを得ました。役立つと思われるポイントがいくつかあります。
方法論の変更は難しい
「これが私たちのやり方です」という慣性の下で作業しているため、締め切りやビジネスニーズのプレッシャーに逆らっているため、ワークスペースではこれは大きな課題です。
チームが計画に費やす時間はより多くより少なく ;その計画はあなたの現在の時間は得意ではなく、改善する必要があるものです。問題は、新しいルールを口述するだけではそこに到達できないことです。新しいルールは、大きな助けになる前の新しい負担です。そして、それらが大きな価値をすぐに提供しない場合、あなたは協力よりも回避を得るでしょう。
このトピックについてはロイ・オセロベを強くお勧めします。彼は 会社での変更を計画して実行する方法 の簡単な概要を入手しており、- このビデオ でさらに深くトピックに触れています。
Osheroveの基本的な観察は、以下のすべての課題が満たされる必要があるということです：
個人の動機：なぜ誰かが特定の行動をすることを気にする必要があるのですか？
個人の能力：彼らは文字通りそれを行うことができますか？
社会的動機：この行動に対する仲間からの圧力がありますか？
社会的能力：周囲の人が私の行動をサポートし、助けが必要なときに助けてくれますか？
構造上の動機：良い\悪い行動に対する報酬\罰はありますか？
構造的能力：物理環境はこの動作をサポートしていますか？
タスクを分解する方法を学ぶ必要がある
あなたのチームは、「昨日はタスクXに取り組みましたが、今日もまた取り組みます」と感じており、タスクは1週間延期されているという意味で、彼らは正しいようです。
ここで本当に役立つのは、タスクを小さなコンポーネントに分解する方法を学ぶことです。あなたが探しているのは、「OK、あなたはタスクXに取り組んでいますが、タスクXで具体的に何をしているのですかtoday？」という質問に対する答えです。
いくつかの答えは：
- このクラスのレガシーコードを学習しています。
- 症状が（SYMPTOMS）であるバグを修正しています。
- これがしばらく時間がかかる進行中のバグである場合：「今日私が試してみるのは...（計画）」
- このインターフェースを変更する必要があります。
- テストを書いています。
- テストされていないコードを統合しています。
...などなど。 1日または1週間で実際に何ができるかを観察できることは、アジャイルの大きな利点の1つです。しかし、それは実際に必要なことを意味します準備ができたときにいつでも準備ができるモノリシックなタスクXではなく、個々の日の解像度を確認します。
完了と配信
一般的な問題の1つ（アジャイル、および一般的には職場の計画）は、締め切りが開発者ではなく管理者から来る傾向があることです。その期限は、実際に行われる作業とは切り離されている可能性があります。特に、できるだけ早く配信されることが望まれます。
問題は、「できるだけ早く」が非常に無秩序なプロセスであることです。それはコーナーを切ることを奨励します。 「迅速かつ汚い」コーディング;ガイドラインを無視する;自分の後片付けをしない。それは、「試してみて、機能するかどうかを確認します。機能する場合は、提供します。機能しない場合は、別の方法を試してください」という考え方を奨励します。
一方、あなたがが系統的に作業している場合、計画とテストなどについて厳密である場合は、一連の標識とセーフティネットを設定しています。 長くかかるかもしれません-あなたは即時配信を促進しないものに多くの時間を費やしています、そしてあなたはこの種のワークフローがあまり得意ではないかもしれませんまだ-それははるかに少ない揮発性になります。
ですから、自問するべきことの1つは、開発者が実際に目にするニーズや必要性に応じて、スプリントの目標を設定することですか？それとも、management期限を設定して、開発者がコミットメントをスプリントのようなスケジュールに組み込もうとしているのでしょうか？
開発者が物事を計画する時間を与えられていない、または信頼できる計画に従って作業していない場合、開発者が役立つ見積もりを作成できないことは不思議ではありません。 :)
スクラムには弱点がないわけではありません。もちろん自分で話すこともできますが、開発者は正当な理由でそれを嫌っていると思います。 それを試みてはならないというのが私の正直な意見です。
理由を理解するには、 すべてのスクラムマスターがスクラムについて知っておくべきこと を読んでください。それは私が書いたものではありませんが、そこにあるすべては私の経験の代表であり、私はsheer terrorとしてのみ要約できます。
私の場合、私は特にポイント5で苦しみました。基本的に、スクラムは私を子供であり、敗者として扱いました。今、私は同僚を助けるための機知に富んだ共同開発者です...私が何を好むのか不思議ではありません！
私は今、新しい（スクラムではない）上司を持っています。それはただ歩き回り、人々に話しかけるだけです。そして私はそうですとても感謝しています！これが機能する理由の1つは、開発者間のコミュニケーションのためのチャットルーム（ほとんどの場合、私たちが使用）もあることです。誰かが議題を持っている場合、私たちはそこにそれを取ります。会議は、アドホックな開発者向けのディスカッションのためだけのものであり、人為的な毎日の締め切りを課すためのものではありません。