スクラム実践者が知るべき97のこと の商品レビュー

ギュンター・ヴァーヘイエン(編者),吉羽龍太郎(訳者),原田騎郎(訳者),永瀬美穂(訳者)

2024/10/24

01　スクラムについて誰も教えてくれない5つのこと
　スクラムは、やらない仕事を徐々に増やす。顧客が本当に必要なものに集中する。誰も必要とせず、誰も使い方を知らないフィーチャーばかりのプロダクトを作ったりしない。結果としてプロダクトバックログは短く（クリーンに）なり、デリバリーが速くなり、最終的にマーケット投入までの時間を短くできる。 スクラムは最初から品質を作り込む。品質を作り込むことで、革新的なフィーチャーの開発に集中できる。終わらないバグ対応でエネルギーを浪費することもない。また、保守の手間も大幅に減る。

　組織変革に取り組む準備ができていないなら、スクラムを使う準備はできていない。

04　スクラムはシンプルだ。変えずにそのまま使え
　スクラムはマインドセットだ。複雑でカオスな問題を役に立つものに変えるアプローチだ。ジェフ・サザーランドと私は、3つの柱をスクラムの基礎とした。 小さな自己組織化したチーム リーン原則 経験主義。頻繁に検査と適応を行い、最大限の成果を得られるようにチームを導く

09　「複数のスクラムチーム」と「複数チームによるスクラム」の違いを知ろう
　複数チームによるスクラム」の構成では、プロダクトバックログが1つであるだけでなく、複数の開発チームと働くプロダクトオーナーもただ1人だ。

10　「完成」で何を定義するか？
　「完成」の意味するところに透明性がなければ、スクラムを効果的に適用するのは難しい。「完成」の定義によって、全員が「完成」の意味を理解するのだ。インクリメントが提供するプロダクトの機能の想定価値を考えるには、「完成」の共通理解は欠かせない。開発チームがスプリント中にどれだけ完成させられるかを見積もるにも、完成の定義による明確な基準が必須だ。スプリント中、どのプロダクトバックログアイテムがインクリメントとして完成しているかをチームが判断する基準となるのが完成の定義だ。

　インクリメントに「未完成」のものは含まれない。未完成のものが本番環境に入ることはない。絶対にだ

15　プロダクトマネジメントのすきまに気を付けろ
　予算どおりか？　納期どおりか？　このようなアウトプットのメトリクスは、アウトカムを無視して顧客価値をおざなりにする。そして、それぞれのチームとマネージャーは、計画（と官僚主義）にどれだけ従えるかという評価で縛られることになる。 マネジメントと開発チームの断絶を防ぐため、新たなプロダクトの開発や既存プロダクトの拡張を計画するとき、スクラムマスターはプロダクトオーナーと働かなければいけない。プロダクトマネジメントのすきまを下の図にある3つのVで賢く埋めよう。Vision（ビジョン）、Value（価値）、Validation（検証）だ。

16　フローフレームワークによる組織全体へのスクラムのスケーリング
　フローフレームワーク†1の目的は、アジャイルチームの日々の取り組みよりも抽象度を高くしたスクラムとアジャイルの概念をビジネスに持ち込むことである。ユーザーストーリーとストーリーポイントは、4つのフロー項目（フィーチャー、欠陥、リスク、負債）で置き換える。このように翻訳することで、ビジネス側はソフトウェアデリバリーのダイナミクスが理解できるようになり、双方向の理解が進むのだ。たとえば、技術的負債や、アーキテクチャーへの投資とフィーチャー開発のトレードオフの必要性を双方で理解できるようになるのだ。

23　サッカーのフーリガンから学ぶことなんてあるのか？
　献身、チームダイナミクス、目的、マインドセット、文化、ふるまい、そして価値が必要なのだ

81　アジャイルリーダーシップと文化のデザイン
　それでもこれまでの組織の多くは、個人評価、効率、利益、大量生産といった古いリーダーシップ原則にもとづいたOSのままだ。そのようなOSは、チームのコラボレーション、自立、自己組織化、すばやい判断などをサポートするようには設計されていない。 リーダーとして、自分自身のリーダーシップスタイルについて問わなければいけない。自己組織化を促進しサポートするために徐々に組織構造を変えていくなかで、チームがより多くの判断を下せるようなものになっているだろうか？

2023/09/30

ザッピングした
スクラムでプロダクト開発するメンバーなら気になる項目があるはず。
プロダクトマネジメントのすきま、「それは自分の仕事じゃない！」あたりよかった

2022/07/22

会社の同僚たちと一緒にランチ読書会でちょっとずつ読んでいった。

そんなふうにしてゆるくあーだこーだ言いながら進めるのにちょうどいい本だった。

日本人による追加エッセイもあって、邦訳版はお得だと思う。

「第X章 スクラム番外編」は「お、おぅ。。。」ってなるエッセイが多かったけど、まぁ仕方ないか。

あと、CopeさんがJIRAを名指しでdisっててブレないなー、って思ったw

2022/02/10

スクラム開発者は1度は目を通すべき。
現在スクラムで開発を進めているのだが、壁にぶつかることが何度かあり、それに対しての対応策を決めあぐねる場面も何度か経験した。
あの時どうすれば良かったのだろうかと思考する際のヒントとなりうるのが本書だと思う。
また、基本的な事柄も多々述べられている(多分スクラムの基礎土台を理解して実際にやってみることが重要だからだ)ため、スクラムってなんだったっけ？という復習にも役立つと思う。
本書を1ページ読むたびにワクワクが止まらず、文字を読むのが苦手な自分には珍しく、凄まじい勢いで読み切ってしまった。
自分も人にワクワクを与えられるような、そんな存在になれたらいいな。

2021/07/09

エッセイ集。スクラムをやっている中でみんなどうやってるんだろうな、を知ることができる本。スクラムは具体的にどうやるかといった点は定義されてないのでそれぞれの現場での試行錯誤が集められている。

対話と自己組織化が大切だと改めて感じた。

2021/03/30

これは面白い。
スクラムを経験している人が読むという前提の本。

個別のテーマを読んでいくと、エッセイを書いている人によっては言っていることが衝突していたりする。それがすごく現実的で、正解のあるやり方ではない、を体現していると思った。

今のやり方を見直す、そういう人のための起爆剤というか、刺激になる。

読み通すのもいいが、スクラムイベントの気になったところを集中的に読んでみるといった使い方がより良さそう。

2021/03/27

複雑だ。複雑な世界をそのまま体現したようなエッセイ集だ。個々のエッセイでパースペクティブが異なり、衝突するものもある。同意できない、と感じるものさえあるだろう。

だが、それがいい。だからこそいい。実践知が現場で息づき、変化し、発展していった千差万別の形態がそこにはある。
中には「こうであってはいけない」と断言しているものもある。しかし、そういった主張さえも受け止めチームで考えることがスクラムチームには求められる。

グラグラと価値観を揺さぶられる、カオスなエッセイ集。しかし適当なことを並べているわけではない。真剣に実践知を抽出しているからこそ、こちらを揺さぶってくるのだ。