ふりかえりといえば KPT がメジャーですがスクラムマスターによると「難しい手法だと感じている」とのことで、せっかくなので他の手法をいろいろトライしてみています。今日は Lean Coffee をやってみました。
参加意識が高くなるというのがいいですね。
「時間内で話せるだけ繰り返す」という手法でその時間目一杯使うことになるので、他のミーティングの一部として軽くふりかえりたいというのは向かないということもわかりました。
何回か続けて他の利点・欠点も体感したいと思います。
先週参加した Inspired 入門勉強会グループメンバで都合のつく人で交流ランチ。第1回の勉強会のふりかえりや次回の進め方などの話をしつつ、カジュアルにプロダクトマネージャー業の情報交換となりました。
私のグループのチームは今はスクラムで開発していますという話をしたところ、他の3名のところではスクラムを導入していない/できていないとのことでした。
私もスクラムは学びながらやっていて「エッセンシャル スクラムを読む会」という社内勉強会に参加している最中です。
1週1章1時間、(参加者がその回の章を読んできている前提として)その日の当番の人がサマリを発表、流れで随時「ここ良くわからなかったのですけれどどう思います?」とか「私たちの組織・やり方だとここが当てはまっている・違っている」とかそういう会話をする流れでやってます。
といった感じで進めていますと紹介しました。
さっそく戻って読み合わせやろうという話になっているというコメントをもらって、皆さんスピード感があってさすがだなぁと。
本日2017年3月3日に mixi は13周年を迎えました。
mixi運営オフ#3三茶・mixi運営オフ#4中目黒・mixi運営オフ#5喫茶去と3回のmixi運営オフを開いて交流したり、プロダクト担当になって組織・プロセス・サービスについて試行錯誤したり、合宿(1日目・2日目)で mixi の価値について議論してみたり。
昨年の今日からの1年で何が出来たのか、そして何ができなかったのか。ふりかえりつつ今後について考えていきたいと思います。
今まで3つのスクラムチームで別々のプロダクトバックログをもっていたのですが、より大きい視点で優先度を考えつつ優先度の高いフィーチャーから集中的に取り組めるようにしたいと考えるようになりました。
このためしばらく前にいったんプロダクトバックログを1つにまとめました。
プロダクトバックログを1本化してから3回ほど合同でプロダクトバックログリファインメントをしてみたのですが、これはあまりうまくいきませんでした。やはり人数が多いと議論が進まなかったり、人によっては自分ごとに考えにくくなったりしたようです。
またどのチームがどのプロダクトバックログアイテムを担当するかも決めていなかったので、先にスプリントプランニングに入ったチームからやれるものを順番に取っていくかたちになっているという課題もありました。
今回合同プロダクトバックログリファインメントと振り分けはうまくいきませんでしたが、これもまた一つの良い学習だったと思っています。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 -- アジャイル宣言の背後にある原則
やはり複数スクラムチームで仕事を進める場合は代表者を立てる進め方が良いのでしょうか。LeSS (Large-Scale Scrum) のやり方をまず部分的に取り入れてみることにしました。
各チームの代表者が集まって Overall Product Backlog Refinement と Sprint Planning One にあたるアクティビティでスクラムチーム別に振り分けを行い、その後各チーム別にプロダクトバックログリファインメントやスプリントプランニングを実施するようにしてみたいなと。
取り急ぎ今日からのスプリントに入れるように急遽集まって振り分けを行いました。スプリントレビューやふりかえりについてはまた別途考えていきたいなと思ってます。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。
プロセスをスクラムチームが調査するためのものだ。
2月の第15章 さまざまなプランニング以来、4回目の発表担当です。
半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。
本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。
と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。
付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。
ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。
改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!
なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。