MJ

MJ

私が講師を務める次回の認定スクラムマスター研修（CSM）及び認定 LeSS Basics (CLB）研修は、2024年6月3日に開催される予定です。研修の予約はこちらよりお願いします。

スクラムについての無料オンライン学習をご利用になりたい方は、こちらをクリックしてください。

私見

組織構造が文化を作ります

システム思考家であり、システム思考の提唱者であるJohn Seddon氏曰く、「組織の文化を変えようとする事は愚かな試みです。なぜなら、そのような試みは常に失敗するからです。人々のふるまい（文化）は体制により作られるからです。もしあなたが体制を変えれば人々のふるまいは変わるでしょう。」

LeSSフレームワーク入門

LeSSは12名のグループにも、数百名でも、数千人の規模でも使われてきました。 銀行、通信、ゲームからレーダーシステムの開発などにも使われています。

スクラム研修パート２： バックログリファインメント

バックログリファインメントはスクラムに必要ですが、このビデオにあるようなミーティングである必要はありません。私は、次のスプリントプランニングの数日前にリファインメントを行うことをおすすめしています。

ビル・ウェイク の INVEST

ビジネス価値を生み出す作業や、チームの時間や労力を要する事柄はすべて、プロダクトバックログに載せてください。

スクラムマスターの道具箱

積極的に何もしないこと。例えば、黙って観察しながら、介入したい衝動を抑える。 チームを考えさせたり、議論を促進するような問いかけをする 中立的な観察をする。 観察と評価を分けるNVCのテクニックを使う。 行動をモデリングする（お手本になる。）つまり、他のチームメンバーに真似して欲しいように振る舞...

私がもはやベロシティについてほとんど話さない理由

ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。

チームの自己設計を導入する方法

マネージャによって作られた自己管理型のチームは、意味があるのでしょうか？組織は自己管理型チーム に対する準備ができていますか？それともこのアイディアは過激すぎますか？

パブリック研修の参加者が、プライベート研修の参加者よりも、平均的に優れた結果を出す理由

スクラム、アジャイル、LeSSにおける仕事に対する考え方は、伝統的な考え方と大きく異なります。スクラムとアジャイルは必然的に、組織構造や組織方針など、組織設計の変更を意味することになります。 LeSSでは、このような変化に明確に焦点を合わせることになります。

スクラムリファレンスカード

スクラムは1チーム以上でプロダクト開発を行う為のフレームワーク で、1つのチームは7名前後のクロスファンクショナルで自己組織化 されたチームで構成されます。

小さなチームのためにプロダクトを独立した小さな単位に分割しないほうがよい理由

今日、スケーリングについて二人が同じ勘違いした助言をしているのを聞きました。違うチームが作業するには、プロダクトを独立した部分に分けるのが良いというものです。この助言は決まり文句と言えるほどありふれています。アジャイルのコーチング及びトレーニングのコミュニティに広く見られる盲点がここに現れています。

LeSS Q&A

Q. デザイナーをどのようにチームに巻き込むか

実例による仕様 Cucumber/Java Specification By Example (SBE) 電子バーテンダー

プロダクトバックログリファインメントを行なっている間は、ユーザーストーリーではなく、実例による仕様（Specification By Example、以降SBE）を用いることをお勧めします。ビジネス側の人と開発者は、ホワイトボードを使用して共同作業します。 Cucumberを使用すると、非技術者であっても Fea...

LeSS全体像スクリプト

これがLeSSの簡単な全体像です。 まずは、LeSSの中心となる10個の原則をみていきましょう。

認定LeSS基礎研修（CLB）(Certified LeSS Basics)

大規模スクラム（LeSS）とは、複雑なプロダクト（典型的にはソフトウェア）を複数のチームで開発するためのアジャイルなアプローチです。LeSSはスクラムにインスパイアされたものです。ただし、スクラムガイドが適するのは12人以下の会社のみですが、LeSSは20人、200人、または数千人規模の会社の問題にも対応していま...

局所最適化バイアス：今ここで　対　後にどこかで

ソフトウェア開発について深く理解していない人は、大規模なアジリティは複数の「超生産的」なチームの作業の総計だと考えるかもしれません。一見、論理的に思えるかもしれません。馬の足が早ければ早いほど、馬車も速く進むと考えませんか？しかし、賢明な読者のみなさんは、ソフトウェア開発は馬車を引っ張る馬とはわけが違うことは理解...

大規模組織におけるソフトウェア開発の誤解その３：チームの視野は狭くて良いか、プロダクト全体を見るべきか?

ほとんどの企業では、どのようなプロダクトでも１１人以上が従事しています。彼らはスクラムを適合させる(局所最適化)ためだけに「プロダクト」を再定義し、プロダクト全体より狭い意味に変えてしまうことがあります。しかしこれは、言葉が本来の意図とは真逆のことを意味してしまう鏡の迷宮への入口なのです。

大規模組織におけるソフトウェア開発に関する誤解　その１：知的作業において「依存関係」が生じるのは、逃れられない物理法則の結果なのか？

第一次世界大戦の直前、フレデリック・テイラーの同僚であった H・L・ガントは、工程同士の依存関係をはっきり表示するプロジェクト管理表を提案しました。これはガントチャートと呼ばれ、物理的実体によって依存関係が生じる製造・建設・物流等の分野において有用です。