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