nDiki : ふりかえり

ふりかえり - retrospective

2016年11月17日 (木)

ふりかえりで 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. 全体の残り時間が無くなってきたところで、今日話し合ったものをふりかえる。それぞれ今後どうするかさっと決める。

雑感

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

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

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

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

スポンサード リンク
[ 11月17日全て ]

2016年11月20日 (日)

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

2016年11月20日

[ 11月20日全て ]

2016年12月14日 (水)

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

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

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

[ 12月14日全て ]

2016年12月15日 (木)

Year-End Party 2016

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

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

[ 12月15日全て ]

2016年12月28日 (水)

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

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

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

[ 12月28日全て ]

2017年3月2日 (木)

渋谷 PdM ランチ会 Vol.1

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

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

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

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

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

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

[ 3月2日全て ]

2017年3月3日 (金)

mixi 13周年

rimage:/nDiki/2017/03/03/2017-03-03-073447-nDiki-1200x800.jpg

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

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

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

[ 3月3日全て ]

2017年3月8日 (水)

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

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

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

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

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

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

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

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

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

LeSS

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

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

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

[ 3月8日全て ]

2017年4月4日 (火)

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

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

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

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

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

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

事前準備

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

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

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

インサイトバックログ

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

アクションの決定

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

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

改善アクションを実施したいのであれば、分離してはならない。統合すべきである!

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

[ 4月4日全て ]

2017年4月14日 (金)

第23回 エッセンシャル スクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャル スクラムを読む会ふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

  • 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
  • チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
  • 原則大事(第3章・第14章など)。
  • WIP を下げる重要性をあらためて学んだ。
  • 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

  • プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
  • スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
  • スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
  • 困った状態であることにメンバが気がつくのを3カ月待った上で物理カンバンを導入してみた(すごい)。

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

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

[ 4月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・PO をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.071127s / load averages: 0.42, 0.58, 0.58
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker