組織構造が文化を作ります
システム思考家であり、システム思考の提唱者であるJohn Seddon氏曰く、「組織の文化を変えようとする事は愚かな試みです。なぜなら、そのような試みは常に失敗するからです。人々のふるまい（文化）は体制により作られるからです。もしあなたが体制を変えれば人々のふるまいは変わるでしょう。」
スクラム導入後にアジリティが減少してしまう理由：プロダクトオーナーの役割に対する誤解、その悪影響および対処法について
2023
LeSSフレームワークのルール
チームを組織の基本単位とし、個人ではなくチーム単位で組織を構 成すること。
LeSSフレームワーク入門
LeSSは12名のグループにも、数百名でも、数千人の規模でも使われてきました。 銀行、通信、ゲームからレーダーシステムの開発などにも使われています。
ブライアン・スタンフィールドによる「フォーカス・カンバセーション・モデル」 ORID
客観的質問、内省的質問、解釈的質問、決断的質問
スクラム研修パート２： バックログリファインメント
バックログリファインメントはスクラムに必要ですが、このビデオにあるようなミーティングである必要はありません。私は、次のスプリントプランニングの数日前にリファインメントを行うことをおすすめしています。
スクラム研修パート６：スプリントレトロスペクティブ
レトロスペクティブは、スクラムを学習のフレームワークとして用いる際の鍵であり、私たちが日頃目にする固定的なプロセスではありません。
ビル・ウェイク の INVEST
ビジネス価値を生み出す作業や、チームの時間や労力を要する事柄はすべて、プロダクトバックログに載せてください。
スクラムマスターの道具箱
積極的に何もしないこと。例えば、黙って観察しながら、介入したい衝動を抑える。 チームを考えさせたり、議論を促進するような問いかけをする 中立的な観察をする。 観察と評価を分けるNVCのテクニックを使う。 行動をモデリングする（お手本になる。）つまり、他のチームメンバーに真似して欲しいように振る舞...
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。
2022
チームの自己設計を導入する方法
マネージャによって作られた自己管理型のチームは、意味があるのでしょうか？組織は自己管理型チーム に対する準備ができていますか？それともこのアイディアは過激すぎますか？
パブリック研修の参加者が、プライベート研修の参加者よりも、平均的に優れた結果を出す理由
スクラム、アジャイル、LeSSにおける仕事に対する考え方は、伝統的な考え方と大きく異なります。スクラムとアジャイルは必然的に、組織構造や組織方針など、組織設計の変更を意味することになります。 LeSSでは、このような変化に明確に焦点を合わせることになります。
2021
スクラムは、企業が抱えている欠陥や障害となるものを何から何まであらわにさせ、企業がそれらの問題を修正できるようにすることを目的としています。
ケン・シュエーバーによるCSM学習目標
ケン・シュエーバーが意図的にスクラムから除外した項目
意図的にスクラムの一部とされていないものや、スクラムと矛盾するもの、またスクラムを役立たないものにしてしまうものを挙げてみます。
2020
スクラムリファレンスカード
スクラムは1チーム以上でプロダクト開発を行う為のフレームワーク で、1つのチームは7名前後のクロスファンクショナルで自己組織化 されたチームで構成されます。
スクラム研修 事前セルフアセスメント
このセルフアセスメントで、私が記載した参考文献やチュートリアルと全く関係のない回答をされる方が多くいらっしゃいます。
小さなチームのためにプロダクトを独立した小さな単位に分割しないほうがよい理由
今日、スケーリングについて二人が同じ勘違いした助言をしているのを聞きました。違うチームが作業するには、プロダクトを独立した部分に分けるのが良いというものです。この助言は決まり文句と言えるほどありふれています。アジャイルのコーチング及びトレーニングのコミュニティに広く見られる盲点がここに現れています。
私のコード、あなたのコード。アジリティに有害なプライベートコードポリシー
コードに対して担当者や担当チームを割り当ててしまうと、いくつかの悪影響が出てしまいます
システムの最適化目標がなければ組織改革はできない
「全てを改良する」ではうまくいかない理由
LeSS Q&A
Q. デザイナーをどのようにチームに巻き込むか
スクラムアライアンスによるCSMテストの受験予定者を対象とした12ステップのプログラム
スクラムアライアンスによるCSMテストを受験するにあたり、不安を抱えていませんか？また、スクラムやLeSSについての知識をさらに深めたいとお考えですか？私は2004年より、日本を含め世界中でスクラムならびにアジャイルについての学習をサポートしてきました。
スクラムマスターやプロダクトオーナーは、コーディネーター（調整役）ではありません。
スクラムおよびLeSSでは、（開発）チームはクロスファンクショナル（機能横断的）であり、自己を管理します。スクラムマスターやプロダクトオーナーではなく、チーム自身が調整や統合を行います。
練習問題 スクラム/LeSSで定義されている役割 パート1
各役割における特徴と責任を特定してください。 この練習問題は、匿名で何回でもお試しいただけます。
新しいScrumAlliance CSMテストには、どのようなトピックが出題されますか？
CSM候補の方々の中には、ScrumAllianceの新しい認定テストに若干の不安を抱えている人もいらっしゃると思います。この認定テストを安心して受けていただけるよう、テスト準備のお手伝いをさせていただきます。
クイックスクラムクイズ1
これはバージョン0.2です。 改善にご協力ください。
実例による仕様 Cucumber/Java Specification By Example (SBE) 電子バーテンダー
プロダクトバックログリファインメントを行なっている間は、ユーザーストーリーではなく、実例による仕様（Specification By Example、以降SBE）を用いることをお勧めします。ビジネス側の人と開発者は、ホワイトボードを使用して共同作業します。 Cucumberを使用すると、非技術者であっても Fea...
スクラムの紹介のスクリプト。
https://scrumtraining.jpでビデオを勉強してください。
2019
LeSS全体像スクリプト
これがLeSSの簡単な全体像です。 まずは、LeSSの中心となる10個の原則をみていきましょう。
知識創造を行う仕事は、今までの仕事と何が違うのか？（なぜあの会社はコーディングができないのか）
知識創造を行う仕事、例えばソフトウェア開発などに見られる根本的な制約は、私たち人間の知識を発見したり創造したりする能力にあります。
認定LeSS基礎研修（CLB）(Certified LeSS Basics)
大規模スクラム（LeSS）とは、複雑なプロダクト（典型的にはソフトウェア）を複数のチームで開発するためのアジャイルなアプローチです。LeSSはスクラムにインスパイアされたものです。ただし、スクラムガイドが適するのは12人以下の会社のみですが、LeSSは20人、200人、または数千人規模の会社の問題にも対応していま...
面倒なスクラム・オブ・スクラムに取って替わる７つの方法
スクラム・オブ・スクラム。問題発生から１6年、シュエイバーの否定から10年、なぜ未だにSoSは実践されているのか?
局所最適化バイアス：今ここで 対 後にどこかで
ソフトウェア開発について深く理解していない人は、大規模なアジリティは複数の「超生産的」なチームの作業の総計だと考えるかもしれません。一見、論理的に思えるかもしれません。馬の足が早ければ早いほど、馬車も速く進むと考えませんか？しかし、賢明な読者のみなさんは、ソフトウェア開発は馬車を引っ張る馬とはわけが違うことは理解...
大規模組織におけるソフトウェア開発の誤解その４：各チームが作ったパーツは、魔法の力で組み合わさるのか？
チームの「生産性」向上ではなく、プロダクト開発のアジリティを目指すのであれば、チームの繋がりをゼロにするべきではないのです。
大規模組織におけるソフトウェア開発の誤解その３：チームの視野は狭くて良いか、プロダクト全体を見るべきか?
ほとんどの企業では、どのようなプロダクトでも１１人以上が従事しています。彼らはスクラムを適合させる(局所最適化)ためだけに「プロダクト」を再定義し、プロダクト全体より狭い意味に変えてしまうことがあります。しかしこれは、言葉が本来の意図とは真逆のことを意味してしまう鏡の迷宮への入口なのです。
大規模組織におけるソフトウェア開発の誤解その２:すべてのチームが等しい価値の業務に取り組んでいるか？
7つのチームを持つ会社の人間がスクラムを表面的にしか理解していない場合、各チームは個別の業務リストを持つべきだと考えるかもしれません。それによってチームが「生産的」になるはず･･･でしょう？
スクラム導入後にアジリティが減少してしまう理由：プロダクトオーナーの役割に対する誤解、その悪影響および対処法について
その後、大きな企業でスクラムマスターとして働き始めることになった。この時、私はチームの生産性に焦点を当てるという間違いを犯した。
大規模組織におけるソフトウェア開発に関する誤解 その１：知的作業において「依存関係」が生じるのは、逃れられない物理法則の結果なのか？
第一次世界大戦の直前、フレデリック・テイラーの同僚であった H・L・ガントは、工程同士の依存関係をはっきり表示するプロジェクト管理表を提案しました。これはガントチャートと呼ばれ、物理的実体によって依存関係が生じる製造・建設・物流等の分野において有用です。
クレイグ・ラーマンの法則 (Larman’s Laws)
組織構造は暗黙的に現行のマネージャーと専門家の役職や権限が変わらないように最適化されています。