スクラムはシンプルでライトウェイトな手法だ。スクラムの発案者で共同作者のJeff Sutherland氏は、「スクラムは根本において、シンプルなアイデアに基づいています」という。認定スクラムトレーナーでAgile Pain Relief Consultingの創業者兼コンサルタントのMark Levison氏は、スクラムだけでは十分とは言えないとブログで述べている。
長期的にスクラムでうまくやるには、基本的なフレームワーク以上のものが必要です。これは意図的なものです。スクラムは出発点としての枠組みを提供しますが、他の効果的なパターンと合わせて適用することで、もっとうまくいくように作られているのです。
Charles SchwabのマネージングディレクタであるChrista Conner氏も、アジャイル導入の失敗はスクラムしか考えていないことだとブログで述べている。
スクラムは非常に人気があります。別の組織の知り合いに聞いてみると、90％以上が何らかの形でスクラムを実践しています。彼らは、多くの組織で見られる典型的な導入プロセス、授業形式のトレーニングと付き添いのコーチングによる指導を受けています。ところが残念なことに、なぜかスクラムのうたうメリットが得られず、ひどく幻滅して終わることがあります。どうしてこんなことが起こるのでしょうか？ 私の回答は単純です。スクラムだけでは十分ではないのです。スクラムだけがアジャイルではないのです。
Coactivのリーンアジャイルコーチ、Christophe Keromen氏も「Organisation Agile? Scrum is not enough」というセッションをScrumDay 2015カンファレンスで行っている。
Mark氏はスクラムをこえて検討すべきプラクティスとして以下を提案している。
- 効果的なアジャイルエンジニアリングプラクティス – ユニットテスト、継続的インテグレーション、テスト駆動開発、受入テスト駆動開発（もしくはBDD）、ペアプログラミングなど。こうしたプラクティスを取り入れないと、次第にコードベースの健全さが落ちていく。
Christa氏もスクラムと合わせてXPのエンジニアリング手法を取り入れることを提案している。
テスト自動化、継続的インテグレーション、TDD、ジャストインタイム設計は、アジャイルが提供するべき真の価値を解き放ちます。スクラムは「毎スプリント終了後に潜在的にリリース可能なソフトウェア」を作る必要性を認めていますが、組織にそのためのノウハウがないと、目標は達成できません。
-
カンバン – チームや組織レベルでの仕事の流れを理解するのに役立つ。組織内の仕事の流れをよく理解していないと、局所的には改善だけれども、全体には害を及ぼすような変更をしてしまうおそれがある。
-
ポートフォリオマネジメント – ビジネスが次にどの仕事に注力したいのか、全体的な判断をする技術。プロダクトオーナーによって大きな優先順位が理解され、その順に取り掛かれるようにするため、組織はポートフォリオマネジメントを必要とする。
-
組織的改善 – スクラムによって見つかる多くの問題は、チームやスクラムマスターによって解決されるものではない。組織は、こうした問題の解決に専念する、継続的な改善チームを用意する必要がある。
-
チーム間調整 – チーム間の仕事を調整すること。チーム間調整のための最もよく知られたパターンとして、Scrum of Scrumsがある。
-
チームの組織 – コンポーネントチームやフィーチャーチームの組織方法。分隊、部隊、支部によるSpotifyモデルなど様々ある。
Mark氏は、スクラムは現在の組織と既存の構造を適合させることが目的ではない、と語る。何に取り組んでいるのか、何が改善に必要なのかを、私たちに考えさせることが目的なのだ。