アジャイルプラクティスがさまざまなビジネスやプロジェクトでより広く採用されるにつれて、アジャイルアンチパターンはより巧妙にそして効果的に見かけを変えており、「ソリューション」と「回避策」のように見せかけている。それは、もはやフレームワークベースではなく、しかし、それが存在する組織のアジャイルエコシステムに正しく貢献するものに見える。この記事では、システム思考アプローチを採用することによってこの新世代のアンチパターンを認識し、分類することの重要性について説明する。そして、バリューストリームを使用した共有言語が、アジャイルチームとより幅広いビジネスの間のシステム思考文化を生み出す有効な手段である、という考えを生み出し、促進する方法について説明する。
アジャイルアンチパターンとは何か
アジャイルアンチパターンは通常、識別可能で広く認識されている問題に対して一般的に適用されるソリューションとして表される。効果的な修正を提供しなくなった場合、または修正を繰り返し適用することによる累積的な影響が悪影響を及ぼす場合、ソリューションはアンチパターンになる。アンチパターンの悪質な性質は、悪い影響が現れるまでに時間がかかること、予期しない場所で問題が発生すること、そしてそれが起こっている間に当初の問題がある程度解決されたように見えるという事実と深く関連している。
採用するかどうかを合意ベースで主導することの特徴は、アンチパターンの採用と継続を強くしてしまう。結局のところ、10人の時間的制約のあるチームは、日々のスタンドアップミーティングが、1週間の間に開発時間を12.5時間追加するよりもはるかに少ない利益しかもたらさないということに納得できないでしょう。
一般的なアジャイルアンチパターン
フレームワークベースのアンチパターンは、従来、主要なフレームワークコンポーネント（スタンドアップミーティング、レトロスペクティブ、レビュー）の削除、または通常ガバナンス要件を満たすステージゲートの追加を伴う。これらのフレームワークベースのアンチパターンは、採用や埋め込みが簡単で、ありがたいことに、同じ理由で儀式やプラクティスの追加や削除に関しては、比較的簡単に調整できる。ほとんどの場合、日々のスタンドアップミーティングを犠牲にして開発時間を増やすと、より多くのコード行が生成される。予想通り、このシナリオでは、より多くのバグ、修正、および失敗要求に対する取り組み（そして、チーム内での結束と協力、効果的なコミュニケーションの減少）につながる。
時間、調査、適応、経験によって、そのようなフレームワークの変更の影響が有害となりうるということをチームは学んでいる。彼らが一緒にこれらのアンチパターンを識別し、対処し、根絶することを学ぶにつれて、困難であった経験は自己組織化、高性能チームの進化に貢献している。明白ではない（そしてそれ故にもっと有害な）アンチパターンは、チームの構成、プラクティス、活動から、ジェンガブロックのように、簡単に除去することはできない。多くの場合、これらのアンチパターンは識別が困難であるため削除が困難であり、またアジャイルチームの外部から発生してより広いシステムの要件を満たしているため、識別が困難である。
皮肉なことに、アジャイルフレームワークはアンチパターンの繁殖場になりうる。それは、それらが生み出す経験によって、継続的に表面化し、問題に対処することを強いられるためである。したがって、チーム内で内部の失敗要求に対するシステムが作り出される可能性がある。言い換えれば、これはそれほど重要でない問題でさえも集中して解決を試みるという文化を生み出す可能性がある。これらの問題の起点と我々の反応に対するより広範な影響の両方を認識することは、このシナリオを避けるためのキーの一つであり、システム思考アプローチは大いに役立つことができる。
おそらく、最も一般的な組織上または管理上のアンチパターンは、「遅いプロジェクトに人員を追加するとさらに遅くなる」と述べているBrookの「law」によって具体化されている。開発チームは、リソースが不足しているにも関わらず、プロジェクトに追加の人手を迎えることに不満を言う（多くの場合正当な理由で）。ボリュームと品質を実現することは同じではない。ボリュームを追加することは、あなたがそれを構成する重さ（良いものと悪いものの両方）を製品のフィニッシュラインに向けて運ばなければならないことを意味する。問題の真実は、アンチパターンが提供するように見えるソリューションは非常に魅惑的ということである。結局のところ、余分な人員を削減するには、非常に高性能で高度に進化したチームが必要である（私が試してみた結果、支持されました！）。
チームの観点からすると、いくつかの強力なアンチパターンはそれほど魅力的ではない。しかし、組織的に主導されており、組織的な目的、あるいは、より広いビジネス目的に役立ち、チームが広く認識し共感できることが義務付けられるため強力でないということではない。残念ながら、これらの多くは固定コスト、スコープ、時間の概念に基づいており、チームレベルでは、これらの必須事項に対応するためのソリューションが成立しており、チームによって生み出される価値の流れは希薄になっている。最も包括的で詳細なバリューストリームマップでさえも、システムの構成要素間のインタラクションポイントやこれらのインタラクションを推進するために使用される語彙を意味的に表すものではないかもしれない。
おそらく最も広く普及している（広く感じられる）アンチパターンは、スクラムチームが成長し、その結果として組織変革の原動力となることを期待して、いくつかのスクラムチームを組織に投下することである。チームと組織の間の相互関係が明確に理解されていない、または明確に説明できていない場合、これはめったに成功しない。
多くの場合、これらのアンチパターンは、組織のアジャイルチームの役割にシステム思考アプローチを採用することによって回避、または少なくとも認識され、より効果的に対処することができる。
アジャイルを境界内で適応させるのか、それとも組織の要件を満たすように規則を変えていくのか
一般的に見過ごされがちなアジャイルフレームワークの利点の1つは、それらが診断ツールとしてうまく機能し、多くの場合、広範な問題を（展開の初期ステージで）表面化することである。それらの問題は、価値の提供、チームおよび組織の文化およびダイナミクス、そして継続的改善への動きに悪影響を及ぼす可能性がある。確立された慣習に適応することの本当の危険は、私たちが価値の提供よりも変化の影響を診断する（そして確かに測定する）ことに終始することである。これは、たとえば、より多くの開発時間を追求するためにチームの速度が増すことに重点が置かれ、スタンドアップミーティングを捨てた場合に、特に逆効果になる可能性がある。この場合の速度増加は、この適応が「機能している」ことを示している。さらに、これらの「微調整」が（チームレベルでも組織レベルでも）より広いシステムを参照せずに、そして理解されずに行われた場合、原因も結果による影響も完全には理解できなくなる。そして、元の変更を調整または相殺するためにさらに変更を加えることで問題が続くことなる。
アジャイル認定は良いものでも悪いものでもないが（有効性は認定を保持しているアジャイリストによる）、少なくとも境界、ルール明確にしている。そしてより実践的には対象のフレームワークのべし・べからずを表し、最も一般的には、フレームワークの正しい要素が適切に配置され、正しい方法で正しい順序で配置されることが確実に行える。スタンドアップとスプリントを持っていてもスクラムにはならない。そして、それを強制してもスクラムマスターにはならないが、認定は間違いなく境界を定義するのに役立つ。残念なことに、私たちは組織の規範、規則、境界に対応するために、これらの合意された境界および規則を覆し、希薄化し、無視することが多く、さらに悪いことに、これらの妥協を必要な適応または革新として特徴付ける（これらの「イノベーション」が、上記のようにさらに価値のないソリューションを作成するためのスコープを生み出す場合、特に有害である）。
このアンチパターンを持ち続けてしまう多くの環境要因があるが、その中で最も重要なのは、組織的でより広範な体系的要件に適応するためのフレームワークの柔軟性を示すアジャイリストの即応能力である。皮肉なことに、これは、実際の変革がチームレベルでローカライズされる。そして、チームとそれらが存在するシステムとの間のノードの接続性は、コスト、スコープ、時間の文脈でインタラクションを起こさせ、より広い組織の変革として成功しない。このように、チームレベルの変革が、より広いシステム内での変革の欠如に対応するために行われる。
システム思考とアジャイルがどのように連携するのか
システム思考は、物事が全体（システム）内で互いにどのように影響を与えるかを理解し、これらの相互関係がその全体の共通の目的にどのように影響するかを理解しようと試みるプロセスであり、それ以上複雑なものではない。さらに、システム思考は、この理解を利用して、最も大きな影響力のポイント、つまり小さな変更が大きな結果をもたらす可能性があるシステム内の場所を特定することを目的としたアプローチである。一流のアジャイルチームは、システム思考の概念を非常に効果的に利用し、彼らが何をし、どのようにそれを行うかを改善するために絶えず検査し適応する。システム特性は、フィードバックによって安定性を維持する能力である。
フレームワークをスケーリングすることに対するあなたの考え、感情、そして実際の経験がどうであれ、SAFeのより効果的な側面の1つは、価値を提供するためのシステム思考アプローチに重点を置くことである。これは、「解決策はシステムである」という概念で具体化されている。共通の目的（ソリューション）が組織システムの中心にあるにもかかわらず、システムの個々のコンポーネントが内向きに見え、それらが離れているがゆえに「利己的で競争的で独立したプロフィットセンター」として運営され、「システムを破壊している」ということに気づいていないことがよくある。チームはほとんど（チームにとって）内部の問題とソリューションに集中しているので、これはチームを、より広いビジネスから、そしてそこからたらされる体系的な影響（良い面と悪い面の両方）から分離させるように働く。
これに対抗する方法は、より広いシステムがアジャイルチームに与える影響の認識と理解に重点を置くことによって、より広いシステムとそのコンポーネント（アジャイルチーム）の間の境界をあいまいにすることである。これは、チームレベルとシステムレベルのアンチパターンの両方を分類し、チームが開発するソリューションに関して最も高いレバレッジのポイントを決定するように促すことによって達成できる。
アジャイルアンチパターンに対処するためのシステム思考の使用
多くの企業にとって、組織の複雑さは組織の問題につながり、その結果、組織とそのアジャイルチームが作成して展開できるソリューションの有効性が薄れる。この問題は、アジャイルへの変革提唱者がチームレベルで影響を与えることが多く、より広い組織内での効果的な変革のための限られたスコープしか持っていない（実践のコミュニティにもかかわらず）。システム思考アプローチは、境界を曖昧にし、アジャイルチームとより広い組織との間の障壁の硬直性を減らすための手段と見なされるべきである。システム思考の重要な原則は、システムのパフォーマンスは部品の集合ではないと認識することである。むしろそれはこれらの部品の間のインタラクションの結果である。出現し、持続するアンチパターンは、多くの場合、アジャイルチームと彼らが活動するより幅広い組織システムとの間の効果的でないインタラクションの結果である。
このようにシステム思考を取り入れることによって、これらの最適に及ばないインタラクションを特徴付けるパターンを認識し始めることができる。そうすることで、症状ではなく原因に対処するように変化することができる。
アジャイル認定
一部の分野では金儲けとしては悪く言われているが、認定は、スキルや知識という観点で効果的なベースラインを提供する。そして、トレーニングセッション中にさまざまな背景に基づいて行われる情報の交換と経験は価値がある。特に企業がアジャイルを開発し促進しようとする中で、特定の組織や組織のシナリオ（物流プロジェクトのコンテキストにおけるアジャイルなソリューションは、ソフトウェア開発におけるそれとは著しく異なる可能性がある）に特化したよりカスタムされた認定がますます増えると思う。特に、企業が既存のランク内からアジャイルな専門知識を開発し促進しようとしているときや、より伝統的なデリバリーを中心とした役割が進化するときである。これにより、関連する経験を積むことなく、大量のアジャイル認定を取得することが可能になり、頻繁に現れている懸念にも対処できる。社内の「アジャイルアカデミー」が当たり前になり、企業が独自の非常に特定のニーズを満たすために社内からリクルートするようになるかもしれない。
チームがアンチパターンを自己チェックし、結果に影響を与えないように回避するための行動
「今日の問題は昨日のソリューションである」という古い格言は、アンチパターンの問題のある性質をカプセル化しているだけでなく、問題解決の展望の進化の性質を示唆している。チームまたは組織がアンチパターンを選択した歴史を持っているかどうかを確認し、アンチパターンはアジャイルチームとチームが操作するシステムとの間の効果的でないインタラクションの結果であることが多いことを認識することが重要である。
提起された問題と、チームレベルで提案されるソリューションを分類することは価値がある。それによって、これらの問題がタイムリーに（原因と結果が常に場所と時間で密接に関連しているとは限らない）戦略的に目標設定された方法で対処できる。そして、問題がどこから発生したのか、同じ場所で行動がとられたかを首尾よく識別できるようになる。
パフォーマンスの高いアジャイルチームはチーム内に透明性を作り出すのに長けているが、システム思考アプローチを使用すると、アジャイルチームがシステムと対話する方法に関して、より効果的に透明性を作り出すことができる。このようにして、インタラクションが効果的でない、または損害を与える場所、および、不十分なインタラクションがアンチパターンとしてどのように現れるかをハイライトすることがより容易になる。
アジャイルチームは、問題とソリューションを次のように分類するよう努める必要がある。
- システム条件の分析と、アジャイルチームとそのチームの作業に影響を与えるものの記述
- どのソリューションが成立していて、それらのソリューションがまだ必要かどうか、それらがアンチパターンに進化したかどうか、そしてその理由を判断するための振り返り活動の振り返り
- 問題はチームから発生するのか、それともより広いシステムから発生するのか
- ソリューションに関して最も高いレバレッジのポイントはどこであるか
- 進行中の影響がチームの外部およびより広いシステム内に感じられる場合、どのような内部実験でチームをそこに導けるか
- 私たちはチームが感じる症状ではなく、体系的な原因に対処できるか
- 私たちが現在直面している問題のうち、どれがソリューションとして始まったか
- このソリューションをチーム内の他の場所でも感じ取ることができるか
- アジャイルチームと幅広いシステムとの間のフィードバックループはどこにあり、それらは改善できるか
上記のすべては、システムの変更と改善におけるアジャイルチームの積極的な役割を認識し促進する組織文化の中で行われます。
製品開発の世界に私たちが今存在しているという事実によって重大な課題が提起される。製品開発の世界では、継続的開発、インテグレーション、実現された価値、そして流れがビジネス競争力の観点から重要であると考えられている。しかし、これらの目標の達成は、バランスのとれた微調整されたアジャイルエコシステムの作成に依存しており、バランスをとるために、それを脅かすアンチパターンを認識し対処する。
アジャイルフレームワークはより多様なビジネス環境やデリバリーモデルに統合されるため、アンチパターンは製品や環境を反映したものだけでなく、システム思考のアプローチに失敗した結果でもある。システム思考により、より広範なシステム内でのアジャイルアプローチの破壊的な影響を認識し、それを活用することができる。
著者について
David Johnstonは、高等教育、ソフトウェア品質保証、ソフトシステム方法論、およびアジャイルフレームワークの指導などで15年以上の経験を持ち、メディア、小売、物流、エンジニアリングなどのさまざまなソフトウェア開発環境でスクラムマスターおよびアジャイルコーチとして活動してきた。