nDiki : ふりかえり

今日のさえずり: 「ハウスマヌカン」という言葉が通じないだと?

2016年11月02日

• 08:18 ポチった。
• 17:36 「ハウスマヌカン」という言葉が通じないだと?
• 20:31 ふりかえり、いろいろ考えているうちに「集団解決の型」が最強だというところに回帰した。
• 24:49 Time Machine のバックアップを移動中。

ふりかえりで Lean Coffee やってみた

ふりかえりといえば KPT がメジャーですがスクラムマスターによると「難しい手法だと感じている」とのことで、せっかくなので他の手法をいろいろトライしてみています。今日は Lean Coffee をやってみました。

http://leancoffee.org/

今回のやり方

1. 話し合うトピックを明らかにする。
   1. 5分間で各自付箋紙に話し合いたいトピックを書く。ふりかえりだけれど内容はプロセスにかぎらずプロダクトの事でも良いとする。
   2. 順番に付箋紙を出して話し合いたいことを簡単に説明する(ここでは議論まで入らないようにする)。
      • 同じトピックを書いた人がいればまとめる。
   3. 付箋紙を眺め、話し合いたいと思ったトピックを各自2つ選び、それぞれしれっとその付箋紙にドットを書く。
   4. 付箋紙をドットの多い順に並べる。
2. 話し合う。
   1. ドットの多いものから順に1つ取りで7分間話し合う。
      • 今日はコーチ(スクラムマスター)がファシリテーションをする。ホワイトボードに出た意見を書きだす。
   2. 時間になったらそのトピックを続けたいか親指で続ける(上)・終わる(下)・どちらでも(横)で投票する。
   3. 続けるが多いようなら2分延長する。今日は延長は1回まで。
   4. 時間がきたら途中でもそのトピックはいったん終了する(必要があれば別の機会に議論することとする)。
3. まとめる
   1. 全体の残り時間が無くなってきたところで、今日話し合ったものをふりかえる。それぞれ今後どうするかさっと決める。

雑感

• 良い点
  • 全員の参加意識と議論への集中度合いが高まる。
  • 決める意欲の多い人がいればその場で何か決まる可能性が高い。
• 懸念点
  • 検討する時間が短いので、ぱっと出た意見の影響力が強くなりがち。

参加意識が高くなるというのがいいですね。

「時間内で話せるだけ繰り返す」という手法でその時間目一杯使うことになるので、他のミーティングの一部として軽くふりかえりたいというのは向かないということもわかりました。

何回か続けて他の利点・欠点も体感したいと思います。

今日のさえずり: 電気ファンヒータ出して加湿器出してクリスマスツリーの箱出して扇風機は掃除した

2016年11月20日

• 11:39 RT @HR_mixi: 第4回git challengeがはじまりました。今日は快晴で、git challenge日和となりました。#mixi_git https://t.co/0aIH0Au6uw
• 14:41 電気ファンヒータ出して加湿器出してクリスマスツリーの箱出して扇風機は掃除した。
• 20:46 iOS 版の iA Writer 4.0 でキーボード「日本語 - かな」での空白がいわゆる全角になったの改悪。
• 20:53 もしかして iA Writer 4.0 より前のバージョンからそうだった?
• 22:43 RT @ryuzee: そう、KPT難しい / “ふりかえりで Lean Coffee やってみた | nDiki” http://htn.to/nYDXZU
• 24:36 ふりかえりで Lean Coffee やってみた。 http://bit.ly/2fpUD9V

YWTM はやっていないことを書きにくい

1つのチームのスプリントのふりかえりに YWTM をやってみているのですが、この手法だとフォーマット的に「やっていないこと」をやはり書きにくいですね。

やったことをふりかえるのにはいいのですが、チームで改善サイクルをまわすには KPT(KPTA) の方がやりやすいかなと感じています。

Year-End Party 2016

今日いつもの場所で全社全グループの Year-End Party (YEP)。

そういえば今年は CS 部門からプロダクト部門へ移り、担当範囲・役職・チームメンバなどいろいろ変わった年でした。失うものあり、学んだものあり。個人的にもきちんと1年をふりかえり来年につなげたいなと。

ふりかえりを残しつつ仕事納め

今日は仕事納め。細かいタスクをクリアしたり前倒しでやった GTD 週次レビューで時間が経ってしまって、1年のふりかえりやら来年の計画やらをあまり整理できずに終わってしまいました。ちょっともやもや。

そういえば去年は1年分の one-on-one ミーティングノートのふりかえりもしたんでしたっけ。今年も近いうちにやっておきたいところです。去年の教訓から one-on-one ノートは日付順にしたので上から読んでいきやすくなってます。

渋谷 PdM ランチ会 Vol.1

先週参加した Inspired 入門勉強会グループメンバで都合のつく人で交流ランチ。第1回の勉強会のふりかえりや次回の進め方などの話をしつつ、カジュアルにプロダクトマネージャー業の情報交換となりました。

私のグループのチームは今はスクラムで開発していますという話をしたところ、他の3名のところではスクラムを導入していない/できていないとのことでした。

私もスクラムは学びながらやっていて「エッセンシャル スクラムを読む会」という社内勉強会に参加している最中です。

1週1章1時間、(参加者がその回の章を読んできている前提として)その日の当番の人がサマリを発表、流れで随時「ここ良くわからなかったのですけれどどう思います?」とか「私たちの組織・やり方だとここが当てはまっている・違っている」とかそういう会話をする流れでやってます。

といった感じで進めていますと紹介しました。

さっそく戻って読み合わせやろうという話になっているというコメントをもらって、皆さんスピード感があってさすがだなぁと。

mixi 13周年

本日2017年3月3日に mixi は13周年を迎えました。

mixi運営オフ#3三茶・mixi運営オフ#4中目黒・mixi運営オフ#5喫茶去と3回のmixi運営オフを開いて交流したり、プロダクト担当になって組織・プロセス・サービスについて試行錯誤したり、合宿(1日目・2日目)で mixi の価値について議論してみたり。

昨年の今日からの1年で何が出来たのか、そして何ができなかったのか。ふりかえりつつ今後について考えていきたいと思います。

複数スクラムチームでのプロダクトバックログ振り分け

今まで3つのスクラムチームで別々のプロダクトバックログをもっていたのですが、より大きい視点で優先度を考えつつ優先度の高いフィーチャーから集中的に取り組めるようにしたいと考えるようになりました。

このためしばらく前にいったんプロダクトバックログを1つにまとめました。

人数が多くてプロダクトバックログリファインメントがうまくいかず

プロダクトバックログを1本化してから3回ほど合同でプロダクトバックログリファインメントをしてみたのですが、これはあまりうまくいきませんでした。やはり人数が多いと議論が進まなかったり、人によっては自分ごとに考えにくくなったりしたようです。

プロダクトバックログアイテムの振り分け方法が決まっていない

またどのチームがどのプロダクトバックログアイテムを担当するかも決めていなかったので、先にスプリントプランニングに入ったチームからやれるものを順番に取っていくかたちになっているという課題もありました。

今回合同プロダクトバックログリファインメントと振り分けはうまくいきませんでしたが、これもまた一つの良い学習だったと思っています。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 -- アジャイル宣言の背後にある原則

LeSS

やはり複数スクラムチームで仕事を進める場合は代表者を立てる進め方が良いのでしょうか。LeSS (Large-Scale Scrum) のやり方をまず部分的に取り入れてみることにしました。

• https://less.works/

各チームの代表者が集まって Overall Product Backlog Refinement と Sprint Planning One にあたるアクティビティでスクラムチーム別に振り分けを行い、その後各チーム別にプロダクトバックログリファインメントやスプリントプランニングを実施するようにしてみたいなと。

取り急ぎ今日からのスプリントに入れるように急遽集まって振り分けを行いました。スプリントレビューやふりかえりについてはまた別途考えていきたいなと思ってます。

第22回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。

プロセスをスクラムチームが調査するためのものだ。

2月の第15章 さまざまなプランニング以来、4回目の発表担当です。

半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。

事前準備

本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。

スプリントレトロスペクティブに使う時間

• 60分未満で有益なスプリントレトロスペクティブをするのは難しい。
• 2週間スプリントなら 1.5時間。

と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。

インサイトバックログ

付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。

アクションの決定

ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。

アクションはスプリントバックログへ

改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!

なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド