再訪ありがとうございます!

なんどもご来訪くださりありがとうございます。わたしたちにお手伝いできることはありませんか?ぜひご意見やフィードバックをいただければ幸いです。

翻訳記事

本記事は、Barry Overeem さんによる「Mind The (Scrum) Gap!」の翻訳です。翻訳・公開は、Barry  さんの許諾を得ています。誤字脱字・誤訳などありましたらぜひご指摘ください。

はじめに

スクラムのコミュニティメンバーとしておよそ12年間経ちました。この間、LinkedIn、Medium、TwitterなどのSNSでのスクラム関連のスレッドの多くには明確なパターンがあることに気がつきました。コミュニティとして、私たちはチームや組織の誤りである痛いところを突くことに長けています。また、スクラムの理想的な状態と対比させることも得意です。その意見が強ければ強いほど、より多くの議論を引き起こし、「いいね!」が増えていきます。

良いスクラム」対「悪いスクラム」の例えとして、私たちは皆、同意をしているように思えます...。

良いスクラム悪いスクラム
プロダクトオーナーは、プロダクトに関する意思決定の全権限を持っているプロダクトオーナーは、何の権限も持ち得ていない受注者である
スクラムマスターは、組織全体の変化を推進するスクラムマスターは、書記、スクラム警察、ツール屋さん、ミーティング開催者である
各スプリントには、明確で具体的、かつ説得力のあるスプリントゴールが設定されている各スプリントでは、プロダクトバックログを完成させることだけが目標である
スクラムチームは頻繁にステークホルダーと関わりを持っているステークホルダーがいる場合、そのステークホルダーと関わるのはプロダクトオーナーだけである
スクラムチームは、早期に頻繁にリリースし、仮説を検証しているスクラムチームは、四半期に一度しかリリースしないので、その度に苦痛を強いられる
スクラム
プロダクトオーナーは、何の権限も持ち得ていない受注者である
プロダクトオーナーは、何の権限も持ち得ていない受注者である

これらが本当にスクラムチームにとってどれだけ役に立つのかが疑問です。私にとって非常に明確なことは、多くのスクラムマスター、トレーナー、コンサルタントがオンラインで議論することに喜びを感じているということです。しかし、スクラムチームのメンバーや実際にスクラムを成功させたいと考えている組織にとって、どれほど役に立つのでしょうか?このような記事を読むと、楽しいと思うかもしれません。また、「悪いスクラム」と表現されるものを認識し、「良いスクラム」と表現されるものに同意することもあるでしょう。

問題は、チームの現状と望ましい状態の間に大きなギャップがあることが多く、ほとんどの記事では、実際にギャップを埋める方法については説明していないことです。また、チームがその方法を見つけですためのニュアンスにも欠如しているのです。その結果、チームはさらに不満を募らせ、なぜスクラムを用いる必要があるのかと考えるようになるのです。このような偏った言説が、まさに多くのチームや組織をスクラムやアジャイルから遠ざける原因になっているように思えるのです。これが、私たちがスクラムコミュニティとして望んでいたこととは思えません。

スクラムチームを支援するためのより良い方法があると信じています。より役に立ち、スクラムのフレームワークのルールに妥協せず、多くのチームや組織が直面する厳しい課題を認識する代替アプローチがあるはずです。この記事では、この代替アプローチについての考えを述べています。これは、Christiaan Verwijsと私が過去数年間に取り組んできたものです。

それが重要な理由

現状を改善するべきと認識しながらも、その方法(HOW)がわからない場合、3つの事態が発生する可能性があります。

  1. スクラムチームが、もう「スクラムの鏡」を見なくなる
  2. スクラムチームが、ベストプラクティスのみでそのギャップを埋めようとする
  3. スクラムチームが、意味のない改善しかしない

もう少し詳しく探索してみましょう。

#1. スクラムチームが、「スクラムの鏡」を見なくなる

Ken Schwaber氏の有名な言葉に「スクラムはあなたの姑のようなもので、あなたの欠点をすべて指摘してくれる」というものがあります(参考文献が見つけられませんでしたが)。言い換えれば、スクラムフレームワークは、チームや組織におけるスクラムの状態について透明性を高めるための鏡なのです。問題を解決するのではなく、問題を痛感させるのです。どのような解決策が自分たちの状況に最適なのかを見極めるのはチームや組織にしかできないのです。これは理にかなっていて、とても良好です。しかし、もしスクラムチームが、非常に困難組織の阻害要因を解決するのに苦労をしているとしたら、鏡を見るのが非常にもどかしくなってきます。改善するための指針がなければ、おそらくチームはもう鏡を見ることはないでしょう。現実はあまりにも厳しいものです。

もしスクラムチームが、非常に難しい組織の阻害要因を解決するための改善に苦労しているとしたら、鏡を見るのが非常に辛くなる
もしスクラムチームが、非常に難しい組織の阻害要因を解決するための改善に苦労しているとしたら、鏡を見るのが非常に辛くなる

#2. スクラムチームが、ベストプラクティスのみでそのギャップを埋めようとする

スクラムのフレームワークは意図的に不完全なもので、スクラムの理論を実現するために必要な部分のみを定義しています。スクラムのフレームワークは、チームが有用と考えるさまざまなプロセス、テクニック、手法を盛り込むためのフレームや構造を提供するということです。そしてこれは理にかなっているのです。複雑な環境においては、ベストプラクティスは存在しません。それぞれのチームや組織が異なっているのです。Aという組織ではとてもうまく行ったプラクティスが、Bという組織ではまったくうまくいかないかもしれないのです。複雑さには、予測不可能なことが伴うのです。そのため、チームは小さな実験を行い、何が自分たちにとって最適なのかを見極める必要があるのです。

私は、改善をしようとしないチームに出会ったことはありません。必要な変化を起こす方法(HOW)を知らない多くのチームと仕事をしてきました。改善したいという内発的動機がありながら、改善方法についての知識がないため、スクラムコミュニティとして勧めるものに依存するのです。残念ながら、「悪いスクラム」と「良いスクラム」の間のギャップを埋めるためのベストプラクティスをたくさん見つける可能性が高いのです。「Spotifyモデル」が最も有名な例でしょうが、他の例としては、SAFe(本質的には、大規模なベストプラクティスのコンテナ)、または単に、ストーリーポイントやスプリント0(ゼロ)、準備完了の定義(DoR: Definition of Ready)を用いることがあるでしょう。

これらのプラクティスが必ずしも悪いというわけではありませんが、複雑なシステムという性質上、「モデル」や「ベストプラクティス」は存在しないのです。結果だけを真似るだけでは、複雑な課題を解決するために必要な「学ぶ能力」は身につきません。

結果だけを真似るだけでは、複雑な課題を解決するために必要な「学ぶ能力」は身につかない
結果だけを真似るだけでは、複雑な課題を解決するために必要な「学ぶ能力」は身につかない

#3. スクラムチームが、意味のない改善しかしない

私は、どのスクラムチームも改善したいと思っていると確信しています。先述したように、問題はすべてのチームが改善の方法(HOW)を知っているわけではないということです。標準化されたモデルやベストプラクティスを導入するだけでは、スクラムチームは無意味な改善点を洗い出してしまうかもしれません。例えば、デイリースクラムの時間を変更してみようとか、2週間でインクリメントを作るのは難しいので3週間スプリントを試してみようとか、デジタルホワイトボードとして他のツールを使ってみようとかが挙げられます。これらの改善には十分な意図がありますが、スクラムチームの効果性に大きな影響を与えるものではありません。また、スプリントごとに潜在的にリリース可能な価値のあるインクリメントを提供するというスクラムの本質に直接触れるわけでもないのです。

もう一つの例は、私たちの著書『Zombie Scrum Survival Guide(ゾンビスクラムサバイバルガイド)』の中で私たちが「ハッピークラッピースクラム」と呼ぶようになったものです。ここでは、スクラムチームが、オンラインにある多くのゲームやファシリテーションのテクニックを活用して、スクラムイベントをできるだけ楽しく、軽快に、活気あるものにすることにエネルギーを注いでいるのです。このような現象は、チームが阻害要因に影響を与えることができないか、その方法を知らないために、意図的な改善が表面的なものに留まってしまう場合によく起こります。参加型の魅力的な環境を作ることには、大きな価値がありますが、チームが実際に成果を検査し、フィードバックに基づいてプロダクトやアプローチを適応させていないのでは、何の役にも立ちません。スクラムイベントを、検査と適応を妨げる大きな阻害要因を取り除く機会として使うのではなく、スクラムチームが、ゾンビスクラムの荒地の中で次のスプリントを生き残るためにメンバーの再活性化に集中してしまうのです。

「ハッピークラッピースクラム」は、チームが阻害用に対して影響を与えることはできないか、その方法をしらないために、意図的な改善が表面的なものに留まってしまう場合によく起こる
「ハッピークラッピースクラム」は、チームが阻害用に対して影響を与えることはできないか、その方法をしらないために、意図的な改善が表面的なものに留まってしまう場合によく起こる

「ゾンビスクラムと同じことをしていないか?」

私たちの書籍『Zombie Scrum Survival Guide(ゾンビスクラムサバイバルガイド)』では、ゾンビスクラムの原因について深く掘り下げています。さて、「おいおい、お前らもゾンビスクラムの概念と全く同じことをやっているのではないか?」と思われるかもしれませんね。そうですね。ゾンビスクラムは先述の「悪いスクラム」と比較できますし、私たちの言う健全なスクラムは、「良いスクラム」と似ています。また、ゾンビスクラムからチームが立ち直るための超実践的な実験も数多く提供している点が異なっています。これらの実験では、ベストプラクティスを提供するわけではありません。しかし、それぞれの実験によって、チームは自分たちの現状について透明性を確保し、検査し、適応することができるようになるのです。書籍で紹介した実験に加えて、65個以上のDIYワークショップを作成しました。それぞれのワークショップでは、チームが阻害要因を解決し、スクラムをより効果的に用いることができるように、完全に準備された一連のリベレイティングストラクチャーが含まれています。

私たちの実験やワークショップでは、標準的なモデルやベストプラクティスを提供することはありません。私たちは、チームとして持続可能な阻害要因についての透明性を確保し、一緒に状況を検査し、それに応じて適応させていく仕組みを提供しています。多くのチームにとって、これは依然として難しいことではあります。ワークショップは、チームが「ゾンビスクラム」と「健全なスクラム」の間のギャップを縮めるのを支援することを意図していますが、何を適応・改善するべきかを決めるのは難しいままです。チームが正しい方向に進むために、まずできることは何でしょうか?

この課題に取り組むスクラムチームを支援するために、私たちはスクラムチーム調査を開発し、65のDIYワークショップを収録し、さらに、125以上のクイックヒントを作成しました。このように、スクラムチーム調査は、チームが現状を診断でき、その結果を一緒に検査し、次の具体的なステップと有意義な適応策を特定することを手助けしてくれます。

代替アプローチの一つ: クイックヒント!

私たちは、15%ソリューション(15% Solutions)がとても役に立つことを発見しました。Gareth Morganは、これらを「他者からの承認やリソースがなく、完全に自分の裁量で行動できるあらゆる最初のステップ」と定義しています。やろうと思えば、今すぐ始められることのことです。究極の解決策ではないかもしれませんが、正しい方向への第一歩であることは間違いないでしょう。

スクラムチーム調査では、これらの15%ソリューションを「クイックヒント」と呼んでいます。クイックヒントの目的は、スクラムチームにおける小さな、そして漸進的な変化を呼び起こすことなのです。阻害要因を取り除き、コラボレーションを改善し、リスクを管理し、価値を素速く提供するための正しい方向への小さなステップなのです。

クイックヒントの目的は、スクラムチームに小さな、そして漸進的な変化を呼び起こすことである。阻害要因を取り除き、コラボレーションを改善し、リスクを管理し、価値を素速く提供するための正しい方向への小さなステップである。

これらのクイックヒントで、スクラムチームは、「unstuck(行き詰まりを取り除く)」することができます。さらに良いことにKent Beckの著書『エクストリームプログラミング』では、「適切な条件下では、人々やチームは多くの小さなステップを素速く踏み出すことができ、それはあたかも跳躍しているかのように見える」と述べています。

「15%ソリューション」で小さく始めることで、大きな変化を引き起こしす。スクラムチーム調査では、これらを「クイックヒント」と呼ぶ
「15%ソリューション」で小さく始めることで、大きな変化を引き起こしす。スクラムチーム調査では、これらを「クイックヒント」と呼ぶ

クイックヒントの10例

クイックヒントの10例で具体的に説明することとします。それそれのヒントは、異なる領域に焦点を当てています。ご覧の通り、これらはスクラムチームにとって究極の解決策ではなく、チームが正しい方向に進むための手助けをすることを目的としています。私たちは、これが非常に強力であることを学びました。チームが継続的改善の流れに乗れば、チームのモラルと幸福感は高まり、最も頑強な阻害要因さえも取り除くことが可能になることが見込めます!

  • 品質向上のクイックヒント:
    3人の重要なステークホルダーにインタビューを行い、どのようにすればプロダクトの品質を向上させることができるかを彼らから学ぶ。
  • 心理的安全性改善のクイックヒント:
    次のスプリントレトロスペクティブで、「現在チームとして行なっていないが、本当は行うべき会話は何でしょう」と尋ねる。そして、その会話を行う!
  • 自己管理向上のクイックヒント:
    現在の仕事のやり方で、チームとして足枷になっている点を1つ選ぶ。あるスプリントの間、それをやめてみる。スプリントレトロスペクティブで、何が改善され、何が悪化したかを振り返る。
  • クロスファンクショナル(機能横断的)向上のクイックヒント:
    次のスプラインとでは、仕掛かり作業(WIP)をチームメンバーの3分の1以下に制限することに合意し、そのアイテムをできるだけ創造的に共同作業する。
  • マネジメント支援改善のクイックヒント:
    次のデイリースクラムの後に、10分ほど時間をとって「マネジメントが適切な領域で私たちを支援してくれているかどうか、どうすればわかってもらえるか?他に何が必要だろうか?」を尋ねる。協力して、1つの改善点を見つける。
  • チームの自律性向上のクイックヒント:
    次のスプリントでは、通常チーム外の人が行うはずの決定を1つ行なってみる。その後、その人に報告を行うようにしてみる。
  • リファインメント改善のクイックヒント:
    プロダクトバックログのどのアイテムが最も明確でないかを投票する。次のスプリントでは、プロダクトオーナーと一緒にこれらのアイテムのうち3つを明確にするようにする。もしくは、これらを削除する。
  • チームモラル向上のクイックヒント:
    次のスプリントでは、プロダクトオーナーと協力して、プロダクトゴールを大きなバナー(カンバンや垂れ幕)に書いて、チームルームの目に見えるところに貼る。
  • スプリントゴール改善のクイックヒント:
    次のスプリントでは、チームが、スプリントゴールに合わないような重要ではない要求が来たら丁重に「いいえ(No)」と言えるようにする。
  • 価値集中向上のクイックヒント:
    少なくとも3人のステークホルダーとプロダクトバックログを共有し、どのアイテムが最も価値が低いと考えているかを尋ねる。自分でも説明できないようなアイテムは削除する。

すべてのクイックヒントは、スクラムチーム調査に含めています。この無料プロダクトにより、スクラムチームは、科学的に検証された広範囲な調査によって自分自身を診断し、完了時に詳細な結果とエビデンスベースなフィードバックを受け取ることができます。25のトピックに対するそれぞれのクイックヒントを得ることができます。

終わりに

この記事では、多くのスクラムチームが意味のある改善を特定するのに苦労しているのを見るにつけ、私の考えを述べてみました。スクラムの現状と理想の状態にはギャップがあることが多く、多くのチームがそのギャップを埋める方法を知らないのです。私たちのクイックヒントでは、代替アプローチを提供しています。良いクイックヒントとは、短く簡潔で、実行可能で具体的、大胆で勇気が必要で、簡単に使えて試せるものなのです。クイックヒントを作成することは、簡単そうに見えて、実はとても難しいことなのです。小さく具体的な改善点を見つけ出すには、別の種類のリファインメントスキルが必要です。

この記事で紹介した改善点からインスピレーションを得て、次のスプリントレトロスペクティブで新しいクイックヒントをチームと作ってみるのはどうでしょうか?さらに良いのは、まずスクラムチーム調査を用い、仮説ではなく、実際のデータに基づいて改善を行いませんか。もし新しいクイックヒントがあれば、遠慮なく共有してください。一緒に学び、成長しましょう!

本記事の翻訳者:

長沢智治

長沢 智治 - アジャイルストラテジスト

サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。

PSPO II - Professional Scrum Product Owner II
PSPO I - Professional Scrum Product Owner I
PSM II - Professional Scrum Master II
PSM I - Professional Scrum Master I
PSD I - Professional Scrum Developer I
PAL-EBM - Professional Agile Leadership - Evidence-Based Management
PAL I - Professional Agile Leadership I
SPS- Scaled Professional Scrum
PSU I - Professional Scrum with User Experience
PSK I - Professional Scrum with Kanban I
PSF - Professional Scrum Facilitation Skills
PSPBM - Professional Scrum Product Backlog Management Skills
認定スクラムマスター
DASA Accredited DevOps Trainer
DASAアンバサダー

『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。

Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。

プロフィール