初心者のアジャイル チームによる失敗トップ 10

初心者のアジャイル チームが犯す可能性のある、最もよくある 10 の誤りを以下にまとめました。ここで提案されている改善方法は、当社のサポート、ユーザ ラーニング、およびアジャイルに移行するチームを何年も指導してきたコーチング チームから直接提供されました。アジャイルと CA Agile Central を初めて利用する場合や、単に復習が必要である場合は、以下のリストのアイテムを選択してトピックに直接ジャンプしてください。

  1. 懸念
  2. 不十分なコミュニケーション
  3. 不十分なチーム構成
  4. 不十分な見積もり
  5. 不十分な計画
  6. 不十分なテスト
  7. 顧客からのフィードバックの無視
  8. チーム エンパワーメントの欠如
  9. 振り返りミーティングとデモ ミーティングの欠如
  10. 従業員の抵抗への対処計画なし

1. 懸念

懸念はさまざまな形で現れる強い感情です。懸念が不適切な意思決定や作業方法につながり、初心者のアジャイル チームが不満を抱くことがあります。懸念を打ち消すのは信頼です。すべてのレベルに信頼感を浸透させることによって、懸念を払拭してください。チームが適切なコミットメントと意思決定を行うであろうと組織が信じていることをチームに知らせることから始めます。チームは、管理者から指示を受けるのではなく、グループとして学習し、成長して、選択できることを信じてもらう必要があります。

懸念がチームの成長を抑圧する例としてよく見られるのが、コミットメントの問題です。チームは失敗のために責任を負ったり非難されたりすることを恐れて、過小なコミットメントや過大な見積もりを行うことがよくあります。初めのうちは、チームによる見積もりの誤りを許容してください。チームが責任を追及するのではなく、誤りの原因を調査できるように、信頼環境を醸成します。これにより、ベロシティの本当の上限を把握することができます。1 つの誤りは、その後の多くの成功につながります。

2. 不十分なコミュニケーション

チーム メンバがお互いに毎日定期的に会話していない場合は、問題が将来生じる可能性があります。最も詳細なドキュメントがあるとしても、問題と障害を発見する最善の方法は対面のコミュニケーションです。すべてのチーム メンバが互いに近距離で作業できる専用のチーム エリアをセットアップして、コラボレーションを促進してください。ビデオ会議とインスタント メッセンジャ ソフトウェアを使用して、グローバル チーム用の仮想領域を作成します。CA Agile Central では、通知ダッシュボード パネル、およびディスカッションを利用して、チームのコミュニケーションを強化することができます。

スタンドアップ ミーティングを毎日開催します。すべてのチーム メンバの間の簡単な対面式のミーティングでは、昨日どのような作業が発生したのか、今日どのような作業が計画されているのか、そしてどのような問題によって作業が進まないのかを皆に知らせます。共有する情報に関しては、数よりも質を重視します。チーム メンバはミーティング中に立っているので、ディスカッションが無駄に長くなると、苦痛を感じるようになります。スタンドアップで問題を解決する誘惑に負けないでください。障害問題の詳細については、後でスクラム マスタが個人と話し合うようにしてください。

3. 不十分なチーム構成

優秀なアジャイル チームに共通する 2 つの特徴は、機能横断型と安定です。

真に機能横断的なチームはユーザ ストーリーを完了させるのに必要なあらゆるスキルを持ちます。たとえば、「完了」のチーム定義に、完全に文書化されたコードが含まれている場合は、テクニカル ライタをチームの構成に含めてください。コードの質が高いことを確認するために、テスターも含めてください。チームは、スコープを正しく見積もることができるように、ユーザ ストーリーを広い視野から見る必要があります。

安定とは、チーム メンバは共に成長する時間を持っていることを意味します。1 か月、四半期、さらに 1 年単位でチームを維持してみてください。1 つのプロジェクトが終わり、別のプロジェクトが始まるときに、チームを維持することを検討してください。さまざまなロールが共に学習することは、チーム メンバにとって有益です。チーム メンバが全員のスキルを理解するようになると、お互いに競って正確な見積もりを出すことができるようになります。これらの成熟したチームでは、ベロシティが正確に定義されているので、プロダクト オーナーと関係者の予測精度が高くなります。

4. 不十分な見積もりの慣習

新しい作業のサイズとスコープの見積もりは、特に新しいチームにとっては、難しくなることがあります。そこで諦めずにがんばってください。時間が経つにつれて、見積もりは容易になります。チームは初期ベロシティを把握するために 2 ~ 3 の初期スプリントが必要であることを管理者に知らせてください。チームがどのくらいの速さで作業を完了できるのかを把握するまで、機能セットの推定期限を受け入れないでください。

チームによっては、ユーザ ストーリーのポイントを実際の作業時間に関連付けることがあります。この過ちを避けるようにしてください。T シャツのサイズ、色、またはポイントなどの抽象的な値を使用して、新しい作業のサイズを表します。これが重要です。抽象化することで、個人の可用性ではなく、ストーリーの複雑さを追跡することができます。ポイント見積もりは、チーム全体の能力を反映します。ユーザ ストーリーがイテレーションにサイジングおよびコミットされると、個々のキャパシティは時間単位のタスク見積もりの形式で実行されます。

5. 不十分な計画の慣習

ウォーターフォールやその他の方法と比べて、アジャイルでは計画がほとんどない、あるいはまったくないと思っている人がいるかもしれません。実際には、アジャイルの方が計画が多いのです。アジャイルがほかの方法と異なるのは、この重要なアクションが開発サイクルの冒頭で終わらせる 1 回限りのイベントではなく、継続するという点です。これはさまざまなレベルの複雑さと粒度で実行される継続的なプロセスであると考えてください。成功するには、利用可能な時間の 20% を計画に費やすことを見積もってコミットします。

バックログの改善、毎日のスタンドアップ、イテレーション計画、リリース計画ミーティングをスケジュールします。これらのミーティングを一定の間隔で設定してください。これにより、チーム メンバは「マッスル メモリ」を鍛えて、次のタイムボックスの計画の質を向上させることができます。チームが 1 ~ 2 回先のイテレーションを見通すように計画サイクルを構築します。

6. 不十分なテスト

アジャイルの目的は、ソフトウェアを速く納入することではなく、高品質なソフトウェアを速く納入することです。完了した作業がテストされて、チームの承認基準が満たされるまで、プロダクト オーナーは作業を承認しないでください。不十分なテストの慣習を克服する 1 つの方法は、自動テストの開発に力を入れることです。テストが成功するまで、ぞれぞれのビルドをテストしてください。

開発者がコーディングを完了したら、テストは最後に実行されると思っていませんか。それは違います。テスト担当者が機能横断的なチームに所属している場合、すぐにテストを開始することができます。イテレーション計画の後には、ユーザ ストーリーの要件がわかります。コードが完成したらすぐに検証できるように、ストーリーがもたらす価値に対するテストの構築を開始してください。これにより、ボトルネックの発生を防ぐことができます。

7. 顧客からのフィードバックの無視

顧客は最も重要な関係者です。組織による機能の構想を顧客に手伝ってもらいましょう。バックログと計画を改善するときに、最もよくあるリクエストをレビューします。データとトレンドを提供してくれるチーム メンバとしてカスタマ サポート担当者を含めることを検討してください。顧客の要望を満たしていないものを作り続けないように、このフィードバック ループをイテレーションごとに確認します。

CA Agile Central では、CA Agile Central Idea Manager を利用して顧客フィードバックを簡単に管理できます。外部および内部の関係者からの新機能のリクエストの収集、整理、および投票を行うことができるカスタマイズした投票サイトをセットアップできます。各リクエストについてのフィードバックを投稿したり、最新状況を知らせたりすることで、顧客の声に答えることもできます。CA Agile Central Idea Manager は、CA Agile Central Unlimited Edition に含まれています。

8. チーム エンパワーメントの欠如

アジャイル プロセスでのチーム エンパワーメントには 3 つの手順があります。最初に、計画に参加するようにメンバを招待して、チームの参加を促す必要があります。次に、提案された作業セットに対する考えをチームに尋ねます。最後に、それらの意見の価値が考慮される必要があります。本当のエンパワーメントとは、チームがコミットメントに影響を与える決定を行うことを意味します。会社はチームに何をするのかを指示するのではなく、最も重要なことに関するデータを提供します。

ディレクティブのセットの代わりに、リクエストの優先順位リストがあるチームは、プロセスの一部となります。チームは「ストーリー A を完了することはできますが、その場合はストーリー B を除く必要があります」や、「このイテレーションでストーリー C を完了する必要がある場合は、品質が低下する可能性があります」といったフィードバックを組織に返すことができます。チームによっては、この責任を回避して、追従するだけです。エンパワーメントを実現するために、チームの成長を促し、信頼環境を醸成してください。

9. 振り返りミーティングとデモ ミーティングの欠如

もうこれ以上ミーティングが提案されることはないと思ったかもしれませんが、まだ終わりではありません。イテレーションとリリースを終了するミーティングは、検査と順応のサイクルを完了するために必要な締め括りです。これは、すべてのレベルで実行されます。デイリー スタンドアップ ミーティングに振り返りの要素を含める必要があります。イテレーションの最後に、組織とのデモ ミーティングを開催し、チームが完了した作業を示します。ほかのチームからは貴重な意見(および賛辞)を得ることができます。

チーム内ではイテレーションとリリースの振り返りミーティングを実施します。これらのミーティングでは、チームは成功したこと、直面した問題、および次のタイムボックスで問題を回避するために必要なアクション アイテムについて話し合うことができます。コミットした作業だけに注目せず、アジャイル プロセス全体を振り返ります。計画のどの側面が上手くいきましたか。チームはこのリストにある誤りに直面しましたか。どのように調整できますか。

10. 抵抗への対処計画なし

変革は困難であり、一部の人がアジャイルへの切り替えに抵抗する可能性があります。このシナリオに対して準備するために最初に利用するのは、管理者からの通知です。組織は、個人のパフォーマンスよりチームの成功が優先されるという考え方を支持することを明示する必要があります。個人のメトリックをなくします。成功と失敗はグループとして評価されます。これで潜在的な文化問題に対処します。すなわち、アジャイルがもたらす透明性が、同僚による評価につながります。これは信頼環境の実現に再び戻ります。

初期段階では、アジャイルへの移行の経験者がオンサイトでチームに参加することを要求してください。その経験者は炭鉱でのカナリアの役割を担い、プロセスが危機にある可能性を示すわずかな兆候を見つけます。これを必要とする組織を支援する CA Agile Central コーチを活用できます。要望に合わせて計画をカスタマイズして、チームが最も必要とするアジャイル コンセプトを重視することができます。短い電話セッションで助言することもできます。

フィードバック

ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。