SAFeはScrumと全く異なるアジャイル開発プロセスだ

SAFe経験者の話を聞いて、SAFeはScrumと全く異なるアジャイル開発プロセスだと初めて認識できた。
ラフなメモ書き。

【参考】
SAFe 5.0のエッセンス: スケールド・アジャイル・フレームワークによりビジネスアジリティーを達成する (00) | リチャード ナスター, D レフィングウェル |本 | 通販 | Amazon

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 | 榎本 明仁, 木村 卓央, 高江洲 睦, 榎本 明仁, 荒瀬 中人, 水野 正隆, 守田 憲司 |本 | 通販 | Amazon

SAFeRアジャイルな企業への変わり方　現場から経営まで貫く価値創造のためのフレームワーク入門 | 張嵐, 横田和彦 |本 | 通販 | Amazon

作る、試す、正す。　アジャイルなモノづくりのための全体戦略 | 市谷 聡啓 |本 | 通販 | Amazon

Amazon.co.jp: アジャイルソフトウェア要求 (Object Oriented SELECTION Classics) : Dean Leffingwell, オージス総研: 本

【1】SAFe勉強会に議論してすごく参考になった。SAFeはスクラムと全く異なるフレームワークと見たほうがいい感じだ。

僕がSAFeで一番知りたいことは、アジャイル開発における計画・実行・検査・適応のそれぞれのプロセスでは、誰が責任を持って意思決定しているのか、ということだ。
大規模アジャイルだからといっても、大規模プロジェクトと同じ構造を持つわけだから、メンバー全員が一同に集まることは時間的にも物理的にも難しくなる。
責任の分担と責任範囲、権限範囲の設計が必要になる。

誰がプログラムバックログ、スプリントバックログの優先順位、イテレーションの範囲を決めるのか？
誰がプログラムバックログのメンテナンス、リファインメントを担当するのか？
誰が、各チームが開発したモジュールを統合ビルド、デプロイ、デリバリーの責任を持つのか？
誰が、リリース計画の方向性を決めるのか？

僕は、誰が責任や意思決定を持つのか、が知りたかった。
実際、大規模プロジェクトになれば、どうしても階層的な組織構造が発生し、そこに意思決定や指揮命令系統の順序が決まる。
だからこそ、組織の4原則に基づき、統制範囲の原則、命令統一化の原則が組織構造に必要になり、指示命令する人と指示に従う人に分かれる。
その組織構造が大規模アジャイル組織では、どのように設定すべきなのか？

※大規模プロジェクトなので、プロダクトバックログと呼ばず、プログラムバックログとも呼ぶらしい。

【2】SAFeの肝は、2つあると思う。
1つ目は、アジャイルリリーストレインで複数のアジャイルチームのリリースを同期させること。
大規模アジャイルなので、複数のアジャイルチームで構成されるプロジェクトになる。
すると、複数のアジャイルチームが開発したコンポーネント複数個を統合ビルドする必要がある。
その統合ビルドを合わせるために、電車の発着時刻にたとえて、アジャイルリリーストレインと言うわけだ。

2つ目は、複数のアジャイルチーム同士でプロダクトオーナーだけのPOSync、スクラムマスターだけの打合せ、全メンバーが集まる打合せ、など数多くの打合せを設計すること。
確かに官僚的なアジャイルな印象を持った。

アジャイルリリーストレインを全チームに同期させるために、事前に全チームで計画を立てて、定期的にリリースする。3ヶ月後にふりかえりする、というプロセスみたいだ。
興味深いことは、統合ビルドしたモジュールのスプリントレビュー、スプリントデモ・スプリントレトロスペクティブというイベントは正式に作られていないらしい。
もちろん、アジャイルチーム内ではスプリントプラニング・レビュー・デモ・レトロスペクティブは行われる。
とはいえ、大規模プロジェクトであっても、全チームメンバー全員が集まることはできないので、各チームのリーダークラスが集まった打合せで、モジュールのデモ・レビュー・レトロスペクティブは行われているのだろう。

【3】小さなチームによる小さな開発が現代では主流であっても、LLMとかSaaSとか大規模なシステム開発は必ずある。
GAFAのように、ソフトウェア専門企業も数万人の従業員を抱える大規模な組織を形成している。

だからこそ、SAFeのように、既存の大規模かつ複雑な組織にアジャイル開発を導入する時に無意味な摩擦をできるだけ避けて、導入できるプロセス手法が欲しくなる。
その辺りを考えてみたい。