#Book ## 🎯目的 [[🗃️スプリントゴール]]を描くことの重要性は理解できるのだが、実際に[[🗃️スプリントゴール]]を設定するのは難しい。以下を明らかにしたい。 - そもそも[[🗃️スプリントゴール]]はなぜ必要なのか？ - どのように[[🗃️スプリントゴール]]を設定して、チームに根付かせていくのか？ ## 💭感想 この本を読んで私は以下のことを頻繁に言うようになると思う。 ①[[🗃️謙虚な計画]]を立てよう ②計画ではなく、意図に従おう。やること(ToDO)ではなく、意図を伝えよう。([[🗃️司令官の意図]]) ③アウトプットではなく、[[🗃️アウトカム]]を大事にしよう([[🗃️フィーチャー工場]]にならないようにしよう) [[🗃️スクラム]]の話が多くて、学びも多いが、仕事の向き合い方全般に言える話だと思う。 [[🗃️価値の不確実性]]があることを、どうしても忘れてしまってアウトプットにフォーカスが行きがちになる。 アウトプットがそのまま成果として見られてしまうと、過度なタスクリストが生まれて、工夫の余地がなくなり、働き過ぎや余裕がない状態となり疲弊していく。 [[🗃️スプリントゴール]]という話を通して大切なのは、「コミットするべき成果の約束」をするというプロセスを踏むということなのかもしれない。 両者が下記のことを踏まえて、[[🗃️スプリント]]におけるコミットラインを合意して進められたのであれば、[[🗃️フィーチャー工場]]や[[🗃️アナコンダ・スタイル]]みたいな悲しい状態にはならないのかなと思う。 - what(何を作るのか)に責任を持つ人が意識すべきこと - [[🗃️司令官の意図]]を伝える - 想定外のことは起こりうる。計画通りにいかない。 - アイディアを実現するスピードと比較して、アイディアが生み出されるスピードは速く、量は圧倒的に多い。一度に複数実現しようとするとどれも中途半端に終わる - how(どのように実行するのか)に責任を持つ人が意識すべきこと - ゴールラインとして、どこまでは可能なのかを明示する - 約束したコミットラインは達成する ## 🎓学び ### 完全な計画は立てられないからこそ、[[🗃️謙虚な計画]]を立てるべきである > 「良い計画の敵は，完璧な計画を夢見ることである」 by カール・フォン・クラウゼヴィッツ(イエナ―アウエルシュタットの戦いで生き延びたプロイセン人) 当初立てた計画通りに行くということは、ほぼない。計画とは不完全なものである。 計画を不完全にする「摩擦」(驚きが起きる機会を増やすあらゆるもの)がある。 [[🗃️ソフトウェア開発]]というものは、[[🗃️不確実性]]が高いものである。驚きが多い時は、計画はより謙虚であるべき。([[🗃️謙虚な計画]]) **⚠ 計画を立てるべきではないという意味ではない。計画を進めていく中で、より詳細な計画策定を行うべきということである。** だからこそ、[[🗃️スクラム]]の中で語られる[[🗃️検査]]、[[🗃️適応]]が大切になってくる。 #### [[🗃️謙虚な計画]]を立てるということは、どのようなことか？ - 計画実行前の段階で知っている情報がどれだけ少ないことなのかを認めること - 予期しないことに対処するための十分な余地を残すこと - 計画を進めながらより詳細を詰めていくということ ### 計画に従うのではなく、意図に従う #### 計画に従うことで生まれるペイン - 頻繁に状況が変わる環境において、実行前の計画や指示が無意味なものに変わる可能性が高い - 上層部から指示された方法(how)が組織の目的を達成するために効果がないものかもしれない([[🗃️知識のギャップ]]) #### [[🗃️司令官の意図]]に従う [[🗃️司令官の意図]]とは、他者に指示をする際にやることを伝えるのではなく、以下の2点を伝えることである。 - なぜその使命が重要なのか - 望まれるせいか、あるいは使命の終了状態 これによって、状況が大きく変わっても、その目的を達成するための行動ができるようになった。(💭チケットの[[🗃️受け入れ基準]]でよく書くやつだなと思った) 達成しようとしている成果(what)と理由(why)の意図を理解することによって、不完全な計画、実行の不備、そして予期できない結果に対処可能になる。 ### なぜ[[🗃️ゴール]]が必要なのか？ 共通の[[🗃️ゴール]]を共有しなければ、[[🗃️チーム]](共通のゴールを達成するために一緒に働く個人の集団)にはなれない。 ### [[🗃️スクラム]]に関するよくある誤解と、本書の考え #### (誤解) [[🗃️スクラム]]をすればうまくい [[🗃️スクラム]]は、不完全なフレームワークであり、問題を照らし出す助けłなりうるシンプルな土台である。 [[🗃️スクラム]]は何をすべきかを語らない。[[🗃️スクラム]]がもたらすのは[[🗃️フィードバック・ループ]]である。 > [[🗃️適応]]がない[[🗃️検査]]は[[🗃️スクラム]]では無意味だ #### (誤解) [[🗃️インクリメント]]はスプリントの中で作ったものである [[🗃️インクリメント]]は、プロダクト全体を意味する。 [[🗃️インクリメント]]は、あなたが確信を持つまではアウトプットに過ぎない。 #### (誤解) [[🗃️スプリントレビュー]]の目的は、デモを示すことではない。 [[🗃️インクリメント]]を調べて、[[🗃️プロダクトバックログ]]を調整すること #### (誤解) [[🗃️スプリント]]は一定の仕事量をこなす小さな締め切りである ゴールが達成できていれば、そのスプリントは成功である。タスクの持ち越しが悪いことではない。 絶え間ない全力疾走は、チームを硬直化させて、しっぱうするように追い詰める。価値提供に必要な協働を損なう。 この誤解が、[[🗃️アナコンダ・スタイル]]を生み出す。 [[🗃️アナコンダ・スタイル]]のスクラムチームは、キャパシティでできる量のタスクを詰め込む。 計画に従うことを重視していて、持ち越しが悪いことのように扱う。 [[🗃️アナコンダ・スタイル]]は、変化に対応することに適していない。予期せぬことへの対応をする余地が少なくなる。 [[🗃️ハチドリ・スタイル]]では、予期されていないことが起きても対応するための柔軟な動きができるようになる。 #### (誤解) より多くの[[🗃️フィーチャー]]を提供することがより多くの価値を提供すると言う結果をもたらす [[🗃️価値の不確実性]]が存在する。冗談を言うことで、人々が必ず笑うことを意味しないのと同じ。 機能を多く作ることが必ず価値に繋がるという考え方は[[🗃️フィーチャー工場]]を生む。何かが提供されたということ[[🗃️アウトプット]]が顧客へ価値を届けるという成果よりも大事になる。[[🗃️フィーチャー工場]]では「構築し、忘れる」状態になる。 [[🗃️フィーチャー工場]]では、[[🗃️ベロシティ]]崇拝が起きる。 [[🗃️フィーチャー]]は実験。価値想像だけではなく、お金を稼ぐための価値獲得も必要である #### (誤解) 野心的な予定を守ることが大事 ストレッチなリリース目標を掲げて、いつ完了するのか？を異常に注目するとき、価値はそっちのけにされてしまう。 > 延期したゲームは結果的にはよくなるが、急いで作ったゲームはよくなることはない by 宮本茂(任天堂) [[🗃️フィーチャー]]で止まらない。顧客の生活をどのように改善し、ビジネスに対する価値をどのように獲得することが大事。 [[🗃️ノーススターメトリック]]を使って、価値を届けられているのかを確認する ### なぜ[[🗃️スプリントゴール]]を立てるのか？ [[🗃️スプリントゴール]]が無しと言うのは[[🗃️スクラム]]は心臓を失い、[[🗃️スクラムイベント]]は目的を失う。 [[🗃️スプリントゴール]]がないと、[[🗃️スプリント]]で全ての仕事を完了すること([[🗃️バーンダウン]])がゴールになる [[🗃️スプリントゴール]]無しでは以下のようなことが起こる - 計画に従うことが目的を満たすことよりも重要になる - 全ての仕事を完了させるための計画を作る - [[🗃️レトロスペクティブ]]では全ての仕事を完了にすることにフォーカスがあたる - スプリントの中の全てが等しく重要になる - [[🗃️バーンダウン]]がゴールになる(アウトプットが目的になる) - 柔軟なチームではなくなる。変化を受け付けなくなり創発を可能にする柔軟性を押し殺してしまう。 - 計画通りにいかないことが起こると、何かが犠牲になる。品質に皺寄せがいく。 ### [[🗃️スプリントゴール]]をどのように[[🗃️スプリント]]で扱うのか？ - [[🗃️スプリント]]の目的から始めて下書きを用意する - 自分たちが取り組みうる最も大事なことは何であるか？ - [[🗃️スプリントゴール]]は[[🗃️FOCUS]]でたてる - 楽しさ （Fun）： スプリントゴールは、覚えられるタイトルをもつべきである（そして，楽しいとなお良い！ - 成果指向 （Outcome-oriented）： スプリントの成果として期待されるものは何か？ - 協働 （Collaborative）： スプリントゴールは，スクラムチーム全体により， 念入りにつくられるべきである． - 究極的な理由 （Ultimate）： スプリントの理由 （why）， 私たちが行うこと がどうして大事なのであるかの最終的、あるいは究極的な理由 - 単一 （Singular）： 単一で首尾一貫した目的に焦点を合わせる - 考えうるスプリントゴールの下書きを用意し て，[[🗃️スプリントレビュー]]に臨む - [[🗃️ステークホルダー]]に共有し、認識をすり合わせる - 全員が別々のゴールを設定する場合[[🗃️リベレイティング・ストラクチャー]]の、[[🗃️1-2-4-All]]が有効 - [[🗃️スプリントプランニング]]で、ゴールを作る - 下書きのゴールを共有して、チームが「いいえ」と言えばより小さくする - 「はい」 or 「多分」とすれば下書きとして出発する - [[🗃️プロダクトバックログ]]から、[[🗃️スプリントバックログ]]へアイテムを移動させる - [[🗃️デイリースクラム]]では、次の24時間で達成を計画していることへのゴールを設定すること - このゴールを設定しないと、進捗を追跡したり思い通りに進んでいるのかを知ることが難しくなる。