概要

1日目の参加報告に続き Regional Scrum Gathering Tokyo 2015 : Day 2 Open Space Technologyにも参加しました。 2日目は、Open Space Technologyということで、ScrumMastersNight形式で、皆で議題を持ち寄って各スペースで議論をする形でした。いくつか参加したので、議論の内容のメモと、それに対する追記を残します。

LeanCoffee
経営陣に話すスクラムのビジネス的価値
どのフェーズで誰とUXを検討しているか
変化を作るUXの話
KPTのマンネリ化の対策
小さな失敗をどこまで許容できるか
大きな組織の中で上手く生きる話

LeanCoffee

お昼時に、LeanCoffeeが開催された。
最初に話たい内容をみんなが付箋に書いて集める。書いた議題を1つ15秒で説明する。
次に、話をしたいテーマに対して投票する。票の多かったものから議論する。
1つのテーマは7分で話す。
時間がきたら以下の3種のサインを使って全員でジャッジ。

満足：十分な議論ができて結果が出た。次の議論へ移ろう。
継続：もう少し話をしたら成果が得られそう。継続。
不満足：満足できなかったけど続けても無駄。次の議論へ移ろう。

経営陣に話すスクラムのビジネス的価値

経営陣に「スクラムでやってもいいよ」って許可を貰うためには、何かしらの価値を説明できないといけないはず。新たにスクラム導入の許可を貰うための方法を議論しました。

一案

ストーリーボード形式で相手がどんな嬉しいことがあるのか説明する。
エピソードとしては、樽本さんの書籍執筆の話が上っていた。
書籍を執筆するときに先頭から書き始めたら予定よりも1年オーバーして完成して出版になった。
書きたい所から書いて相手に見せていたら、「もう十分価値があるので出してしまいましょう。」といった流れになった。
スクラムで常に状況が見える化することで、他の人がビジネス的な判断を下しやすくなる。

追記

スクラムに限らず、相手に説明するときには説明相手の言葉で説明する。
例：「スクラムって実はPDCAを早く回すためのツールの集まりなんですよ」など
相手がPDCAを大事にしろって言う人ならPDCAを回すためのツールなんですといった、相手に合せる。

説明相手が気にしている指標があるなら、その指標がどう向上するか話せばよい。
売り上げを気にするなら、スクラムを使うとどう売上を上げられるか話す。
例：「完成してからリリースだとお金を得られるのが遅くなりませんか？5割できた所で3割の値段でお試し価格で使ってもらってはどうでしょうか。」

相手相手も誰かに許可を貰うことも少なくないはず。
説明相手と一緒に、もっと先にいる承認をする人にYesと言って貰えるように考えましょう。

こちらも参考になれば。エバンジェリスト活動から学んだ説明の方法 - 学んだことの記録

どのフェーズで誰とUXを検討しているか

一案

毎回スプリントを回すのとは別にユーザテストやユーザインタビューなどの時間を別途用意しておく。全体の3割程度の時間は、UX検討に利用する。

変化を作るUXの話

セッション間の時間にUXについて話をしたので、そのメモ。
新システムを開発しても、ユーザは旧システムを使い続けてしまう。
そんな場合、旧システムを逆に不便にしてしまうのも方法ではないか。
例えば、旧システムに対して遅延を発生させる。すると、自然に新システムへ移行するようなこともある。

上記の場合は、社内システムだから使いやすかったが、
ゲームなどの替えが聞くもので他社が提供している場合には、一部は他社に移ってしまうことも考えられる。
流出を少なくするためには、先に新システムを公開してスムーズな移行をするようにする。

結論：変化に対応するよりも、変化を作るほうが楽だし楽しいよね。

KPTのマンネリ化の対策

スクラムの振り替えりの時間にKPTをやっていると、どうもマンネリ化したり
上手くいかなくなることも多い。複数の方が同様の疑問を持っていた。

一案

KPTだけが振り返りの方法ではないので、KPTを止めればいいのではないか。
アジャイルレトロスペクティブズには、複数の振り替えりの方法が書かれているので、
こちらを参考に自分達に合っている方法を選べば良い。

また、振り返り自体に飽きてしまっている場合には、いっそ期間を決めて振り返りを止めてしまってもいいのではないか。
必要だったことが皆で再確認できる。

追記

議論中にもあったが、どうしてKPTが日本だとこんなに上手くいかないか。
欧米は日本よりも成果主義なのではないかと考えている。
というのも、日本では成果がたいして報酬に継がらないので、
自分達に都合の悪いルールを課してまで生産性を上げようとしないのではないか。
自分が土日に有志で集まって物作りをしているチームだと、「良いプロダクトを作りたい」や「自分達のスキルを上げたい」と思っているので
真剣にKPTできているし本気で取り組んでいる。

小さな失敗をどこまで許容できるか

アジャイルを取り入れるのは許可が下りていて実践できるのだけど、最初のプロジェクトで失敗すると「やっぱりアジャイルはダメだったね」となりやすい。なので、どこまで許容されるのだろうか、どうすれば良いのだろうかという事を話あった。

写真を撮り忘れたのと、書記だったので書き起せず。

大きな組織の中で上手く生きる話

合間に組織で生き抜く方法についてお話を聞いたのでいっしょにメモ。

あまりやろうとすることに前向きじゃない上司がいるなら組織移動できるように振る舞うほうがいいよね。
自分がやってる活動が、どこかに役立つならどんどんやればいい。
やりづらいと思った上の人はその人を手放そうとするし、それを役立つって思う人は拾ってくれる。
そうやって自分の居場所が良くなるようにするのも大事じゃない？
上長が理解してくれないなら、理解して貰える人の所に移ればいい。

何かお願いされたら、その場でリソース交渉する。
相手も頼んでいる立場なので、その場だと交渉に応じてくれやすい。

まとめ

自分が今まで教えてもらったり考えたりしていたことが意見することで他の人の役にたって良かった。本の著者の人も沢山来ていて、そういった人からも意見に対して良い評価を貰うことができた。新しい出会いが沢山あり学びも沢山あったので参加してよかった。良い経験になった。

実行委員の方々、スポンサー様、スタッフの皆様、本当に良いイベントありがとうございました。