アジャイルの8つの良くないパターンとその対処法

しかし、"アジャイルであること"（中心的な価値観や原則を実践していること）と " アジャイルを実践していること"（形式的な規定には従っているが、正しい考え方を持っていないこと）には大きな違いがある。チームは表面的にはアジャイルに見えるかもしれないが、実際には非常にウォーターフォール的であり、効率的ではない。この記事では、よくある良くないパターンと、それを特定し対処する方法を取り上げたい。

これは、新しいチームが（特に大きな組織で）アジャイルに切り替えたときによく起こる問題である。彼らはスプリントをやり始めるが、各スプリントの対象範囲はあらかじめ決められており、柔軟性がない。

問題点

計画にゆとりがないため、チームは仮説を検証し、経験から学び、環境の変化に適応する能力を失う。ウォーターフォールのデメリットをすべて経験し、その上にアジャイルの方式を加えても、不満が募るばかりだ。

対策

計画方法を変更しましょう - 全体像を見据えることは重要ですが、製品や顧客についてまだすべてを知っているわけではないことを受け入れ、より多くを学ぶにつれてアプローチを変更する必要があることを理解する必要があります。ロードマップ計画を立てることは良いですが、各スプリントの納品物ではなく、全体像と製品の成果に焦点を当てましょう。

私はある日本企業でこれに遭遇したことがあるが、彼らは自分たち独自のフレームワークだと自負していた。実際には、多くの形態とバリエーションが存在し、良いことではありません。
このアイデアは、いくつかのチームが平行して同じ製品に取り組み、スプリントのリズムに従っています。一つのチームがデザインを担当し、別のチームが開発を行います（例えば、フロントエンド、バックエンド、QAのチームがある場合もあります）。スプリント5では、デザインチームが新しいデザインを開発し、フロントエンドはスプリント4からのデザインに基づいて構築し、バックエンドはスプリント4のフロントエンドコード（それはスプリント3でデザインされたもの）で作業し、QAはスプリント4の開発チームの出力（それはスプリント2でデザインされたもの）をチェックします！

問題点

ここではすべてが間違っています。例からわかるように、最終製品を届けるまでに少なくとも4つのスプリントが必要です（各作業項目がデザイン、フロントエンド、バックエンド、QAを通過する必要があるため）。実験の余地がありません - 多くのチームが関与している場合、誰が実験を行いますか？どのチームも最終製品に対する責任を持たず（デザイナーは常に自分のデザインが誤解されたと言い、エンジニアは自分のコードが完璧だが、製品がうまく機能しないのはデザインのせいだと主張する可能性があります）、これは非常に悪いアプローチであり、アジャイルとは何の関係もありません。

対策

最初から最後まで製品の責任を持つ部門横断チームを立ち上げる。例えば、あるチームは製品検索の責任者にし、別のチームはショッピングカートの責任者にするなどですが、各チームが独自に価値を提供し、実験し、迅速に行動できるようにする必要があります。

私は時々、アジャイルコーチやスクラムマスターが「唯一正しい方法」について何時間も語るのに出会います。しかし、アジャイルで物事を行う「唯一正しい方法」は決して存在しません。アジャイルについてアジャイルである必要があります - 実験し、失敗から学び、検査し、調整します。

問題点

場合によっては、アジャイルの最良の実践でさえ特定の状況で機能しないことがあります。製品がユニークであったり、チームが珍しい問題を抱えていたり、作業スタイルが型破りであったり - その理由はたくさん考えられます。スクラムに固執し、それ以外のものを受け入れないのであれば、うまくいかないプロセスを強化し続けることになります。チームはやる気を失い、生産性は低下し、業績はますます悪化し、組織全体が苦しむことになります。

対策

振り返りを行います。振り返りを行い、うまくいくもの、うまくいかないものについてオープンで率直な議論を行い、既存のプロセスを変更する方法を探ります。もちろん、最良の実践に従うことは常に良いことですが、それらに過度に固執することなく、新しい解決策を試し、チームにとって最適なものを見つけ出しましょう。

よく耳にするのは、「カンバンボードがあるのでカンバンフレームワークを採用している」という話です。しかし、それだけでは不十分です。カンバンフレームワークを採用していると言えるのは、ボードを持つだけでなく、進行中の作業項目を制限し、サイクルタイムを測定し、作業をプッシュするのではなくプルし、日々の作業に連続的改善のベストプラクティスを適用している場合です。

問題点

カンバンボードを使用してもウォーターフォール方式での作業が可能であり、それがアジャイルであるとは限りません。適切に実装されたカンバンフレームワークは、アジャイルの基本原則と考え方を適用するのに役立ちます。最初から最後までの責任を確保し（人々が自分の作業セクションだけでなく、全体の進捗に配慮する）、独立した作業項目をワークフローを通じて移動させることにより、段階的な製品開発を保証します。最終的に、継続的な改善を達成します。

対策

カンバンフレームワークについて学び、ボードだけでは十分ではないことを覚えておきましょう。

多くの組織、特に移行期には、多くの組織が「チームマネージャー」の役割を維持するか、プロダクトオーナーの役割と組み合わせています。チームマネージャーのいるチームはアジャイルになれるのでしょうか？私は、いくつかのまあまあのケースを見たことがありますが、多くの場合、それは大失敗のもとです。

問題点

チーム内に正式な権威者が存在すれば、全員がその権威者を頼りに決断を下し、チームに指示を出すことになります。もちろん、優れたマネージャーはいつ後退すべきかを知り、心理的安全を作り出すことができるかもしれませんが、一般的にはチームメンバーは意見を共有したり、優先順位に疑問を投げかけたりすることを躊躇します。

対策

これはやっかいなことで、必ずしも簡単に実行できるわけではありません。なぜなら組織改革が必要になるからです。私たちが達成したい理想は、管理職のいない（プロダクトオーナーは管理職ではありません！）部門横断的なチームで、目標について決定し、目標達成に向けて協力し合うことです。組織改革が不可能な場合は、正式な管理職を対象に奉仕型リーダーシップのアプローチをトレーニングすることが有効かもしれません。

伝統的なプロジェクト管理では、時間ベースの見積もり（工数、工数日など）がいまだに頻繁に使用されており、ほとんどの場合、チームがアジャイルの潜在能力をフルに発揮するのを妨げています。

問題点

時間ベースの見積もりは、すべての作業を事前に割り当てておく必要があり（これはしばしば分裂を引き起こします）、価値を提供する以上の問題を引き起こしながら多くの時間を要します。不確実性をどのように評価しますか？見積もりに3日余分に追加して最善を祈りますか？1日1時間、15日間作業が必要な作業をどのように見積もりますか？15時間とすると、間違ったタイムラインになるリスクがありますが、15日とすると、必要なリソースを過大評価することになります。

対策

まず、そもそもどのような作業見積もりが必要かを特定します。バックログ項目が大体同じサイズであれば、チームが週に完了する項目の数で速度を見積もり、この情報を使用して将来の予測を行います。それ以外の場合は、Tシャツサイズやストーリーポイントの見積もりを探求します；時間ベースの見積もりは最後の手段とすべきです。

多くの場合、誰か他の人（通常は指導者）が彼らに代わって目標を設定します。チームが惰性に従って、いつもやっていることをやっている場合にも起こります。この場合、彼らは計画はするかもしれません（私たちが成し遂げたいこと）が、目標設定（私たちが到達したい場所とその理由）はしません。

問題点

チームが目標を設定しない場合、製品パフォーマンスの責任を持たず、製品の成功にコミットしていないことも意味します。これは大きな問題です。

対策

最初にビジョンを描く。チームがターゲット顧客、そのニーズと問題を特定し、それらの問題にどのように対処したいか、何が彼らをユニークにするかを決定するワークショップを行います。次に、このビジョンをロードマップと一連の目標と重要結果に変換します。最後に、バックログを見直して、そこにある作業項目がビジョンとOKRと一致していることを確認します。

これは私の嫌いなところであり、日本では非常に一般的なことです。人々は、どれだけ働いたか（労働時間、書かれたコードの行数、作成されたパワーポイントページの数など）によって評価されますが、成果によってではありません。多くの日本企業では、9時から5時までしかオフィスにおらず、残業をしない場合には昇進が難しいです。同時に、典型的な日本のオフィスを夜9時に歩いてみると、デスクで寝ている人々、おしゃべりしている人々、ファックスされたエクセルスプレッドシートをスキャンしてWord文書に挿入し、それをファックスで送る（実話です）人々や、過去2時間で同じpptページ上のボックスを15回再配置している人々を見るでしょう。私が間違っているとは言いません、もちろん実際の仕事をしている人々がいますし、通常、すべての従業員は一生懸命働いています。問題は、焦点が問題を解決し、ビジネスの成果を達成するのではなく、「一生懸命働く」と「たくさん働く」にあることです。

問題点

これは説明するまでもないだろうと思います。もし働いた時間数で判断されるなら、最も非効率的で時間のかかる解決策を見つけるインセンティブが働くでしょう。問題を解決することに重点を置くのであれば、（家族と過ごす時間を確保し、ボーナスももらえるように）効率よく終わらせることにインセンティブが働くでしょう。

対策

決してアウトプットベースの目標を設定しないでください（例：x数のキャンペーンを立ち上げる、xストーリーポイントを完了する、x行のコードを書くなど）。すべての目標は成果指向であるべきです（例：売上をx％増加させる、NPSをxポイント達成する、SLAを99％達成するなど）。