開発者が「毎日のスクラム」を好まない理由と理由は何ですか？
毎日のスクラムを保持することには、次のような利点があります。
- チームは互いに調整されます
- 誰もがどれだけの量のタスクが実行されたかを知っています
- バーンダウンチャートがますます完全に
- タスクボードを更新しました
- それはそれほど長くは続きません、15分は誰も殺しません
しかし、最近（スクラムの実装と使用から6か月後）、開発者はもはやスクラムを毎日あまり好まないように感じています。人々は十分に説明せずにタスクボードを更新するだけで、飽きているようです。なんらかの理由で私たちがそれを保持しないと、彼らは一種の非常に幸せになることがわかります。
私はこれで何が悪いのかわからないだけです。 「デイリースクラム」がチームにもたらす不利な点について、どこかに言及されている理由はありますか？開発者が毎日のスクラムに飽きる理由は何でしょうか？
私はいくつかの雇用主のいる「スクラム」チームに参加した経験がありました。マネージャーは「毎日のスクラムミーティング」をSCRUMの主要なポイントとして取り上げ、それを目的として設定するのではなく、目標として設定しているように見えます。より効果的な開発サイクルを達成するための手段。
15分の会議がすぐに45分の会議になりました。人々は他の人の話を聞くのではなく、あくびをして「いつ行けますか」と考えるのに忙しいため、更新は効果がなく、人々の慣例も壊してしまいました（私は、たとえば、フクロウの人であり、毎日午前9時にこの愚かな会議に出向くのは、私が仕事を辞める十分な理由です。
マネージャーが正しく適用されれば良いかもしれないアイデアを取り入れ、それを極端にすると、期待した結果とは正反対の結果が得られます。私個人的に参加する会議が多ければ多いほど、私が行う作業は少なくなると思います。私のカレンダーでは週に2回の定例会議があり、通常はそのうちの1つをスキップします。ミーティングはマネージャー向けであり、開発者に仕事を任せます。
きっと「でも素晴らしい」と言うSCRUM愛好家はたくさんいると思います。まあ、それを保存して、すべて聞いたことがあります。
それに価値がないと感じたら、毎日のスタンドアップは退屈で役に立たないでしょう。毎日のスタンドアップのユーティリティを減らすことができるいくつかのものがあります。
- 共有されている情報が、決して関係することも、影響を受けることもありません。
- チームの所有権がなく、全員が常に自分のプロジェクトに取り組んでいる。
- スタンドアップの外でのチームコミュニケーションの欠如。
- 目に見える、または伝達される進歩の欠如。
- 共有する情報がない。
これらは私の頭の上にありますが、常により多くの考えられる理由があります。
おそらく、開発者に、なぜ彼らが興味を示さないように見えるのかを直接尋ねるべきでしょうか？あなたがより/より良いコミュニケーションを望むなら、それはあなたから始めるべきです。
毎日のSCRUMミーティングで発生する問題の一部：
- 長持ちするもの。彼らがこの種の問題の根本的な原因であるので、あなたはそれらに毎日マネージャーの人を欲しがりません。彼らが通常どのように椅子を使用するのかを見てください（そうです、それらのために立ち上がる必要があるのは人々が速くなるように誘惑することです）
- 関係者と話し合うために後で別の実際の会議をスケジュールすることを決定するのではなく、彼が長い間抱えている孤立した問題について説明している誰か（または2人または3人の開発者）について聞く必要がある
- 愚かな時間。これらの会議は午前中である必要はありません。昨日やったことについて話したり、今日何をするかを決めたりするのではありません。あなたは最後の毎日とこれまでの間に何をしたかについて話し、次のものまで何をするかを決定しています。
- 開発者のためのアプリの所有権の欠如。 SCRUMは、開発者がコードモンキーとして扱われない場合に機能します。プロセスがうまくいかない最初の兆候は、開発者が何かが完了するまでにかかる時間を評価していない場合です。
- 再び愚かな時間。チームの一部が何かに取り組み始めており、毎日が起こったときに「ゾーン内」にいる場合、それは面倒になります。それらを毎日持つのに適した時間は、誰も作業してはならないときです（たとえば、昼食後、または昼食中に行ういくつかのディスカッションを開始する直前）。
タイミングは多くの人にとってキラーです。プログラマーは遅くコードを書き、遅く眠り、朝のラッシュの後にやってきます。決まった時間にオフィスにいなければならない-彼らには早すぎる。そして、もっと早く来てすでに仕事を始めるかもしれない他の人には遅すぎます。
Flowは別の問題です。いくつかの機能を備えた流れのプログラマーは、夜遅くまで働き、家に帰って、再充電され、続行する準備ができています。ほとんど関係のない問題について会議に出席する必要があると、彼の気が散ることがあります。
私の観察では、これらの会議は、マネージャーがチームやプロジェクトに役立つのではなく、実際に何かをしているように見えたり感じたりするためのものです。
たとえば、チームは、さまざまなプロジェクトで一連の短いバグ修正を行うよう割り当てられています。彼らは実際にはチームとしてではなく、個人として働いています。ただし、会社/部門のポリシーで義務付けられているため、チームリーダー/マネージャーは、とにかく毎日スクラムミーティングを開催します。達成されることは、役に立たない会議のために15分以上かかり、会議の前後に15〜30分の注意散漫と生産性の欠如に取り組むことです。
さて、締め切りが厳しく、さまざまな作品に取り組んでいる人々の間で多くの調整が必要なプロジェクトでスクラムがうまく機能しているのを見ました。その意味でそれは素晴らしいシステムでした。しかし、「私たちはスクラム/アジャイルショップなので会議を行っているのですが、それは私たちがやろうとしていることです」というのは本当にうんざりです。
誰も会議を独占していないことを確認してください。
4人の開発者が5分で邪魔にならないようにし、次の10分がamazing、すごい彼が作った新しい開発、それらのほとんどは彼が思っているほど驚くべきものでも驚くべきものでもないので、人々はすぐに飽きてしまいます。
少し立ち戻って、チームについて考えてみましょう。
- 彼らは効果的に働いていますか？
- タスクは時間どおりに完了していますか？
- コードは堅牢で適切に記述されていますか？
- チームは、亀裂から抜け落ちるものがないことを確認していますか？
- チームは、作業を複製したり、お互いのつま先を踏んだりしないように調整しますか？
これらすべてに対する答えが「はい」の場合、おそらく、毎日のミーティング、バーンダウンチャート、タスクボードなどの忙しい仕事をチームに強制したい理由を検討する必要があります。それはどんな価値を追加しますか？あなただけの楽しみのために官僚的なデータを生成したいですか、それともチームの生産性を高めようとしていますか？
毎日のスクラムが停止してから生産性が低下しましたか、それともすべてが以前と同じように進んでいますか？何も変わっていないのに、なぜ会議を続けるのですか？
15分。その15分（および準備のための時間）は、チームメンバー間で十分かつ新しく有用な情報を伝え、翌日のチームの生産性を15分以上向上させますか？毎日、それほど多くの有用なスクラムコンテンツがない場合、チームメンバーは、この会議をできるだけ早く終了して仕事に戻ると、目標に向けてはるかに進歩すると考えているでしょう。
ボードとチャートを頻繁に更新したい場合は、ドラフトコピーをwikiに入れてください。
Retrospectiveミーティングを開催して「うまくいったこと」と「うまくいかなかったこと」を確認し、開発者が毎日のスタンドアップミーティング自体を時間の無駄として挙げているかどうかを確認することをお勧めします。次に、少し再編成する必要があります。
私の個人的な経験：
- 目的は、今日何をしているか、昨日どこにいたかを知ることです。議題にこだわるのではなく、2人と他の15人の間のブロッカーの技術的な議論に退屈します。問題を特定し、外部で話し合う
- 人々は時間通りに会議室に入ることはありません、そしてこれは意図的に誰かによって行われるサイクルになります。したがって、スクラムマスターは、会議の外で彼らと静かに話し合い、予定どおりに開始および終了するようにする必要があります。
- 私たちはすでにスクラムミーティング以外でバーンダウンチャートを更新しているので、それは毎日のスタンドアップの主な目的ではありません。
抵抗は次の場合に発生します。1）午前9時に人々を急いで押し込むために使用されます。電車が遅れる時はストレスになる。 2）スクラムのリーダーシップが悪い。リーダーは、人々に彼らに影響を与えない何かを聞いて周りに立っているのではなく、物をオフラインにするように人々に言っているべきです。 3）価値のないコンテンツ。これもスクラムリーダーシップの問題です。これは、ボトルネック、軌道の問題、潜在的なコラボレーションに対処するためのフォーラムになるはずです。実際に起こるのは、誰もがその日に作業することを期待していることを言うだけであり、それは他の誰にとっても役に立たない、または興味がないものです。 4）立っている。私は立って立つつもりはありません。立っていることの論理は、それが人々に簡潔になることを奨励することでした。人々は実際に関係なくただガタガタ音を立てます。
率直に言って、私が行った毎日のスクラムミーティングの99％で、ほとんどすべてのディスカッション/質問/回答は、数通のメールで修正できたはずです。
正直なところ、会議を開かないためには、もっと正当な理由を示す必要があると思います。全員を直接対面で部屋に集めるときは、それが正当な理由であり、時間効率を最大化するように編成されている環境を構築します。
会議は一般的に嫌いです。ビデオ会議、電話、電子メールなど、生産性の流れを妨げずに仕事に取り掛かることができるものなら何でも使いたいと思います。
個人的には、8時間に4回を超える会議があった場合、プロジェクトはうまく管理されていないと思います。
会議をめぐる緊張に寄与する要素はたくさんあります。会議があなたに価値があるよりもあなたにコストをかけるかもしれない重要な理由のいくつかとしてこれらを考慮してください：
- フォーカス-ソフトウェアと会議
- 管理-マネージャーは測定が必要
- 性格-内向的対外向的
- 時間-割り込み、メーカー、マネージャーの時間
- 目標、優先順位
これらの各要素について以下で説明します。
Focus-私はソフトウェアの開発を楽しんでいます。これには、課題（問題）についての考え、ソリューションの作成、ソフトウェアの構築、そして、会議は、ソフトウェアを構築するタスクへの集中を妨げます。 「Flow」と呼ばれる状態があり、開発者はチャレンジ（問題）に没頭し、ソリューションのメンタルモデルを構築し、完了しています。ソリューションの構築に焦点を当てます。開発者は、真夜中まで作業し、食事と睡眠のみを行い、その後、彼らが去った場所に近い状態に戻ることができます。
開発者は気晴らしを避ける必要があり、多くの人は夜遅くまでコードを書くことに利点があることを発見します（彼らはノイズ、電話、忙しいオフィス、そして開発者以外の同僚による作業の中断を避けます）。そして、あなたが10時、11時、または12時まで仕事をしたとき、後で仕事に来ることは不合理ではありません（10、11、正午？）。開発者が午前9時から真夜中まで働くことを期待するのは理にかなっていますか？
スクラム（およびその他の）ミーティングは、開発者の主な目的（ソフトウェアの構築）から注意をそらします。
管理-マネージャーは成功するために測定する必要があるため、スケジュール、成果物、タイムライン、優先度、および進捗状況を測定および報告し、依存関係、遅延、およびリスク領域を明らかにするための会議。スクラムの課題は、マネージャーにはこれらのものが必要だが、開発者は集中する必要があるということです。ミーティングはマネージャーにサービスを提供し、マネージャーがステータスと進行状況を取得、測定、追跡する方法を提供しますが、ミーティングが開発者に役立つことはめったにありません。管理者は、注意散漫に対処し、障壁を取り除き、開発者がソフトウェアの構築に集中できるようになると、より多くの価値を提供することを考慮してください。
会議の必要性に対する解決策があります。管理者は、開発者を訪問し、ステータスレポートを要求し、中断の少ないときのためのプロトコルを採用するか、または開発者が中断可能である場合に進捗を通知するポリシーを採用することができます。これが重要な理由については、時間の説明を参照してください。
Personality-一部の人々は内向的であり、他の人は外向的であると考えてください。外向性愛好家は社会的交流を楽しみ、彼らによって再充電されます。内向的な人はマネージャーとして成功することができますが、マネージャーは通常外向的な人です（外向的な人は通常、ソーシャルインタラクションに優れているため）。内向的な人はソーシャルインタラクションで楽しむことができ、エクセルさえもできますが、孤独によって再充電されます。開発者は多くの場合内向的であり、ソーシャルインタラクションを「必要としない」ため、単独で（または小さなチームで）成功します。彼らは問題に一人で取り組むことで幸せになることができます（外向的な人も開発者になることができます）。毎日のスクラムミーティングは社交的な集まりになり、外向的な人には適していますが、内向的な人にはあまり適していません。
時間-開発者は、会議中はコードを記述できません。会議に気を取られている間、彼らは（ブレインストーミングをしている場合を除いて）難しい問題について考えることもできません。開発者は、ソフトウェアの構築に集中するために、途切れることのない大きな時間ブロックを必要とします。会議は、彼らの努力の邪魔になる中断です。何時間も問題の解決に没頭し、ほぼ完了し、誰かが「スクラムの時間」と言ったとき、あなたは中断され、おそらく「ギアをシフト」している間に何時間もの作業を失います。または、午後11時まで仕事に留まり、仕事を辞め、家に帰り、問題に寝つき、目を覚まし、問題を解決する準備ができて仕事に戻り、1時間問題に取り組んだ後で中断された。 「スクラムの時間」です。
Paul Grahamは、Maker TimeとManager Timeに関する優れた記事を持っています。これは、この問題を私よりはるかによく説明しています。計画されているかどうかに関係なく、会議の中断によりフローが中断され、開発者がメーカーの時間からマネージャーの時間に強制される可能性があると言うだけで十分です。私を信じて、あなたはメーカーの時間に開発者を求めています。
目標、優先度-開発者とマネージャーは、異なる目標と優先度を持っています。マネージャーは、スケジュールを追跡し、コストを最小限に抑え、レポートが責任を持って実行されるようにする責任があります。開発者は、課題/問題に対処するソフトウェアを構築することを目標としています。これらの目標は対立していませんが、緊張を生み出しているのはコミュニケーションのメカニズムです。ミーティングはマネージャーのニーズに対応し、マネージャーの時間を最適化しますが、開発者のニーズと矛盾します。スクラム会議は、会議の最初のルールを破棄し、「議題を持っている」ため、より多くの放浪傾向があります。また、会議はコミュニケーションを最適化するために使用されます（マネージャー向け）が、開発者の時間（中断、フローの喪失など）がかかります。
目標は何ですか？制約が（品質、時間、コスト、プロセス）である一方で、ニーズに迅速かつ品質で取り組むソフトウェアを構築すること。スクラムおよびその他のアジャイル手法はプロセスの制約を認識し、その要因を最小限に抑えようとしますが、それらはその制約を最小限に抑えるため成功しています。しかし、会議の追加には時間がかかり、中断によって開発者は会議の期間よりもはるかにコストがかかります。
私は何度もスクラムチームを管理し、その一部でした。開発者がスクラムを好まない主な理由は次のとおりです。
- 非常に貧弱なスクラムマスターによって実行されるため、45分になった場合、スクラムマスターはスクラムの制御を改善する必要があります。
- 彼らがそれを好まない最大かつはるかに最も正直な理由は、悪い労働倫理に隠れることが非常に難しいためです。私が一緒に働いたいくつかの開発者は衝撃的で、彼らは30分の仕事であるべきタスクを行うのに何日もかかります。良いPMは開発者の障壁を取り除くはずです。つまり、スプリントでタスクをすり抜けることができるはずです。開発者は毎日立ち上がって進行状況を示す必要があるので、それを好まないでしょう。正当な問題が原因である場合、優れたスクラムマスターはその問題をできるだけ早く解決する必要があります。
問題は、スクラムマスターがブロッキングの問題を解決する権限、スキル、または能力を持っていない場合に発生します。実際、私はいくつかの埋葬問題がそれらがなくなることを期待して見たことがあります。これは悲惨です。
会議を変更して、メリットが得られるようにします。
- 都合のよい時間にスケジュールしてください。誰もがメールを確認して会議の考えを整理できるように、仕事の開始から30分後にはどうでしょう。簡潔にするためには計画が必要です。準備ができていない人は永遠に争うことができます。
- 会議中に問題が伝えられた場合に回避できたはずの問題を特定します。誰もが要点を理解する必要があります。
- 全員の入力を最小限に抑えるために必要なことは何でもしてください。議論の場ではありません。話し合いが必要なトピックに焦点を当てた毎日の会議の外で、個人的に会議をスケジュールするように人々を奨励します。ルール：一度に話すのは1人だけです。
すべての苦情者は、彼らが問題に貢献していないことを確認する必要があります。毎日のスクラムの目標をそれほど苦痛なく達成することができれば、ぜひ聞いてください。