Agile 20周年：失敗した反乱

 (simplethread.com)
23 ポイント 投稿者 xguru 2021-08-09 | 3件のコメント | WhatsAppで共有
  • Agile Manifesto（アジャイル宣言）が発表されてから20年が経った今、明白な事実が2つある

  1. Agileという名前を広めることには勝利した。誰も non-Agile と呼ばれたくはない

  2. Agileの実践という点では、創始者たちの革命的なアイデアに比べてかなり不十分である

  • 「みんな Agile をやっていると言うが、Agile な人はほとんどいない」なぜこんな状況になったのだろうか？

[ Whence The Manifesto : 宣言文はどのように始まったのか ]

  • 2001年2月、17人のソフトウェア専門家グループがユタ州のスキーリゾートで会合を開いた

  • 数日間の議論を通じて "Agile Software Development Manifesto" を共同で作成した

  • 重要なのは、彼らが "Practitioner（実務家）" だったということ。彼らは PM や CTO、VP Eng などではなかった。彼らは開発者、プログラマー、科学者、エンジニアだった。彼らはその時もコードを書き続け、利害関係者と協力して問題を解決していた。これは本当に重要だ。

  • もう1つのポイントは、Agile Manifesto がゼロから作られたわけではないということ。彼らの多くは、自分が作ったり広めたりしている方法論をすでに持っていた。

→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Pragmatic Programming

  • グループの全員がソフトウェア開発の豊富な経験を持っており、当時市場の主流だった文書主導の重いソフトウェア開発プロセスに代わるものを探していた。

  • 宣言の核心は4つの価値の説明にある

"私たちは、ソフトウェアを開発し、また他者の開発を支援する中で、より良いソフトウェア開発の方法を見つけ出している。この活動を通して、私たちは次のことを価値あるものと認めるようになった。

  • プロセスやツールよりも個人と対話を

  • 包括的なドキュメントよりも動くソフトウェアを

  • 契約交渉よりも顧客との協調を

  • 計画に従うことよりも変化への対応を

価値あるものとする。すなわち、左側の項目にも価値はあるが、私たちは右側の項目により高い価値を置く。"

[ A New Hope : 新たな希望 ]

  • 2021年の視点から見ると、現代的なソフトウェア開発の実践は当たり前のものに思えるが、2001年にはこうしたアイデアは非常に急進的だった。

  • 要件をすべて集め、全機能を評価し終える前にソフトウェア開発を始めるんですか？ 狂ってる！

  • 忘れられつつある重要な点は、Agile が初期には公然としていて、しかも戦闘的なまでに反管理職的（anti-management）だったことだ

  • 例えば Scrum の共同創始者 Ken Schwaber は、すべてのプロジェクトマネージャーをなくそうと主張し、単にプロジェクトから PM を外すだけでなく、業界そのものからその職種をなくすべきだと述べていた。

"私たちは、複雑で創造的な仕事において、プロジェクトマネージャーの役割は非生産的だとわかりました。

プロジェクト計画という形で表れるプロジェクトマネージャーの思考は、

問題を最良に解決するために全員の知性を集めるのではなく、

計画に書かれている内容によって全員の創造性と知性を制限してしまいます。"

  • スクラムマスターにはほとんど権限がなく、課題についての投票権もなかった。彼らはサーバントリーダー*であり、チームを守り、障害物を取り除くが、チームを管理はしなかった。

→ サーバントリーダー：部下に奉仕する姿勢でその成長と発展を助け、リーダーと部下の信頼を築き、組織目標の達成に部下自らが貢献するようにするリーダー

  • XP にももともと Tracker と Coach があり、同様に機能していた。

  • Crystal と Hexagonal アーキテクチャの創始者である Alistair Cockburn は、最近のツイートスレッドで次のように語っている

"スクラムは敵対的な土地で非常に大きな取引を成立させた。

  • 経営陣は年に12回、各スプリント後に好きな形で方向転換できた

  • チームは、重い思考と作業を行うために、割り込みや方向転換のない完全に静かな1か月という期間を得た

  • チームは経営陣の干渉なしに、Bid（優先順位を決めるためのもの）で1か月の間にできることとできないことを宣言できた

  • どの経営陣も、これ以上に良い取引をしたことはなかった

  • どの開発チームも、これ以上に良い取引をしたことはなかった

"

（注：このツイートスレッドは最初に「スクラムチームはスプリントに割り当てられた全アイテムを100%完了しなければならない、という考えはどこから来たのですか？ それはおかしいのでは？」という質問から始まった回答です。元のスレッド全体を見ることを勧めます。）

  • 私は15年以上 Agile チームで働いてきた認定スクラムマスターであり、この分野の人気書籍も多く読んできたが、スクラムのアイデアをこれほど明確かつ簡潔に説明したものを見たことがない。

  • スクラムは敵対的な環境で機能するように作られた。思考し探索する時間を必要とする開発者と、強圧的な管理者との間の契約だった。

[ The Empire Strikes Back : 帝国の逆襲 ]

  • ある意味で Agile は草の根の労働運動だった。実務家から始まり、経営陣にまで上っていった。では、どうやって成功したのだろうか？

  • 一因は開発者の数が増え、ビジネスにもたらす価値が高まったことにある

  • より大きな理由は、従来のウォーターフォール開発がうまく機能していなかったことだ

  • ソフトウェアがより複雑になり、ビジネスのスピードが速くなり、ユーザーの期待水準が上がるにつれて、すべてを事前に計画することは不可能になった。

  • 反復的な開発を受け入れるのは理にかなっていたが、すべてを計画したい管理者にとっては少し怖いことでもあった。

  • 2000年代半ばの経営陣は、当初はこれを受け入れていなかった。

  • その後、「エンジニアたちが言い続けているこのクレイジーなアイデアを一度試してみよう。どうせ今も締め切りには間に合っていないんだから、これ以上どれだけ悪くなる？」という話が出てきた。

  • しかし驚いたことに、うまく機能し始めた。チームは最初こそ少し縮こまっていたが（遅かったが）、徐々に各チームに合うパターンがわかるようになり、スピードがついてきた。

  • 数回のスプリントを経て、動くソフトウェア、協業、検査と適応に時間を割くこと、そしてそれ以外のすべてに優先順位をつけることの力が理解されるようになった。

  • およそ5年の間に、Agile は「聞いたことはある方法論」から、誰もが完全に慣れているわけではないが一般的なものへと変わっていった。

  • 2005年には Agile と TDD は本物の差別化要因だった

  • 2010年には、最新のソフトウェアチームはどこも何らかの形で Agile を実践していた。

  • 少なくともコンサルティング業界ではバブルだった。大企業はいつだって動きが遅かったが。

"やりました！ 勝ったんです！ みんなで祝いましょう"

これで物語は終わりで、ブラウザのタブを閉じてもいい。

"Winning was easy, young man. Governing’s harder."

「勝つのは簡単だった、若者よ。統治するほうが難しい」

→ ミュージカル『Hamilton』で描かれたジョージ・ワシントン

  • 残念ながら、多くの革命と同じように、アジャイルの歴史も創始者たちが構想した通りには展開しなかった。

→ 「個人と対話」を優先することは、売り込みにくい概念だとわかった。プロセスやツールを売るほうがはるかに簡単だ

（注：ここでの Sell は販売というより、他人に理解させるという意味です。）

→ 「動くソフトウェア」は、非現実的な計画や大量の文書よりも作るのが難しいことがわかった。

→ 「顧客との協調」には信頼と脆弱性（vulnerability）が必要だが、ビジネスには常にそれがあるわけではない。

→ 「変化への対応」は、長期計画を立てて統制したい経営陣のほうに、しばしばより重みが置かれてしまった。

"Agile は、正しく実行されないとしばしば混沌のように感じられることがわかった"

  • しかし、この4つの価値が間違っているわけではない

  • つまり、これらすべてを正しく機能させるには多少の努力が必要であり、ソフトウェアが本質的に散らかっていて混沌としていることを受け入れる勇気が必要だということだ。

  • 学び、適応し、改善し、リリースし続ければ、最終的にはウォーターフォールよりもはるかに良い場所、より正直で、より現実的で、より生産的な場所へ行けると理解し、信じなければならない。

"アジャイル運動は反方法論（Anti-methodology）ではありません。

実際、私たちの多くは『方法論』という言葉への信頼が回復することを望んでいます。バランスが回復することを望んでいます。

モデリングを受け入れますが、それはほこりをかぶった会社の倉庫に図をしまっておくためではありません。

文書化を受け入れますが、保守されず、ほとんど使われない何百ページもの本を受け入れるわけではありません。

計画は立てますが、激動する環境における計画の限界を認識します。

XP、Scrum、その他のアジャイル方法論の支持者を『Hacker』とレッテル貼りする人々は、『方法論』と『ハッカー』という用語の本来の定義を知らないのです。"

  • Jim Highsmith, History: The Agile Manifesto

  • これが重要なポイントだ。私たちは依然として計画とドキュメントを作るし、Agile に対して厳密であるべきだ。これはバランスの話である。

  • しかし、あなたの組織が Agile への移行に苦労し、混乱に陥っているときに、誰かが認証やプロセス、ツールのような救命ボートを差し出せば、そちらへ飛びついてしまう。

  • 経営陣は「自己組織化チーム」よりも、プロセスとツールのほうをはるかによく理解できる。

[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : ローグ・ワン（の帰還） ]

  • ここで私の三幕構成は少し崩れる。なぜなら Agile の名を掲げずに戻ってくる勇敢な反乱軍が見当たらないからだ

（注：スター・ウォーズシリーズの題名になぞらえ、Agile ではない別の何かは現れなかった、という意味）

  • ツールベンダー、プロセスコンサルタント、専門家は、彼らが決して提供できない約束をすることが多い。

  • 私たちが SAFe（Scale Agile Framework for Enterprise）や Scaled Scrum、そのほかのエンタープライズ向け Agile バージョンを作るに至った理由もそこにある

  • こうしたフレームワークは悪意を持って作られたわけではなく、おそらく適切な文脈ではある程度の価値があるだろう。

  • しかし、私はそれらを Agile とは呼ばない

  • 個人と対話を重視する方法論をスケールさせようとすると、必然的に問題が起こり、方法論の本来の価値が損なわれる。

  • アジャイル宣言の署名者であり、XP の共同創始者でもある Ron Jeffries が2018年に書いた有名な文章

"開発者は Agile を捨てるべきです。

『Agile』というアイデアが正しく適用されないと、開発者への干渉が増え、作業時間は減り、圧力は高まり、『もっと速く進め』と要求されます。これは開発者にとって良くないだけでなく、最終的には会社にとっても良くありません。『Agile』を正しく実行しないと、実際に達成できる以上のはるかに多くの欠陥と、より遅い進行をしばしば招くからです。しばしば優秀な開発者がそうした会社を去り、その結果、『Agile』を導入する前よりも効率の悪い企業になってしまいます。"

  • もう1人の署名者であり、『The Pragmatic Programmer』の共同創始者でもある Dave Thomas が2014年に書いた有名な文章

"Agile は死んだ。（Agility よ永遠なれ）

『Agile』という言葉は、実質的に意味がないところまでねじ曲げられてしまい、アジャイルコミュニティはおおむね、コンサルタントやベンダーがサービスや製品を売る場になってしまいました。Manifesto が大衆化するにつれて、Agile という言葉は、支持を得たいもの、請求したい時間があるもの、あるいは売りたい製品があるものすべてを引き寄せる磁石となり、マーケティング用語になってしまったのです。

だから私は、『Agile』という言葉はもう引退させるべき時だと思います。"

[ Retro : 過去への回帰 ]

  • 本当に悲しいのは、若い開発者が Agile を見下し、経営陣が非現実的な約束を引き出し、開発者に途方もない時間働くよう仕向けるための手段だと考えるようになっているのを見ることだ。

  • 彼らが知っている唯一の Agile は、自分たちに課された統制メカニズムであって、喜んで受け入れた自己エンパワーメントの道具ではない。

  • しかし、歴史と当初のビジョンについての議論を始めることが、私たちがこれからどう進むべきかを思い出す助けになればと思う。

  • それでも良い知らせは、Agile Manifesto の原則が20年前と同じように、今でも賢明で適切だということだ。そして Jeffries や Thomas のような、背教者（apostates、信仰を捨てた人）と見なされがちな人たちも、依然としてそう考えている。

  • 上で言及した文章で Jeffries は次のように述べている

"しかし、Manifesto for Agile Software Development の価値と原則は、依然として私の知る限り最良のソフトウェア構築方法を提供しており、私の長く多様な経験に基づけば、より大きな組織でどんな方法論を使うにしても、その価値と原則に従うでしょう。"

  • 私はこの意見に同意する

  • 今、アジャイルについて語ることはヒップでもクールでもない。アジャイルは退屈だ。

"みんな Agile やってますよね？"

  • 今は、この20年を振り返り、自分たちにいくつかの問いを投げかけるのに完璧なタイミングだ

→ 何がうまくいったのか？

→ 何が間違っていたのか？

→ 次は何をどう変えたいのか？

  • 今後数か月にわたり、元来の12のアジャイル原則を見直し、その本来の意味を文脈化し、現在のソフトウェア開発環境における価値を考えていく予定だ

"私の願いは、創設時の原則を学ぶことで、過去から学び、Dave Thomas の言うように『Agile』を捨てるとしても『Agility（俊敏さ）』は保てるようになることです。"

関連記事

3件のコメント

 
kaykim 2021-08-10

私は以下の説明には共感しますが、残りについてはそういうものだと受け止めています。

「『Agile』という言葉は、事実上意味がなくなるところまで転倒・変質させられており、アジャイルコミュニティも概してコンサルタントやベンダーがサービスや製品を販売する場になってしまいました。」

その理由は、すでに皆が知っている通り、どんな方法であっても商業的成功（あるいはプロジェクトの成功）を保証するわけではないからです。ゲームに限って言えば、アジャイルが他のアプローチより統計的に有意な結果を出すわけではないという研究さえありました。

「優れたゲーム開発チームは、スタジオの開発方法論についてすべての構成員が十分に訓練を受け、それに従うようにしています [1]。また、ゲーム開発の最中にも継続的に労力を払い、開発方法を磨き上げて改善します。それにもかかわらず、私たちはアジャイルとアジャイル・スクラム、あるいはウォーターフォール開発手法の間に、統計的に有意な成果の差を見いだせませんでした [2]。開発手法の中で成果に差が見られたのは、何の開発手法もない場合だけでした。私たちの研究では、チームメンバーの多寡にかかわらず、開発手法が存在しないことは破滅的であることが分かりました。

開発方法論に普遍的な正解はありません。自分たちのチームとプロジェクトに最も適していると考える開発方法論を選んでください。」

（出典: https://masterfarseer.blogspot.com/2015/03/5.html ）

それでも私がアジャイルのアプローチ（より正確にはスクラム、XP、カンバン）を好む理由は、私が直面している問題を解決してくれるからです（It works!）。同じ理由で、「アジャイル宣言」の中で私が最も好きな一節は「私たちはソフトウェアを開発し、また他の人たちの開発を助けながら、ソフトウェア開発のより良い方法を見つけ出している。」です。これは、何らかの理論に基づいて方法論を作ったのではなく、実際に「自分でやってみて効果があり、他の人にも勧めてみたらやはり効果があった」ということを土台にしているからです。Ken SchwaberとMike Beedleが書いた Agile Software Deveopment with Scrum でも、実践法を先に発明し、後からその理論的根拠を発見していく道のりが語られています。そしてその観点に立てば、いつか誰かがアジャイルをさらに発展させることもできるし、アジャイルより優れたものを発明することもあり得ると思います。

他のすべての道具と同じように、アジャイルは万能薬ではないので、ある人には効果があり、ある人には効果がないだろうと思います。だから私は今では、誰かがアジャイルで成功したからといって特別に勇気づけられることもなければ、失敗したからといって特別に落胆することもありません。同時に、より良い方法があるなら、いつでも試し、適応する（inspect and adapt）つもりは十分にあります。それこそが、スクラムが私に与えてくれた本当の教訓なのです。
 
kenuheo 2021-08-09

  • プロセスとツール < 個人と相互作用

  • 包括的な文書 < 動くソフトウェア

  • 契約交渉 < 顧客との協力

  • 計画に従うこと < 変化に対応すること

ここで不等号を入れ替えてみると

  • プロセスとツール > 個人と相互作用

  • 包括的な文書 > 動くソフトウェア

  • 契約交渉 > 顧客との協力

  • 計画に従うこと > 変化に対応すること

SIになります。

要約翻訳ありがとうございます。
 
xguru 2021-08-09

→ 2012年に有名だった Spotify の「Scaling Agile」ホワイトペーパーは、彼らの希望にすぎず、完全には実装されなかった。