最後のアップデート以降、スクラム拡張はどうなっているのだろうか?私たちも知りたかったので、Scrum.orgでビジネス開発担当VPおよびプログラムディレクターをつとめるAlex Armstrong氏にコンタクトした。以下に彼が話したことをまとめる。
達成したことこの1年ほど耳にしてきたニーズに対する解決策として、スクラム拡張に関心があることが確かめられました。最新の提案には、投稿されてから24時間で18ものコメントが集まりました。私たちは1ダースを超える提案を受けとっていますが、そのうち3つがパブリックレビューおよびフィードバックのための準備段階にあります。学んだこと「スクラム拡張」というアイデアはまだ比較的新しいものです。受けとった拡張提案の多くは、スクラムフレームワーク内で何かを達成するための具体的アプローチというよりも、ソフトウェア開発のベストプラクティスに近いものでした。それぞれ、たとえば「特定のコンテキストで効率的にスプリントレビューミーティングを実施する具体的なアプローチ」、「TDD(テスト駆動開発)」といったものだと考えてください。私たちはみなさんがこうした提案を真剣に持ってきていることも学びました。このことは、拡張を提案する人たちに対するアドバイザーとしての私たちの仕事が極めて重要であることを思い出させてくれます。こうした拡張には議論が必要になりますが、これはスクラムを前進させるのに役立つ、非常にポジティブな一歩だと思います。最後に、これはゆっくりとしたプロセスになりそうだ、ということを学びました。みなさん非常にすばらしい質問をしています。そうした質問の多くは検討に値するものです。こうした提案を公式に発表するまでに、拡張の提案者らは全スクラムコミュニティの懸念に取り組む時間が必要になります。次のステップこれからも学び続けます。みなさん関心があることはわかりましたが、このアプローチが説得力をもってニーズを満たせるのか、まだ判断しているところです。私は先週AgileNZカンファレンスで講演したのですが、そこでスクラム拡張のアイデアを紹介しました。聴衆はそのアイデアと目的を理解してくれて、私はこれまで聞いたことのない非常にすばらしい拡張アイデアをたくさん受けとりました。ほかの人たちがベースラインとして使うのに十分なサンプルが集まるまで、こうしたコミュニティに対する直接的な活動をもっとやっていくつもりです。
Alex氏: スクラム拡張に対する反応を見ると、2つの派閥があるようです。ひとつは「スクラムの実施方法」の説明書を切望しているようです。その多くはスクラムガイドにあったもので、削除されたものです。もうひとつは、誤解や誤用をまねくようなスクラムの具体的ガイダンスといったものにうんざりしているようです(積荷信仰の導入)。
Alex氏: それは私たちのゴールではありません。拡張はスクラムを強化するためではありません。拡張とは単に、スクラムフレームワーク内で機能するコンテキスト固有のプラクティスのことです。たとえばスプリントバックログは、そのスプリントのためにプロダクトバックログから選択した項目と、それらをプロダクトインクリメントとして届けてスプリントゴールを達成するための計画とを合わせたものです。スプリントバックログのひとつの表現方法は、プロダクトバックログの項目を、完了させなくてはならないタスクのリストに分解することです。ほかにも、パスさせなくてはならない失敗するテストのリストを作る、という表現方法もあります。現在どちらのアプローチもチームによって使われており、どちらもスクラムフレームワークにとって有効な拡張になるでしょう。
Alex氏: スクラムには、よいもわるいもありません。スクラムはスクラムです。あらためて去年、Ken氏はこのポイントについてすばらしいブログ記事を書きました。その拡張によって実際にチームがもっと利用可能で有用なソフトウェアを顧客に届けられるのなら、承認される見込みがあります。