SAFe ケーススタディ: 現場からの変革ノート

この記事は、Toptal のアジャイル スケーリング シリーズの第 3 部であり、プロジェクト マネージャーがチーム拡張の取り組みを行うためのガイドとなるように設計されています。 パート 1 の「5 つのアジャイル スケーリング フレームワークの比較: どちらを使用すべきか?」を必ずお読みください。 パート 2、「アジャイル スケーリング: スクラム マスターのための SAFe ベスト プラクティス」。

第 15 回 State of Agile Reportによると、94% の企業が何らかの形でアジリティを実践しています。 しかし調査によると、組織の 90% は全社的なアジャイルの実装に苦労しています。 通常、これらの取り組みを主導し、組織化するのは、アジャイル コーチ、スクラム マスター、およびその他のプロジェクト管理の専門家の仕事です。 多くの場合、彼らは理解しにくい企業文化の中で、変化に抵抗するチームや部門と協力しています。

この円卓会議では、Toptal の 3 人のプロジェクト マネージャーが、主要なアジャイル変革の課題について話し合います。 彼らのソリューションは Scaled Agile Framework (SAFe) に準拠しているため、SAFe の作成者である Dean Leffingwell にも話を聞きました。 彼らの集合的な洞察は、SAFe 実践者がアジリティとは何かについての明確なビジョンと、反抗的なチームを参加させることができるリーダーシップ計画を準備する必要があることを示しています。

フレームワークの作成者と SAFe について話す

Scaled Agile によって正式化されたフレームワークである SAFe の歴史は 2014 年にさかのぼります。 ソフトウェア開発方法論者として、彼は開発チームでのアジャイル プラクティスの結果に感銘を受け、すぐにその考え方を会社全体に適用する方法を模索し始めました。 アジャイル チームが結果を出せるとしたら、調整されたアジャイル チームのチームは何を生み出すことができるでしょうか? 国内企業または国際企業での本格的な変革プロジェクトにアジャイル プラクティスをどのように使用できるでしょうか? Leffingwell 氏は次のように述べています。 私はアジャイルが大好きです。 私はそれを大きくしたいだけです。

それ以来、企業は、納期の短縮、製品品質の向上、効率の向上、従業員のエンゲージメントの向上など、SAFe のメリットを認識してきました。 2021 年の時点で、世界中の組織の 3 分の 1 以上が SAFe を使用しており、その最も重要な側面の 1 つは、SAFe が提供する共有プロセスと統一言語です。 たとえば、あるチームがスプリントの長さを 2 週間と考え、別のチームが 30 日と考えている場合、Leffingwell が「バベルの塔の問題」と表現する問題が発生します。 「機能」が何を意味するのかさえ合意できない場合、チームがどの機能を追加するかについて議論するのは困難です。 「大きなソリューションを構築したいのであれば、共通の方法で働く人々が必要です」と彼は言います。 「私たちの業界には、「イテレーション」、「スプリント」、「バックログ」など、過負荷でない用語はありません。 チームや地域の境界を越えて仕事をしようとしている場合、これは役に立ちません。」

アジャイルの成功事例

会社の全員が統一された話し方や仕事のやり方を採用するようにすることは、変化の緊急性が非常に高い場合でも困難な作業です。 確立された企業では、それはより困難になる可能性があります。 Leffingwell は次のように詳しく述べています。 さて、彼らにとっての問題は、なぜそうすべきなのかということです。」 ここで取り上げた Toptal のプロジェクト マネージャーは、各自のスケーリング アクティビティ中にこのような質問に直面し、SAFe を使用してアジャイル変革を進める独自の方法を見つけました。

価値の実証

チリのサンティアゴにある Toptal プロジェクト マネージャーの Alvaro Villena は最近、クロスビジネス プラットフォームを開発するポートフォリオの SAFe 移行を完了しました。 「私の移行における最初のマイルストーンは、バリュー ストリーム ワークショップを実施することでした」と彼は言います。 簡単に言えば、バリュー ストリーム ワークショップは、コンセプトから提供までのビジネス プロセス全体と、その間のすべてのステップ、ユーザー、システム、および問題点を特定するためのキックオフ ミーティングです。

企業全体の代表者をワークショップに参加させることで、Villena は企業文化と彼の障害が何であるかを理解することができました。 「ワークショップを実施する前は、あるビジネスにチームがあり、別のビジネスにチームがあり、次のビジネスにチームがあり、3 つが互いに話し合うことはありませんでした。」

Villena は、すべてのチームが同様の問題点を共有しているものの、解決策については協力していないことに気付きました。 たとえば、ポートフォリオ内のすべての企業が製品を出荷しましたが、追跡システムを開発したのは 1 社だけでした。 誰も知識を共有していないことを除いて、全員がそれを使用できない理由はありませんでした。 ワークショップで彼らが話し始めると、チーム、企業、製品所有者の間で知識が流れ始めました。 「そのような会話は、プログラムにとって非常に強力でした。 それは素晴らしい出発点でした」と Villena は言います。 DevOps、設計、および製品のすべてが他のチームが何をしているかを知っているとき、彼らは社内に使用できるソリューションがあることに気づきます。 「彼らは『どうやってそれを手に入れられるの?』と尋ね始めます。 そして、そこに踏み込んで、『このプロセスに従ってください』と言うのです。」

「理由がわかるまで、誰も変化を望んでいません。 ですから、理由から始めて、より良い未来を彼らに与えてください。」 SAFeの生みの親、ディーン・レフィングウェル

レフィングウェルは、チームが抵抗する場合があることを知っています。 「理由がわかるまで、誰も変化を望んでいません」と彼は Toptal に語っています。 「だから、理由から始めて、彼らにより良い未来を与えるのです。」 チームがどれだけ効率的になれるかを垣間見せることは、リーダーシップを変えるための強力なツールです。

全員が熱心に参加している場合でも、困難なスタートを期待する必要があります。 たとえば、従来のウォーターフォール開発や大規模なリリースに慣れているチームは、その価値を理解していても、より反復的でアジャイルな開発プロセスに移行するのに苦労する可能性があります。 「私たちが行った最初のプログラムのインクリメントは、チームにとって一種の惨事でした」と Villena は言います。 そして、私たちはそれが起こることを知っていました。 最初の 3 か月は難しいかもしれないとクライアントに伝えました。」 これを補うために、彼は、チームが進捗状況を評価できる最初のプログラム増分 (PI) の最後に、1 週間に 1 回の反復を組み込みました。 彼は、通常の検査と適応を超えるプロセスの改善と評価のみに専念するスプリントを組織しました。 彼は、製品だけでなくビジネスの移行にもアジャイルの考え方を適用し、時間をかけて一歩下がって、何が機能し、何が機能しなかったかを確認し、それに応じて調整することが有用であることを発見しました。

小さな勝利を生み出す

SAFe の採用において予期しない障害に備えておくことが重要です。 数年前、セルビアのベオグラードに住む Toptal のプロジェクト マネージャー Miroslav Anicin は、通信会社を SAFe に移行していました。 その会社はすべてのソフトウェア開発を外注していた. オフサイト チームを組み込むことは、特に面倒な作業ではありませんでした。関連する問題は、主にロジスティクスに関するものでした。 しかし、この取り組みは、会社自体の移行において予期せぬ課題を生み出しました。 「リリーストレインで必要な能力を探していました」と彼は言います。 「そして、私が選ばなければならなかったのは、マーケティング、法務、製品、財務のすべての人でした。アジャイルの考え方や、アジャイルの経験さえまったくありませんでした。」

経営陣がアジャイル チームを扱った経験がないことが明らかになりました。 分散型の意思決定では、管理者がある程度のコントロールを放棄する必要があります。実際、アジャイル フレームワークの経験がない場合、リーダーは躊躇する可能性があります。 これを解決するために、Anicin はボトムアップとトップダウンでトレーニングを行い、チームと共にリーダーを指導する必要がありました。

このようなより分散化された意思決定への移行には、「コマンド アンド コントロールから、サーバント リーダーシップを通じて、力を与える学習の文化とアジャイルの文化、そして間違いを許容する能力へと働き方を変えることが必要です」と Leffingwell は言います。

Anicin は、小規模なアジャイル プロジェクトを SAFe フレームワーク内ではなく、単一のチーム内で実行することで、段階的にスケーリングするプロセスを開始しました。これにより、個々のチームは実践的な経験を積むことができました。 これらのプロジェクトは、重要ではなく、最初の試みで何か問題が発生しても会社に損害を与えない程度に小規模である必要がありましたが、そのアプローチで何が達成できるかをチームに示すのに十分有用である必要がありました。 たとえば、マーケティング チームは社内のマーケティング キャンペーンを作成し、その間にアニシンがスクラムの基本を教えました。 Villena のワークショップと同様に、これらの小規模なプロジェクトはアジャイルの価値を実際に示しているため、チーム メンバーとリーダーは、本格的な移行の前に短期間のリリースと継続的な改善の利点を確認できます。

チームのニーズを満たす

パリを拠点とする Toptal のプロジェクト マネージャーである Imane Marouane は、大規模な多国籍金融機関の変革を主導したとき、個々のチームが堅実な仕事を生み出したものの、全社的なビジョンを共有していない混沌とした環境に足を踏み入れました。 「各チームには独自の優先順位がありました。 各プロダクト マネージャーは、自分の製品が最初に納品されることを望んでいました。」

この問題に対する SAFe のソリューションは、加重最短ジョブ ファースト (WSJF) モデルで見つけることができます。 WSJF は、仕事の優先順位付けの基準を提供しているため、次のタスクを決定するとき、最初のステップで重要度をランク付けする方法について議論することはありません。 フローベースのアジャイル システムでは、一度にすべてを提供することを心配する必要はありません。 そして、それは、最も価値のある仕事は何かというよりも、答えるのがはるかに簡単な質問です。」 SAFe は、チーム間の依存関係を解決する方法を提供します。この結果には、タスクの順序付けが不可欠です。

Marouane 氏が依存関係を解決するまでの道のりは不確かなものになりました。 PI 計画で定義された依存関係が守られていなかったため、別のチームからの貢献の準備ができていなかったため、あるチームの作業を開始できませんでした。

「これが最初のイテレーションであり、チームがこの種の作業に慣れていなかったため、追加のセレモニーを実施することにしました。依存関係の進捗状況について話し合う毎週のミーティングです」と Marouane 氏は言います。 「各チームから 1 人が参加し、貢献の進捗状況を更新しました。」 このようにして、チーム A が提供できないと言った場合、チーム B は、スプリントの開始時に実現しない貢献を待つのではなく、前もってそれを知り、それに応じて計画することができます。

Leffingwell は、SAFe にこの種の調整を行う際の注意を説きます。 … 適応させることはできますが、十分に注意する必要があります。」 フレームワークは適応可能であることを意図していますが、再評価しないと変更が組み込まれる傾向があります。 Essential SAFe 構成は、変更が基本的な基準を満たしていることを確認するために存在します。

マルアンの余分なセレモニーは 2 番目の PI に再び含まれ、3 番目の PI までに段階的に廃止されました。 チームは、まだ伝えられていないことについて報告するものは何もありませんでした。 Marouane 氏は、柔軟性を少し高めたことで、チームを従来のプロセス トラックに戻すことができました。 彼女は、金融機関のチームを最大限に活用するには、移行自体にアジャイルな考え方が必要であることを発見しました。 そして重要なことに、彼女が行った変更は、継続的な改善へのコミットメントを通じて、最終的に Essential SAFe の基盤であるリーン アジャイルの原則に役立ちました。 彼女のソリューションは、会社に欠けていた統一されたビジョンを与え、チームが同じ優先事項に向かって協力できるようにしました。

将来に適応する

大規模に運用されているフレームワークには、課題が伴います。 可動部品と競合する利益の数は計り知れません。 しかし、その見返りも同様に大きく、適切に実行された移行により、チームは共通の目標に向かって作業するために必要なツールを手に入れることができます。 このような大規模な実装で直面する障害は予測不可能であり、アジャイルな考え方は、Villena、Anicin、および Marouane が予期しない課題に適応するのに役立ちました。 継続的デリバリーの目的は、不測の事態に適応するためのツールを使用してプロセスを強化することです。

Scaled Agile は、必要に応じて新しいツールと機能を導入し、新しいテクノロジーと進化する業界標準にも適応します。 誰もが機敏さを保ち、不測の事態に備える必要があります。 「水晶玉はありません」とレフィングウェルは言います。 「私たちは速く走り、一生懸命リードし、一生懸命フォローし、できるだけ速く書きます。」