nDiki : スクラム

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。

スプリントレビュー

スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。

不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。

という、ちょっと最初は勇気が必要なアクティビティです。

この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。

スケジュールの調整

スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。

スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。

きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。

スプリントレビューのアウトプット

リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。

ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。

これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。

デモ

デモが難しいからといって、それはデモをしない理由にはならない。

プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。

スプリントレビューはスクラムマスターと協力してきちんと設営していく必要があるなと感じました。

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

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

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

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

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

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

事前準備

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

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

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

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

インサイトバックログ

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

アクションの決定

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

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

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

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

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

今日のさえずり: スクラムチーム1つ解散

2017年04月05日

• 12:59 スクラムチーム1つ解散。

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

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

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

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

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

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

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

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

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

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

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

などが上がりました。

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

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

などの話が出ました。

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

全23回

• 2016年10月25日 第1回 第1章 イントロダクション
• 2016年11月01日 第2回 第2章 スクラムフレームワーク
• 2016年11月08日 第3回 第3章 アジャイルの原則
• 2016年11月15日 第4回 第4章 スプリント
• 2016年11月22日 第5回 第5章 要件とユーザーストーリー
• 2016年11月29日 第6回 第6章 プロダクトバックログ
• 2016年12月06日 第7回 第7章 見積もりとベロシティ
• 2016年12月13日 第8回 第8章 技術的負債
• 2016年12月20日 第9回 第9章 プロダクトオーナー
• 2017年01月10日 第10回 第10章 スクラムマスター
• 2017年01月17日 第11回 第11章 開発チーム
• 2017年01月24日 第12回 第12章 スクラムチームの構成
• 2017年01月31日 第13回 第13章 マネージャー
• 2017年02月07日 第14回 第14章 スクラムのプランニングの原則
• 2017年02月14日 第15回 第15章 さまざまなプランニング
• 2017年02月21日 第16回 第16章 ポートフォリオプランニング
• 2017年02月28日 第17回 第17章 エンビジョニング (プロダクトプランニング)
• 2017年03月07日 第18回 第18章 リリースプランニング (長期計画)
• 2017年03月14日 第19回 第19章 スプリントプランニング
• 2017年03月21日 第20回 第20章 スプリントの実施
• 2017年03月28日 第21回 第21章 スプリントレビュー
• 2017年04月04日 第22回 第22章 スプリントレトロスペクティブ
• 2017年04月14日 第23回 第23章 未来へ

今日のさえずり: 昔、ケーキといえば芝大門の izumi のでした

2017年04月27日

• 08:34 今日はいい日だ。
• 09:00 某氏、土曜日はドールを連れて撮り歩くのかな。
• 11:00 試供品としてついてきていたリステリン トータルケアは洗口液ではなくて液体歯磨きだったのか……。クチュクチュペしかしてなかったよ。後味が悪い訳だ。
• 14:50 さよならランチ。 (@ 青山 星のなる木 in 渋谷区, 東京都) https://www.swarmapp.com/c/kmMqWLsaLib
• 18:38 歩きたこ焼きの人に遭遇した。
• 18:50 窯出しとろけるプリンも窯焼きとろけるプリンも終わってる。
• 21:50 RT @harakachi: なんか変だなって思う気づきと、何が変なんだろうって潜る力が、スクラムに出会って界王拳ぐらい増した気がする。善し悪しの判断基準が出来たからなんだろうなあ。
• 22:23 昔、ケーキといえば芝大門の izumi のでした。

スクラムマスターのいるチーム 【日記】

暑いのでお昼は社内販売の弁当。

スクラムマスターのいるチーム

やはりスクラムマスターがいるのといないのとでは、スプリントの回しやすさ・プロセス改善のしやすさが全然違うなと感じています。スクラムをやるまでは謎な存在でしたが偉大さがわかってきました。

Prime Dayセール

安くなっていた Fire HD 8 タブレット (Newモデル) 16GB を購入。

• Fire HD 8 タブレット (Newモデル) 16GB

シューズ25%オフにつられてニューバランスのウォーキングシューズも買い足し。

メンテナンスフェーズに入ってきたプロダクトの保守とスクラム

メンテナンスフェーズに入ってきたプロダクトを保守しているスクラムチームのプロダクトバックログが枯渇してきました。無理に新しいことを絞り出して手を入れ続けるのが得策ではない感じに。

もはやスクラムで開発には適さない領域に入ってきたのかもしれません。一段上のレベルに戻ってプランニングするのが良さそう。

今日のさえずり: Emacs を起動して M-x shell してゔぃむしたら崩れた

2017年08月01日

• 13:22 メンテナンスのみの領域に入ったら、もはやスクラムは最適ではないということ。
• 13:34 Emacs を起動して M-x shell してゔぃむしたら崩れた。
• 24:35 ドライヤーをかければすぐ寝られる事を最近覚えたのだが、この時間にドライヤーをかけるの面倒だというのも最近覚えた。

何もコミットしないスプリントで各自好きなことをする

インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。

リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。

普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。

ちなみにこの取り組みは去年別のチームが unwinding period と呼んでやっていたのを真似てみたものです。

今回スプリントがどういう感じだったのかは、いつも通りスプリントレトロスペクティブでふりかえってみます。

---

[ スクラム ]

仕事に追われない仕事術 マニャーナの法則 完全版

タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。今までスルーしていたのですがここ最近クローズリストの考え方を取り入れてみているので、その辺りの話が書かれている「仕事に追われない仕事術 マニャーナの法則 完全版 (Do It Tomorrow and Other Secrets of Time Management)」を読んでみました。

• 仕事に追われない仕事術 マニャーナの法則 完全版

マニャーナの法則

まずマニャーナの法則ですが

• 原則1 新しい仕事は「明日やる」を基本にする
• 原則2 クローズリストを使う

という2つの原則のこととあります。日本語ではマニャーナの法則と訳されていますが the mañana principle なので「(行動)原則」の方が適切に感じました。

「すぐやる」ことの弊害

すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。

「すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。

ただ「すぐやる」については

• 「後回しにしてチャンスを逃す」ことのないようにする。
• 先送りすることで増大するコストを最小化する。

というメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。

全員がマニャーナの法則をやるとどうなるか?

個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。個人の稼働が最適化されるかわりに、作業の手待ち(idle work)が多く発生することになるからです。

このあたり要注意に思われます。

緊急レベルを判断する

入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。

• 緊急レベル1「今すぐ」
• 緊急レベル2「今日中に」
• 緊急レベル3「明日やる」(ベスト)

本書では「明日やる」がベスト。

これはすでに2週間前からRemember The Milk の優先度設定に取り入れてみています。

WILL DO リスト

その日にやるとコミットしたタスクを入れておくクローズリスト。自分は Remember The Milk でタスクの優先度を1にすることでリスト化しています。

処理する順番はファースト・タスクが最初で「明日のリスト作成」が最後です。それ以外はまったく自由。

1日の最後に何をおいても明日の WILL DO リストは作成することが必須とあります。仕事については実践していますが、プライベートでは翌日の WILL DO リストを夜に作るのがまだ習慣にしきれていません。

ちなみに本書ではタスクにかかる時間の見積もりについてはほとんど触れられていません。翌日時間が足りず WILL DO リストを完了できそうもない場合もいつもどおりリストを作成し翌日は「できるとこまでやる」「完了できない日が続くなら対策をとる」という感じになっています。

やり残しをどうするか?

WILL DO リストで完了できなかったものは、「やり残し」フォルダに放り込み、ファースト・タスクで処理しましょうとあります。

これは今週から Remember The Milk で backlog タグを付けるようにして実践中です。

ファースト・タスク

ファースト・タスクは「毎日の最初に行い、そこから1日をスタートさせるのが望ましい仕事」とのこと。毎朝最初にできる仕事は1つしかないので、常に1つ。

• 原則1 とにかく、する (Do)
• 原則2 一番始めに、する (First)
• 原則3 毎日、する (Every day)

ファースト・タスクに向いている仕事は

• 「やり残し」を片付ける
• 仕事のシステムを修正する
• プロジェクトを進める

です。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。

実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。

ダッシュ法

ダッシュ法はポモドーロテクニックにつながるところを感じました。ちょっとマニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。

二分等法 すべての仕事を半分にする

プロジェクトをタスクに分解する方法。 GTD でプロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。

その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。

全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。

行動の合間に考える習慣をつける

最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。

• 「毎日15分」など時間を決め確保する。
• 邪魔が入らない場所でノートと筆記用具を用意し、浮かんできたアイデアや考え方をノートに書き留める。
• 時間の終わりに近づいたら書いたものについて考える。良いアイデアや行動が必要なことに下線を引く。

というものです。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。ぜひ取り組んでみたいなと思います。

冒頭にキーワードが説明されているのが良かった

最後に本書の構成について。

本書では冒頭で「本書に登場する18のキーワード」として

• 「クローズ・リスト」「オープン・リスト」「チェック・リスト」
• 「コミットメント」「本当の仕事」「忙しいだけの仕事」
• 「バッファー・ゾーン」「マニャーナの法則」
• 「タスク」「プロジェクト」
• 「タスク・ダイアリー」
• 「デイリー・タスク」「ファースト・タスク」
• 「TODOリスト」「WILL DOリスト」
• 「ダッシュ法」「期限の効果」
• 「ラベリング」

が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。

本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。

• 仕事に追われない仕事術 マニャーナの法則 完全版

---

[ 読書ノート ] [ お薦めの本 ]

何もコミットしないスプリントで各自好きなことをして得られたもの

「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良い1週間スプリントが終わったのでチームでふりかえりました。

何をやらなかったか?

• スプリントプランニング。スプリントバックログは空。

何をやったか?

• チームとして
  • デイリースクラム(朝会)はいつも通りやった。
  • プロダクトバックログリファインメントもいつも通りやった。
  • スクラム外でやったことをレビューした。
• 開発メンバがやったこと
  • プロダクトバックログアイテムを準備完了にするための情報収集・まとめをやった。リリースできるものはリリースまでした。
  • BTS にある不具合報告についてどんどん調査をした。
  • まとまった時間でシェルの設定を見直して開発しやすくした。QOL が上がった。

このチームが自主的に決めたワーキングアグリーメント(記事)に

スプリントゴールが全て達成された場合は、優先する割り込みタスクがあれば対応し、そうでなければ準備完了になっていないプロダクトバックログアイテム(PBI)に関する情報収集・まとめを優先度の高いものからしよう。」

というのがあり、この活動をしていたメンバが多かったです。「スプリントバックログが空 = ただちにスプリントゴールが達成されたので PBI の準備に取り組んだ」わけですね。

環境整備にあてたりとかはあまり多くなかったようです。シェルの設定見直しをしたエンジニアは「失敗したら1日潰れてしまいそうで普段やれなかったことをできた」とやって良かったと言っておりました。

どう感じたか?

開発メンバからは以下のような意見が出ました。

• 「スクラムを始める前のチケット駆動開発時代に戻った感じ。」
• 「スクラムで開発をしない場合(タイムボックスが無い場合)、個人でしっかり時間・タスク管理する能力が求められると感じた。」
• 「半年に1度くらい頻度でまたやりたい。」
• 「スクラムでやりたい。」

得られた気付きは?

• タイムボックスの良さにあらためて気付いた(期日から逆算していつまでに何をやるということを考えやすい)。
• 複数人で作業を見積もることで自信が得られることに気が付いた。

自由になったことで、普段やっているアクティビティの良さを再認識できたようです。チームが取り組んでいるプロダクトの状況から考えるとスクラムではなくカンバンの方が進めやすいのかもしれないのではと私は考えていたのですが、今回の取り組みで開発メンバは「スクラムで続けたい」と改めて思ったとのことです。

スクラムの基本からは外れる取り組みではありましたが、基本通りにやっていたのでは感じ考えることのことができないことを得られたという意味では非常に有意義な1週間でした。