「こうしてスクラムが終わってしまう」前にすべきこと
こうしてふりかえりは終わってしまった / A Demise of a retrospective
ふりかえりカンファレンスで一番面白かった発表資料です。
資料をざっくり要約すると
ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。
理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。
開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。
ふりかえりを廃止することでチームの成長は停止してしまうでしょう。
これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張ろうというのが論旨です。
また低コスト高リターンの課題を倒し尽くして停滞した状態を「高原(プラトー)」と呼んでいます。
「こうしてスクラムが終わってしまう」とはなにか？
上記の発表資料とおなじく、スクラム導入して低コスト高リターンの課題を倒し終えた開発チームが「もうスクラムで成長できることはないし、スクラムなんてなしでよくね？」と言い出したりあるいは「オレたちのスクラムは完成した」「オレたち流でスクラムをカスタムしていこう」と言い出す。
そうして成長が止まったりアンチパターンにどハマりしたりする状態を指します。
はいここから私の話
「低コスト高リターンの課題を倒し終えた開発チームが成長を止めてしまう」
これは同じ話を10年くらい前に川口さんがプロダクトバックログに関する話でもしていました。
私も最近のスクラムについても同じことを考えています。
つまり低コスト高リターンの課題を倒し尽くして停滞した「高原(プラトー)」のフェーズで停滞してしまうスクラムが多すぎるという問題です。
チームメンバーは多くの場合停滞しているにもかかわらず問題意識を感じてはいません。
なぜなら課題を倒し尽くしたために、学習ゾーンからコンフォートゾーンに移動し快適さを感じているからです。
また過去の成功体験から高い自己肯定感すら感じているケースも多く見られます。
ただいちいち「低コスト高リターンの課題を倒し尽くして停滞した「高原(プラトー)」のフェーズで停滞してしまうスクラム」というと長いので、ここでは プラトースクラム と呼びましょう
「プラトースクラム」とは
パッと見は完全に「機能しているスクラム」に見えます。
- スプリント（１〜２週間）単位で全てのスクラムイベントが１周します
- バックログはJIRA上などで管理されています
- スプリントの始めにはスプリントプランニングが、スプリントの終わりにはスプリントレトロスペクティブが開催されます
- また１日１回はデイリースクラムが開催されます
しかしプラトースクラムでは本来スクラムで行わねばならないことをできていませんし、できるようになる見込みも立ちません。
プラトースクラムでできないこと、やらないこと
- 開発チームがユーザーと直接話をする機会はない
- ユーザーインタビューは行われない。あるいは部分的にはプロダクトオーナーや、チーム外の人が行った結果をまとめた内容を見る機会はあるかもしれない
- スプリント期間より長期の計画をたてることはできない
- スプリントが終われば次のスプリントの計画を立てます。しかしそれ以上長い期間の計画を自分たちで立てることはありません。それは「壁の向こうから投げ渡されるもの」だからです。
前者はユーザーを見ていないことを意味します。
後者はPlanningに関して中期的に自律的なチームとして機能していないことを意味します。
いずれもスクラムチームとしてはかなり疑問符がつきます。
プラトースクラムにあって、本来のスクラムにないもの
開発計画とかマイルストーンとかロードマップとか言われる、期間とスコープが固定されたガントチャート式の上位計画がスプリント計画の上位に「変更不可能な上位存在」として君臨しています。
この「変更不可能な上位計画」が大きな問題を引き起こします
この上位計画によってスクラムで重要な要素のいくつかが機能しなくなります。
この問題を解決するには上位計画をスクラムチームが自分で立てられるようになるしかありません。
もちろんどうやればいいか？というアプローチは示されています。
名著アジャイルな見積りと計画づくりあたりを読めばいいでしょう。
- ヴィジョンを示すプロダクトゴール
- スコープ固定のリリースゴール
- タイムボックス固定のスプリントゴール
この３つのうちリリースゴールとスプリントゴールを開発チームが自力で立てられれば十分です。
しかしそれは不可能です。
上位計画を自分で立てられるようになることは、コストが高すぎるし難しすぎるし、なにより短期間でできるものではないからです。
ユーザーのことを見ていない、という点もこれに拍車をかけます。
となると期間とスコープが固定された上位計画に基づいてプラトースクラムのチームは動くしかありません。
その場合スクラムに必須の要素のいくつかが機能しなくなります。
プラトースクラムでは機能しないスクラムに必須の要素
スプリントゴール
miholovesqさんがよく要約されているスプリントゴールは機能しなくなる要素の最たるものです。
何しろ上位計画で期間とスコープが固定されているのです。
期日までにクッソ長いチェックリストに書かれたものはすべてこなさなければなりません。
となると本来のスプリントゴールの代わりに、「スプリントゴールと呼ばれる進捗目標」をスクラムチームは目標とせざるを得ません。
フィードバック
フィードバックとは、今進んでいる方向を維持するか、あるいはやめるかを判断する重要な指標です。
落語家がマクラと呼ばれる小話の反応を見て本題を何にするかを決めるように、スクラムチームもフィードバックを得て全力を投入する方向を決定します。
しかしプラトースクラムは前述の通り固定的な上位計画に基づいて動きます。
であればフィードバックとして得られるものは「現在計画より進捗がどれだけ遅れているか？」だけです。
それを聞いたところで変わるのはどれだけ残業すればいいかの見込みだけでしょう。
リリース計画
プラトースクラムにおいては固定的な上位計画が最重要視されます。
段階的にリリースし、フィードバックを得てゴールを修正し、市場やユーザーと対話しながら探索的にプロダクトを作り上げていくために必須のリリースゴールはプラトースクラムには必要ありません。
最終的に何を作り上げるかというスコープと、いつまでにリリースするかという点はすでに固定的な計画で事前決定されています。
であれば細かくリリースしようが最後の段階で一気にまとめてリリースしようが大した違いはありません。
市場やユーザーが何を言おうが、固定的な計画は変更されないからです。
フロー効率とスウォーミング
上の「フィードバック」「リリース計画」に同じです。
市場やユーザーのフィードバックに耳を貸さないのですから、早くリリースすることにも意味はありません。
早くリリースすることに意味がないのですから、フロー効率とスウォーミングにも何の意味もありません。
むしろ固定的な上位計画に重要になるのはリソース効率です。
リソース効率と両立し得ない「フロー効率とスウォーミング」は固定的な上位計画にとって有害でしかありません。
インセプションデッキ
固定的な上位計画は開発チームのマインドを社内受託に最適化させていきます。
そんなチームにWhyを考えるために最重要なインセプションデッキは不要です。
社内受託型の開発チームに必要なものはWhatとHowだけだからです。
考える必要のないWhyのために開発チーム全員を２〜３日も拘束するインセプションデッキは工数を食い潰すだけです。
まとめ
おっと筆が乗って話が長くなってしまいました。
プラトースクラムで重要な点は「パッと見はスクラムとして機能しているように見える」にもかかわらず、スクラムに必須の重要なプラクティスを機能不全に陥らせます。
それどころかスクラムに最重要な開発チームが自律的な計画を立てられるようになる点を阻害し、マインドセットを社内受託へと歪めていきます。
誰にも悪意がないとしても、プラトースクラムは本来のスクラムに移行するためには有害なのです。
もう１つ重要な点があります。
プラトースクラムは変更不能な固定的な上位計画に支配されています。
固定的な上位計画という時点で分かる通り、古めかしいウォーターフォール的な考え方に基づくものです。
なのでプラトースクラムは古典的なウォーターフォールの弊害が組織が大規模化したときに顕現します。
開発組織がCTOとかVPoEとか呼ばれるトップの下で３〜４階層にも及ぶ組織図を形成する頃にはひどいことになっているでしょう。
なにより、企業という生き物は常に株主から組織を大きくするよう圧力を受け続けます。
そのためよほど頭を使って努力しない限り、組織は従来よりも変化への耐性が低いメンバーによって肥大化し続けます。
この問題を解決するためには、中間組織に権限移譲して自律的に動かせればうまくいくかもしれません。
でもそれって「本来のスクラム」で目指したことですよね？
それができなくてプラトースクラムに留まり、構成員のマインドセットを固定的な上位計画とガントチャートに従う社内受託に最適化させてしまっているんですよね？
ということは中間組織に権限移譲なんてフロムゲームの最高難易度級であることはあきらかですよね？
なによりこういうチームはつまらない
組織の規模が大きくなるにつれて、各チームの裁量は削減され、固定的な上位計画に基づいて進捗を出すことを常に求められるようになります。
それでいてチームの成長は停滞し、進歩することもやめてしまったためにチームとして成長している感じがありません。
向上心のある個人としては「退屈」に感じるでしょう。
なにしろ裁量がない上に成長していないのですから。
もしあなたが会社の偉い人か、開発組織の偉い人なら
早めに決める必要があります。
組織が大規模化して組織の動脈硬化が起きる前に。
中間管理職やメンバーのマインドセットが固定的な上位計画とガントチャートに従う社内受託に最適化してしまう前に。
本来のスクラムのような、中間組織に権限移譲して自律的に動く開発組織にしたいのか。
それともプラトースクラムのような、古典的なウォーターフォール脳に基づいて動く「ガワだけアジャイル」となり、そして大規模組織と古典的なウォーターフォールがもたらす弊害と闘病する開発組織にしたいのか。
その自律的な開発組織ってやつを作るにはどうすればいいんだよ
最初に引用したこうしてふりかえりは終わってしまった / A Demise of a retrospectiveと大して変わりありません
コストが高く、難しい課題に恐れず立ち向かうようスクラム組織をエンパワーするのです。
コスパの良い課題を倒しきったのでコンフォートゾーンに安住したい開発チームを、学習ゾーンに留まるようエンパワーさせる必要があります。
これは管理職やマネージャー、特に上級であるCTOやVPoEの仕事でもあります。
もしメンバーならどうすれば良いか？
開発チームや開発組織全体の雰囲気としてプラトースクラムに留まりたいという雰囲気がある場合
あるいは上記のガワだけアジャイル状態なのに「守破離の破にうつりたい」という雰囲気を出し始めたとき。
単なるヒラのメンバーにできることはありません。
学習ゾーンに留まりたいなら、コンフォートゾーンのぬるま湯につかることをよしとしないなら、転職しか選択肢はないでしょう。
といっても向上心の高いメンバーは言われなくてもそのうちそうしてしまうに違いありませんが（経験談）
それはすなわちCTOやVPoEにとって、プラトースクラムを続けることは向上心のあるメンバーに対して流出するよう促すことと同義なのです。
Discussion