Agile2013の歩き方

第6回 Agile2013 4日目レポート 「Simple Patterns That Avoid Common Pitfalls for Scrum Teams」

この記事を読むのに必要な時間:およそ 3.5 分

スクラムの使いどころ

10:45~12:00は,スクラム(Scrum)を考案されたJeff Sutherland氏の「Simple Patterns That Avoid Common Pitfalls for Scrum Teams」に参加しました。質問がある参加者がJeff Sutherland氏と一緒にソファーに座って聞くことができます。質問が多かったので,質問者を課題ごとにまとめてソファーに呼ぶことになりました。

画像

始める前に,Jeffから簡単に話がありました。アジャイルを使うと,従来方式で開発した場合よりも成功する確率が上がります。しかし,それでもまだ半分以上が失敗で終わっています。これらの失敗はアジャイルが悪いのではなく,⁠悪いアジャイル」を使ったためです。

サッカーにはルールがありますが,試合の内容までの選手の動きまでは決められていません。同じようにスクラムもフレームワークは決めますが,プロジェクトで具体的にどのように実施するかについては決められていません。また,スクラムはソフト開発以外で使っても効果を出すことができます。

最近はベロシティが注目されていますが,重要なのは加速(acceleration)することです。スプリントを短くすることでより早く加速することができます。

その後,課題についての解説が始まりました。

課題1:スクラムに関係している組織が分裂し始めているように見えたら

スクラムに含まれていることは必須項目ではありません。状況に応じて利用してください。スクラムを考案したKenと私たちの考えを伝えることは重要だと思っています。

現在のスクラムと2.0の違いについてはビデオで述べていますが,主に6点あります。その中の5点は小さな修正です。最後の1つは重要な修正です。デイリーミーティングで行う3つの質問も内容を変えました。

デイリーミーティングはメンバーの状況を確認するために行うためのものではありません。メンバーがよりよく共同で作業を行えるために情報交換の場です。ただ「昨日は自分は何をした」⁠今日は自分は何をする」を伝えるのではありません。⁠チームの目標を達成するために」自分は昨日何をした,今日は自分は何をする,を他チームメンバーに伝えるのがデイリー ミーティングの目的です。

課題2:人とプロセス,ツールとは

個人とプロセスはアジャイルマニフェストにも書かれています。問題の80%はプロセスの問題です。人の問題は残りの20%に過ぎません。

Scrumming the Scrumを行うことを推奨します。⁠Scrumming the Scrum」とは,スクラムを改善していく仕組みです。実際の世の中には問題が多くあります。⁠Scrumming the Scrum」はこれらの問題を解決するのを支援します。

最近,スクラムやアジャイルに関連したツールが多く出回っています。しかし,実際に有効なツールはポストイットと壁です。会話をして,その内容を確認するのはポストイットでも行うことができます。

スクラムが正しく使われるようになると,組織のピラミッドが横に倒れます。組織の構造を保つ必要はありません。マネージャはコーチングやファシリテーションの役に回ります。スクラムにはマネージャは不要なのです。その代わりにリーダーが必要になります。

課題3:チームのパフォーマンス・レビュー

調べによると,パフォーマンス・レビューはメンバーのモチベーションを下げるだけです。ただし,ボーナスを多く貰う理由作りのためにパフォーマンス・レビューを望むメンバーがいます。私の場合は,レビューをした後にメンバーがそのレビューに対して反論する機会を与えています。その際,以下のように点数を与えています。

  • 5~6点:その人が,その人に期待していた以上の成果を上げた
  • 7点:その人が所属するチームが期待していた以上の成果を上げた
  • 8点:その人の上司の上司以上の人の期待していた以上の成果が上げた
  • 9点:顧客から,期待していた以上の成果を与えられたと評価された
  • 10点:社会で良いレビューを受けた

しかし,組織ピラミッドを横に倒した後にはパフォーマンス・レビューは不要です。各自が自分が行うことを他人が見える場に書き込んで,それを読んだ皆から評価されるようにします。

課題4:ハイパーパフォーマンス・チーム

スクラムマスターがチームをよりよくするための責任者です。パフォーマンスを上げるために,以下のことを推奨します。

  • Scrumming the Scrumを使ってスクラムを改善する
  • 割り込みがあることを予想しておく方が良い
  • バッファーオーバーフローした場合は直ぐにスプリントを停止して,直してから再開する

課題5:プロダクトオーナなしのスクラム

スクラムマスター(SM)は注目されているが,プロダクトオーナー(PO)はあまり注目されず,POなしでスクラムを始めてしまうユーザがいます。しかし,しかしスクラムを行う目的はビジネスにあります。ビジネスの収益を考えて責任をもつのがPOです。POなしでスクラムを始めるのはビジネスの収益を高めようと思っていないことになります。

課題6:ソフトウェア開発以外での利用

スクラムをソフトウェア開発以外で使うこともできます。

最後に「良いスクラムマスターとはどのような人か? という質問をときどきされますが,良いスクラムマスターとは,ベロシティを上げてメンバーを幸せにする人だと答えます」とセッションを結びました。

アジャイルを測定する“グッド”プラクティス

14:00~15:15はRally SoftwareのLarry Maccherone氏による「Seven Deadly Sins of Agile Measurement」に参加しました。Rally Software社はAgile2013のスポンサーです。アジャイルの効果についてのいろいろなデータも公開しています。

画像

アジャイルを測定する「ベストプラクティス」はありませんが,コンテキストによっての「良い」⁠Good)プラクティスはあります。

現在,アジャイルは以下の3つの目的に使われています。

  1. スクラムのようなプラクティス
  2. マインド設定,価値(Value)の設定
  3. 環境の変化

このセッションではアジャイルを上記3.の「環境の変化」として使います。アジャイルはプロセスのフィードバックではなく,製品(product)のフィードバックです。

そして測定に関するよくある間違いとして以下の7つを挙げました。

画像

「間違い1⁠⁠,他人の行動を変えるために測定を使う人は以下の観点で測定を行います。

  1. チームを改善するため
  2. 予測するため
  3. 診断するため
  4. メンバーの行動を変えるため

しかし,アジャイルは人の行動を変えることではありません。自分のみの行動を変えます。自分の測定データを見て,自分を変えるのは良いです。他人を行動を変えようとするのは間違いです。

「間違い2」は,製品に望むことをバランスよく考えないために起こります。ただ早く完成させるだけではなく,品質や出荷時期(早くではなく,オンタイムに)も考慮する必要があります。

「間違い3」は考えずに測定データを使うこと。定性分析の裏づけとして定量データを使うことが必要です。

「間違い4」製品を開発するのはプログラマです。ソフトウェア開発で一番重要なのはプログラムの時間です。その時間を測定のために無駄にしないことです。たとえば,プログラマのプロジェクトコードや作業ごとに利用した工数を入力させるのは,プログラマの時間を無駄にしていることになります。入力する時間だけではなく,プログラム以外の作業をさせることで,割り込みが入ります。結果的にはモチベーションが下がる場合もあります。

「間違い5」はお手軽な計測に頼ること。Outcome, Decision, Insight, Measurement(頭文字からODIM)を考えて測定するメトリクスを考えることが重要です。

「間違い6」は,素人分析が原因で起こります。専門家を使って分析をした方が良いということです。

「間違い7」は,測定結果を鵜呑みにして判断してしまうことです。予測は確率であることを忘れないことが必要です。1つの結果を予測するのではなく,複数の異なる結果になる可能性があることを前提に考えなければなりません。

全体を通して

セッションに参加していると,内容よりも演出を重視しているように思えはじめました。参加者から良い評価を得るために,演出を重視して楽しませているような感じです。驚くような内容の発表は少ないです。また,演出が良いセッションの方に人が集まっています。しかし,セッションの中には本当に勉強になるものもあります。

4日経ってやっとわかってきましたが,自分に役立たないと思ったセッションだったら早く出て,別のセッションに参加した方が良いということです。後の方に重要なことを伝えると思って聞いていても,結局変わらない場合が多かったです。

また,参加する前に目的を明確にした方が良いと思います。学びたいのか,楽しく時間を過ごしたいので,それともただ有名人に会いたいのか。目的を明確にして行動することの大事さがわかりました。自分も含めて,発表者は参加者が途中から出て行っても特に嫌味を感じません。なぜなら,自分も他人のセッションの途中に出て行くことがあるからです。

さよならパーティ

Agile2013は明日(米国時間の9日)の午前で幕を閉じることになります。最後の夜ということで,パーティが開催されます。ナッシュビルだけあって,皆で音楽ステージがあるダウンタウンのバー(有名なWildhorse Saloon)を借り切って行うことになりました。今回は1,725人の参加者だったので,全員が参加しないとしてもホテルからナッシュビルへのバスの台数は半端ではありません。

画像

ステージの上でライブバンドもあって,踊るスペースもあります。しかし,人が多いので,皆が合わせて踊るMob Danceです。

画像

お店を出たら,もう暗くなっていました。8月なのにクリスマスツリーのように木は電球が飾られていました。

著者プロフィール

小沢仁(おざわひとし)

株式会社オージス総研

米シカゴ育ち。シカゴ大学で物理を専攻。Oracle XDKを日本に紹介,Seasar英語ページを作成,ESB Muleコミッタとして同ソフトの日本ローカライズ/日本語サイト構築,WaveMakerの日本語ドキュメントを作成,Apache ManifoldCFコミッタ/日本語ページやMySQL対応を貢献。IEEE APSCC 2009などでSOAの研究発表も行っている。

Liferayに興味をもち,Liferay.comフォーラムでサポートしたりWikiページを作成している。Liferay6およびLiferfay IDEの日本語化や日本語資料も作成している。2012年にLiferay社からグローバルレベルでの「Liferay Community Contributor of the Year 2012」を受賞。

現在,米ナッシュビルで開催されるAgile2013カンファレンスでオフショア開発についての発表申請に時間を費やしている。