Rubyはオブジェクト指向言語です。文字列や配列はもちろん、数値やnil（ほかのプログラミング言語でいうところのnull）も含めて、すべてがオブジェクトになっています。その証拠に数値やnil、trueやfalseに対してもメソッドを呼び出すことができます。

少しずつインクリメンタルにコーディングすること。そうすれば、開発が進むにつれてコードが洗練され、構造化されていくことに気づくだろう。インクリメンタルにコードを書いて、テストする。この継続的なフィードバックが、コードが過剰に複雑になったり、散らかり放題になることを防いでくれる。

「開発準備OK」ステージは、基本的に「このステージには、エピックからの分割と見積りが行われており、要求の内容が明確になった機能が集まっているが、どの順番で開発を行うかまではまだ決定していない」という意味を持っている。

素晴らしい企業文化では、問題や意見の相違が水面下に潜ることなくうまく解決される。社員はみなそれまで作ったことのないものを想像したり、実際に作ってみたりすることを楽しんでいる。それが組織の進化を支える。（中略）誰もが率直に発言できる環境を作り、透明性を徹底して、有意義な仕事、有意義な人間関係につなげることを常に目標にしている。

「失敗型」のアプローチでとくに注目すべきは、成果そのものよりも、トップダウン方式を重視した従来の価値観に風穴を開けたことだ。「失敗型」アプローチをとるには、物事を素直に受け入れる気持ちと、根気強さが欠かせない。オンライン共有サービス（Dropbox）を開発したドリュー・ヒューストンもこのマインドセットを学んでいた。

インセプションデッキの背後にある考えはこうだ。「しかるべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して、認識を合わせることができるはずだ。」と。

デイリースクラムやスプリントレビューで障害を発見できたのなら、スクラムの基本である透明性と検査がうまく機能していることを意味します。これは悲観することではなく歓迎すべきことです。予期せぬ障害の発見は学習と成長のチャンスです。

リーダーが開発者に望んでいるのは、バンガロールのチームのような気概と自立心だ。計画を作成して実行し、その成果を報告することは、両方を獲得するのに大いに役立つだろう。

プロセス改善ワークショップとは、それぞれの機能開発チーム、要求分析チーム、テストチームといった、担当チームから１人ずつ代表者が集まるスクラムオブスクラム形式で実施するふりかえりだ。

実際にスクラムを始めて見ると、想定していなかった課題や気づきが出てきます。１週間ごとに行われるスプリントレトロスペクティブの場を使って、スクラムチームの習熟度に合った最適な（スプリント）期間を導き出していきましょう。