Always All Ways

Apologies, Glances and Messed Up Chances

Scrumを教えるのに最適なフレームワークはScrum

Tobias Mayer氏が、「スクラムのワークショップにおける5つの『やってはいけない』」みたいなブログ・エントリを書いています。せっかくなので、その5つを見出しのみ抜粋してみると、

  1. Don't plan the whole workshop.
  2. Don't ask questions you already know the answer to.
  3. Don't play games with predefined outcomes.
  4. Don't answer questions.
  5. Don't talk about yourself.

Top 5 Scrum Workshop Dont's

それぞれの内容については原文を見てくださいね。

Scrumを教えるためのフレームワーク

これらの5つのポイントはそれぞれ重要な示唆を含んでいるのですが、私自身は、この記事の中で最も重要なのは、"Scrumを教えるのに最適なフレームワークはScrumである"という点ではないかと思っています。

There is a great framework for teaching people about Scrum. It is called Scrum.
Top 5 Scrum Workshop Dont's

その根底にあるのは、Scrum(に限らずアジャイル開発全般的にそうだと思うのですが)が、複雑適応系(Complex Adaptive System)を扱うものであるということ。それを忘れると、本来ワークショップの中で気づき・考えるべき「不確実性にどう対応していくのか?」ということを体験できず、参加者はチグハグな印象を受けるだけでなく、場合によってはワークショップで最も気づいてほしいことに気づかずに間違った理解をしてしまいかねません。

フレームワークとワークショップのメタな関係

同じように考えると、要求開発を教えるためには要求開発的なファシリテーションでワークショップを進めるのが適しているように思いますし、その他同じようなことはいろいろなフレームワークや方法論に対しても言えるのではないでしょうか。
実際、例えば私自身は残念ながら参加できませんでしたが、Jeff Patton氏のCSPO研修ではセッションの進行自体をユーザーストーリーマッピングの手法を使ってやったような話も聞いています。
参考: Jeff Patton氏の “情熱プロダクトオーナーシップ” に参加しました #sgt2011 #CSPO | 世界のdaipresents

本質を理解すること

これらのことは、Scrumや要求開発(およびその他世の中のフレームワークや方法論、プロセスなどなんでも)を教えるにはまずなによりも、単なる表面的な知識や具体的なプラクティスだけでなく、その本質を理解していなければならないことを示しています。そして、それをワークショップの中で体現していくこと。これはしっかりと心に留めておきたいです。