はんなりと、ゆるやかに

アジャイル、スクラムが好きが日々から学んだことをアウトプット

スクラムの背景を学んで改善しよう / 「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」を読んだ

スクラムの「なぜ」が学べる「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」を読みました。

ケン・シュウェイバー氏と共にスクラム」を確立したジェフ・サザーランド 氏によるスクラムです。いろんな本やイベント、実践を通じてスクラムの進め方についての知識はついてきました。さらに深く理解するためにスクラムの背景を知りたいと思い、手に取りました。

本書は一つ一つの要素が丁寧に書いてあります。スクラムの全体像が分かった状態で読んだ方が学びは多いと思います。SCRUM BOOT CAMP THE BOOKスクラムガイドを読んでスクラムオーバービューがイメージできる状態になってから、本書を読むと深く学べると思います。

目次

「進みが遅く、出来上がったプロダクトが使われない」という問題を解決するところから始まったスクラム。そんなスクラムの誕生の経緯からスクラムの核となる概念がまとめられています。

第1章 過去のやり方は通用しない
第2章 スクラムが誕生するまで
第3章 チーム
第4章 時間
第5章 無駄は罪である
第6章 幻想を捨て、現実的なプランニングを
第7章 幸福
第8章 優先順位
第9章 世界を変える

イベント一つ一つに歴史がある

当たり前と言えばそうなのですが、デイリースクラムにしても生まれた経緯があります。「デイリースクラムは15 分間、毎日、同じ時間・同じ場所で開催して調整するんだよ」というやり方だけ知っている場合と、「数百におよぶソフトウェア開発プロジェクトを分析して成功しているプロジェクトを視察したところ、仕事を達成するために必要なことをチーム全員が知っている状態が重要だとわかった。その一つの要素としてチームメンバーが毎日集まり話し合い解決していたので、それを取り入れたのがデイリースクラム。15分以内にしている理由は・・・」というように各イベントの背景を知ることで理解度が変わります。また、「なぜ15分なのか?」という理由も合わせて知ることで本質からズレずに自分たちの環境に合わせた改善ができます。

アップデートしたいと思った大きな3つ

僕はスクラムフレームワークを使って開発をしています。常にもっともっと改善したいと思っているのですが、本書を読んで特に開発の改善に繋げようと感じた3つを紹介します。3つ以外にも全然できてないなーって刺激を受けることがたくさん見つかった書籍です。

チーム

本書は理想のチームの一つとしてラグビー ニュージーランド代表の「チーム」と試合前に行われる「ハカ」について取り上げられています。

この「集中力」「一体感」「強い意志」「仲間が攻め込んだ時の歓喜と賞賛」といった要素がスクラムには組み込まれています。スクラムマスターはリーダーシップをとってこのような自己管理型のチームを目指していきます。本書を読んだり過去にも考えたのですが、ソフトウェア開発、プロダクト開発で目指すチームはプロスポーツチームと同じだと感じています。過去の記事でも同じようなことを書いています。

サッカーで例えるとスプリントプランニングは「試合前の戦術ミーティング」、デイリースクラムは「試合中の選手同士の会話」が近いと感じていて、そのメタファーでスクラムを捉えなおすと新しい発見があるかなって思っています。

ムリ・ムダ・ムラの観点

スクラムトヨタ生産方式の影響を受けていると書かれています。トヨタ生産方式と言えば「ムリ・ムダ・ムラ」ですね。本書でも「計画で無理を避ける、実行でムラをなくす。評価して無駄を削る。」と書かれています。スクラムではレトロスペクティブ、スプリントレビューがこの観点を使うメインのイベントになると思います。KPTでふりかえりするなら、Pを出すときにこの3要素の観点でふりかえりすると良さそうです。「間に合わなさそうだったから残業して間に合わせました。間に合って良かったです!」ではなく、ムリをして開発した原因はなぜかを考えていくと、今まで見えてなかった問題が見つけられそうだと思いました。

透明性

スクラムの3本柱である「透明性」は本書を読んでも改めて大切だと感じましたし、自分に足りていないと感じました。チームを阻害する要因の一覧(障害一覧やインペディメントリストと呼ばれます)を見せて開発の改善が進んでいく話があり、こういう使い方があるんだと気付きました。「透明性」となるとプロダクトバックログやスプリントバックログ、インクリメントが大切ですが、障害リストも同じように大切ですね。ちなみに障害リストは認定スクラムマスター研修でスクラムマスターが管理する作成物として紹介されました。(できてない。。。)他にも INVESTなプロダクトバックログアイテムなど大事だ大事だと思いながらも出来てないことがたくさんあるなぁっと反省です。改善していきます。

まとめ

スクラムは導入してOK!というシステムではありません。本書でも「スクラムは進化的で適応性があり、プロジェクトを進めながら修正していくシステム」と書かれていますし、スクラムガイドにも「スクラムフレームワークは意図的に不完全なもの」と書かれています。また、認定スクラムマスターの研修では「スクラムは問題を発見するフレームワーク」と紹介されました。スクラムは導入してからがスタートなのです。継続して改善するためにもスクラムの背景を理解してみるのはいかがでしょうか。