スプリントのタスクを受け入れ条件単位で書く
TL;DR
- スプリントバックログアイテム（よくスプリントのタスクとか言われるもの）を、受け入れ条件の粒度で書くとよいことがチラホラあったという話
背景
- スプリントのタスクを考えるときに、安易に設計・開発・テスト、とかしがち
- 一方で、この切り方で行くと、今作ってるものが方向性あってるっけ？とか、いらないもんまで作ってない？みたいな検査をしたくても、取り返しがつかない
- 結果、PBI が完成してから、過不足に気づいたりして、ムダに悩まされる
何をやるか
- スプリントプランニングのトピック３の際に、スプリントバックログアイテムを、各プロダクトバックログの受け入れ条件（Acceptance Criteria）ごとに作成する
- デイリースクラムでは、スプリントバックログアイテムの進捗を動いている状態で検査する（ミニデモ）
効果
- 計画時に、「なぜやるのか」「何をやるのか・やらなくていいのか」「何がコアバリューなのか」を理解してから作り始めることができる
- 一番コアな部分から作るので、設計がしっかりしやすい（ダメなときはダメ）
- 朝会でインクリメントを見ることができるし、そのうえで、追加の実装の要否やこれでもう十分かも、といった議論ができるようになった
- 詳細な実装タスクにしていないので、モブが加速して WIP が下がる。結果として実装中の会話が増え創発性が向上して想定より良いものができる
- PR で今更言われても、、、になったりしない
- WIP PR だと会話量が少なくて創発的というほどでもない
デメリット
- 何をやれば実現できるか、の検討をリードできる人が欠席しているとリスクが高い
- いままでは計画の日だけ気にしていたとの声
- いろいろ複雑な背景がありそうなのでふりかえりを加速するしかねえなと
- ふりかえりも毎日やればいいか
- いろいろ複雑な背景がありそうなのでふりかえりを加速するしかねえなと
- いままでは計画の日だけ気にしていたとの声
デイリースクラム (朝会) でタスクボードやらバーンダウンチャートを見るな
タイトルは釣り。
デイリースクラム（朝会）で、まず何を見るか、というところが最近気になっている。
よく言われる、「３つの質問」というのが鉄板テンプレートのように言われていることが多いと思う。
３つの質問参考
- 昨日したことは何か
- 今日やることは何か
- 困っていることは何か
について、各自が順繰りに話すというもの。
これについてはイマイチじゃない？、みたいなのは以前書いた。
とはいえ、書いておいてなんですが、これもイマイチだなと。
というのも、避けたい状況として、
「日々ボードとタスクを確認して進めていたが、スプリントゴールが達成できていないことにデモをやるまで気付かなかった」
というもの。
スプリントゴール自体はもちろんスプリントプランニング時点でゴールとして明確化し、達成できるように作業を計画してスプリントバックログを作成する。
しかしながら、現実として、計画時点では、その作業内容で目標を達成できるかどうかは、保証されない。
計画した通りにやればうまくいくはずだ、というのは、ウォーターフォールのおじさんを散々 Dis ってたわりに同じことをやってしまうことになる。少しというかかなりダサい。
そうならないためには、目標に向かっているかの検査と適応が必要になるが、これがデイリースクラムの役割になる。
ではデイリースクラムでは何を見るべきかという最初の話になるが、その時点での「タスクボードのタスク状況」ではなく、その時点までの「インクリメント」を見るのが答えにはなりそう。
少なくともタスクボードを見ても、ゴールに向かえているかは検査できない。
（昨日時点の想定で向かえているかどうかは分かるが。）
----
とはいえ、じゃあタスクボードは意味ないのかというとそういうわけでもなく、デイリースクラムをやって、結果としての反映先はタスクボード（というか、スプリントバックログ）でよいのだろうと。現実的かどうかはバーンダウンチャートとにらめっこすればいいかもしれない。あんまり使わないけど。
これまでの話（検査）はインクリメントで話す
これからの話（適応）はタスクボード（スプリントバックログ）で話す
この2つの使い分けの意識はしておかないと、できているつもりでできていなかったという事態を避けられるようになるのかなと最近思った次第。
※同じ構図はもちろんスプリントレビューとプロダクトバックログにも言えそう
動くソフトウェアこそが進捗の最も重要な尺度です。
って言うし。
----
そう考えると3つの質問は、
- 昨日やったこと（インクリメントを見ながらゴールに向かえているか？）
- 今日やること（何を追加でやるか/やらないか？/よってもって今日は何をやるか？）
- 困っていること（ゴールを達成する上での課題は何か？）
という内容を話していると考えれば、3つの質問でも大丈夫だな。でもやっぱりちょっと無理やりだな。
Celebration から始めるレトロスペクティヴ
ふりかえりアドベントカレンダーの２日目の投稿になります！
https://adventar.org/calendars/8001
ふりかえりで大事なことはなんだろう？今年一番大事だ、伝えたいことはなんだろう？ と思ったとき、一番最初に浮かんだのが、「Celebration からはじめる」というワードでした。
アジャイルなチームは経験主義に根ざしています。
経験主義とは、どうあるべきか（理性主義）ではなく、経験としてどうあったのか、事実に基づこう、という科学的な態度、です。
アジャイルなチームのふりかえりを悪化させる原因として、この理想主義（本来こうあるべきなのに、そうでなかったのはなぜか、というモノの見方）があるように感じています（n=12）
ある意味この考え方は、「正解があって、そこに至るにはどうあるべきか？」といった我が国の教育指針、育ち方が背景にあるのでは？と感じています。
こうした考え方を打ち破るにはどうしたら良いのか，日々スクラムチームと対峙する中で悩んでいます。
こうした中で一つ見えてきたプラクティスとして、タイトルに書いた、「Celebration から始める」というアイデアがありました。
Norm Kerth の Prime Directive にある通り、我々は全力を尽くしたことを疑わないことから始めれば良いのではないか。
そうはいっても、長年の教育により培われた、「あるべき正解に近づかなければならない」といった理性主義の脱却は簡単ではないです。
「Celebration から始める」というプラクティスは、ふりかえりを始めるにあたり、「まず、このスプリント/イテレーションを走り切った自分たちに対して、まず祝福（Celebration）を送ろう」というものになります。
拍手でもいいし、全員に対する kudo カードでもいいです。
自己肯定感の醸成、とか、そういった陳腐な言葉で表記することはできますが、まずは当たり前に自分たちの経験、これまでを祝福する、という態度を明確にすることによって、理性主義の脱却と、経験主義への一歩を踏み出すことができると感じています。
スクラムマスターや上司が抱く、チームのあり方に対する理想があります。
コミュニティで見かける、素晴らしいチームの在り方を目にすることもあります。
そうした理想を抱くことは大事です。でも、そこへ向けて、まず最初の一歩を踏み始めるには、"いま" 自分の足を置いている経験を認め、足元を確かにすることが何よりも大事だと思います。
そのために、いま自分が足を置いている場所を確固なものとし、次に向かって一歩を踏み出すために，今までの自分たち、その足元をありのままに認める、祝福する、Celebration が必要なのだとおもいます。
あなたはいま、ふりかえりをする中で、今の自分たちの在り方をはじめに祝福できていますか？
脱「ちゃんと」病
何かを改善するときに、
「ちゃんと○○できるようにするには」
みたいな方向にどうしても行きがちになる気がする。
ex1. 本番障害が発生した → テストをちゃんとやる ex2. デモで手戻りが発生した → ちゃんと要件・仕様を詰める
みたいな。
この「ちゃんと」病に取り憑かれるのは、Waterfall 時代の癖なのかもしれない。
もちろん、事前に抑えられるなら事前に抑えたほうが良いのは絶対にある。が、限度もある。
100% をちゃんと事前に抑えるのは無理だと諦めたほうが良くて、せいぜい8割が事前に抑えられれば良い方だと思う。（要出典）
で、残りの2割に対して、「ちゃんと○○しよう」というアプローチでやっても、無駄なコストがかかるばかりになってしまう。
そもそも、「ちゃんと要件を事前に決めるなんて無理でしょ」みたいな事実から継続的に検査と適応をしないといけないよね、というのがアジャイル開発のモチベーションの大きな一つなはず。
じゃあ、どうするか。
MTTR vs MTBF を両輪で使い分けるのが大事な気がする。
問題を起こさないことと、問題が起きたときにその影響を極小化したりすることで問題の影響を抑制する方向を考える。
ex.社内でインフルエンザが流行って作業が進まず、遅延が発生する → インフルエンザが流行らないようにする ← そのために、注意喚起、手洗いうがい、アルコール消毒機器を置く → インフルエンザが流行っても問題が大きくならないようにする ←タスクを属人化させない、バッファを確保する、休みやすい環境にする、Plan B を決めておく
ex. メモリが貼りついて本番障害が発生し、売り上げ機会を逸した → メモリが貼りつかないようにする ← スタックした部分を修正する → メモリが貼りついても問題が大きくならないようにする ← 構成を冗長化する、スケーラブルな設計にしておく、定期的に再起動する
どっちも重要だし、どっちもやったほうがよさそう。
どちらかだけで何とかしようとするのは割と悪手な気がする。
どちらがいいというわけではなく、「ちゃんと○○しましょう」という言葉が出てきたら、ちょっと待てよ？無理スジなのでは？って考えるようにしたい。
Daily Scrum が終わったらホイッスルを吹かれても大丈夫か
昨日、Scrum Master's Night に参加してきました。
その中で、ファシリテーション難しいよね、ってテーマに参加させていただきました。同じテーブルの皆さま、ありがとうございました。
その中で、デイリースクラムのファシリテーションをどうやってもらうか、っていう話題になりました。
アジェンダや何を話すかを明確にしておくことで、安心してファシリテーションをやってもらえるんじゃないか、といった話もあり、一方で、デイリースクラムの目的というかゴールだけ伝えておけば、自分たちでどうやるかは考えられるんじゃないか、みたいな話になりました。
で、デイリースクラムのゴールってなんじゃらほい、みたいな話になり、そこで話したのが、表題に書いたことに関係する、「ホイッスル吹かれても大丈夫か」っていう話でした。（なんのこっちゃ）
続きを読む