アジャイルソフトウェア開発は、セルフサービスAPI、インフラストラクチャ・プロビジョニング、リアルタイム・コラボレーション・ソフトウェア、分散バージョン管理システムなどのテクノロジーを使うことで、大規模に行える。リーンは、Obeya（大部屋）、体系的な問題解決、ワンピースフロー、タクトタイム、カイゼンなどのテクニックを用いて、アジャイルカルチャーを補完し、スケールできる。Fabrice Bernhard氏は、FlowCon Franceで、同社がアジャイルソフトウェア開発を大規模に行うために、リーン思考でどのように技術を利用しているかについて語った。
Bernhard氏は、アジャイルマニフェストは大規模な組織には当てはまらないと述べた。ソフトウェア組織をスケールさせながらアジャイルな文化を維持する原則を探しているリーダーは、他の場所を探す必要がある。そして残念ながら、その「別の場所」は現在「アジャイル・アット・スケール」と呼ばれる選択肢で混雑しており、その多くは非常に官僚的であるため、アジャイルマニフェストの精神にはそぐわないと彼は述べた。
アジャイルはスケールできる。アジャイル文化を維持しながらスケールした組織の例はたくさんある。リーン思考の知識体系の中に、アジャイルマニフェストに忠実でありながら組織をスケールさせるために探していた原則を見つけたのだ。
Bernhard氏がBenoît Charles-Lavauzelle氏と共に執筆した書籍『The Lean Tech Manifesto』では、アジャイルマニフェストの原則を拡張するためにリーン思考が提供する原則、システム、ツールを探求している。彼はいくつかの例を挙げた。
- バリューモデル、Obeya、バリューストリームは、「顧客のための価値」が組織全体の北極星とすることで、「顧客とのコラボレーション」を拡大します。
- PDCAと5Sによる体系的な問題解決は、チームリーダーによってサポートされ、デジタル社会ではコラボレーション・テクノロジーによって実現されます。「個人と相互作用」を拡大し、組織を「テクノロジーを活用したチームのネットワーク」に変革します。
- 自働化、ダントツ、ポカヨケ、プル、ワンピースフロー（一品流し）、タクトタイムなどを活用し、「最初から正しく、かつジャストインタイム」を実現し、「動作するソフトウェア」を拡張します。
- 標準、カイゼン、スキルマトリックス、実践コミュニティは、「変化への対応」と「学習する組織の構築」を実現するためのものです。
Bernhard氏は、一部の大規模なアジャイル組織が成功している理由を、リーン思考では十分に説明できないと感じたと述べた。彼は、Linuxオープンソースプロジェクトとそのコミュニティが、1人から55,000人のコントリビューターまでどのようにスケールしていったかを調査し、その過程で直面したスケーリングの問題に対処するためにテクノロジーを活用した。
最初のスケーリングの危機は1996年に起こり、Linus氏は「電子メールに生き埋めにされた」と書いた。この危機は、ローダブルカーネルモジュールの導入により、よりモジュール化されたアーキテクチャを採用し対処された。また、コントリビューターがコントリビューションをマージするために必要な高い品質基準を確実に実装可能にサポートする、メンテナの役割も創設された。
2回目のスケーリングの危機は1998年から2002年まで続き、最終的にBitKeeperの採用によって対処されたが、後にGitに取って代わられた。これによって、コントリビューションをマージする作業が、メンテナとコントリビューターのネットワークに分散された。
どちらのケースでも、テクノロジーはチーム間の依存関係を減らし、コントリビューターが高い自律性を保てるようにし、すべてのコントリビューションをメインのリポジトリに簡単にマージ可能にするために使われた、とBernhard氏は言う。
仕事の遂行に別のチームに依存する必要があるときに、テクノロジーはチーム間のコミュニケーションの必要性を減らすのに役立つ。あるチームが他のチームのデータに依存している場合など、典型的な組織的依存関係は、適切なテクノロジーとアーキテクチャを使用することで、セルフサービスAPIに置き換えられる、とBernhard氏は述べた。これは、AWSがEC2を発明し、先駆けて仮想サーバーを起動するためのセルフサービスAPIを提供したように、インフラのプロビジョニングのような、より複雑な依存関係にも拡張できると彼は付け加えた。
Bernhard氏は、依存関係のもう1つのタイプとして、イラスト、テキスト、ソースコードのいずれであっても、同じようなドキュメントに行われたコントリビューションをマージするという課題に対処することを挙げた。これは、Google Docsのようなリアルタイムコラボレーションソフトウェアや、Gitのような分散バージョン管理システムによって、ここ15年で大きく変化したと彼は言う。
Bernhard氏は、Linuxコミュニティがスケーリングの問題にどのように対処しているのかから多くを学んだと述べた。また、スクラムやXPのような最初のアジャイル方法論が、ソフトウェアエンジニアの単一チームに焦点を当てているのに対し、リーン思考は、非常に大規模な組織において、何十年もの間、大規模な実戦でテストされてきた、とBernhard氏は言う。アジャイル組織を拡大しようとする人は、リーン思考を勉強して、アジャイルマニフェストの精神に忠実でありながら、大規模な組織を率いる方法について、何十年にもわたる経験から利益を得るべきだ、と彼は結論づけた。