海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

デイリースクラム (朝会) でタスクボードやらバーンダウンチャートを見るな

タイトルは釣り。

 

デイリースクラム(朝会)で、まず何を見るか、というところが最近気になっている。

 

よく言われる、「3つの質問」というのが鉄板テンプレートのように言われていることが多いと思う。

 

3つの質問参考

  • 昨日したことは何か
  • 今日やることは何か
  • 困っていることは何か

について、各自が順繰りに話すというもの。

 

これについてはイマイチじゃない?、みたいなのは以前書いた。

 

bbbbashiko.hatenadiary.com

 

とはいえ、書いておいてなんですが、これもイマイチだなと。

 

というのも、避けたい状況として、

 

「日々ボードとタスクを確認して進めていたが、スプリントゴールが達成できていないことにデモをやるまで気付かなかった」

 

というもの。

 

スプリントゴール自体はもちろんスプリントプランニング時点でゴールとして明確化し、達成できるように作業を計画してスプリントバックログを作成する。

 

しかしながら、現実として、計画時点では、その作業内容で目標を達成できるかどうかは、保証されない。

 

計画した通りにやればうまくいくはずだ、というのは、ウォーターフォールのおじさんを散々 Dis ってたわりに同じことをやってしまうことになる。少しというかかなりダサい。

 

そうならないためには、目標に向かっているかの検査と適応が必要になるが、これがデイリースクラムの役割になる。

 

ではデイリースクラムでは何を見るべきかという最初の話になるが、その時点での「タスクボードのタスク状況」ではなく、その時点までの「インクリメント」を見るのが答えにはなりそう。

 

少なくともタスクボードを見ても、ゴールに向かえているかは検査できない。

(昨日時点の想定で向かえているかどうかは分かるが。)

 

----

 

とはいえ、じゃあタスクボードは意味ないのかというとそういうわけでもなく、デイリースクラムをやって、結果としての反映先はタスクボード(というか、スプリントバックログ)でよいのだろうと。現実的かどうかはバーンダウンチャートとにらめっこすればいいかもしれない。あんまり使わないけど。

 

これまでの話(検査)はインクリメントで話す

 

これからの話(適応)はタスクボード(スプリントバックログ)で話す

 

この2つの使い分けの意識はしておかないと、できているつもりでできていなかったという事態を避けられるようになるのかなと最近思った次第。

 

※同じ構図はもちろんスプリントレビューとプロダクトバックログにも言えそう

 

動くソフトウェアこそが進捗の最も重要な尺度です。

 

って言うし。

 

----

 

そう考えると3つの質問は、

 

- 昨日やったこと(インクリメントを見ながらゴールに向かえているか?)

 

- 今日やること(何を追加でやるか/やらないか?/よってもって今日は何をやるか?)

 

- 困っていること(ゴールを達成する上での課題は何か?)

 

という内容を話していると考えれば、3つの質問でも大丈夫だな。でもやっぱりちょっと無理やりだな。

 

Celebration から始めるレトロスペクティヴ

ふりかえりアドベントカレンダーの2日目の投稿になります!

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 に参加してきました。

smn.connpass.com

 

その中で、ファシリテーション難しいよね、ってテーマに参加させていただきました。同じテーブルの皆さま、ありがとうございました。

f:id:Bashiko:20211209235026j:plain

その中で、デイリースクラムファシリテーションをどうやってもらうか、っていう話題になりました。

アジェンダや何を話すかを明確にしておくことで、安心してファシリテーションをやってもらえるんじゃないか、といった話もあり、一方で、デイリースクラムの目的というかゴールだけ伝えておけば、自分たちでどうやるかは考えられるんじゃないか、みたいな話になりました。

で、デイリースクラムのゴールってなんじゃらほい、みたいな話になり、そこで話したのが、表題に書いたことに関係する、「ホイッスル吹かれても大丈夫か」っていう話でした。(なんのこっちゃ)

続きを読む

スプリントに割り込ませるとき

いつスプリントで実施する PBI を変更するのか

 

そもそもスプリント期間中は追加でやることを増やさない。とされている。気がする。なんとなく。

 

スプリント計画でやる PBI を決め、スプリント期間中はその達成に集中する、ってどこかで聞いた気がする。

 

だから、スプリント中に実施する PBI は変えない、というのが答えな気がする。

 

 

----

 

そもそもスプリントの目的ってなんだっけ?

 

スクラムガイドに書いてある通り、スプリントゴール がそのスプリントの目的になる。

 

スプリントで着手する PBI は、スプリントゴールを達成するために必要となるものを実施することになる。

 

逆に言えば、スプリントゴールに関係ない PBI は、そこまで頑張らなくてもいいかもしれない(本当か?)

 

(むしろゴールに集中できなくなるし入れない方がマシかもしれない。YAGNIYAGNI。)

 

スプリントゴールに向かって進む中で、スプリントゴールを達成するために、今やっている PBI だけじゃ足りない、とか、この PBI なくてもスプリントゴールは達成できるな、と分かったときは、どうしたら良いだろうか。

 

そんなときに、スプリントで予定していた PBI を追加したり、やめたりすればいい。

 

f:id:Bashiko:20210604015232p:image

 

----

 

本当にそうだろうか?例えば PBI でいえば。

 

PBI にも達成する内容が決まっていて、Done の定義がそれに該当する。

 

PBI を完成させるために何をすればいいか、作業内容を計画時点で洗い出す。

 

ところである PBI に着手したときに、予定外の作業をやらないと、Done にならないことがわかった。

 

そんなときにどうするか、となると、当たり前だが、計画外の作業をやらずに完成させない、、、のではなく、計画外の作業を実施して完成させることになる。当たり前すぎる。

 

PBI を完成させるのに作業が不足しているなら、追加してやればいい。

 

スプリントゴールについても同じで、スプリントゴールを達成すのに PBI が不足しているなら、追加してやればいい。

 

プロダクトゴールについても同じで、プロダクトゴールを達成するのにスプリントゴールが不足しているなら、追加してやればいい。

 

無駄ならやるつもりだったとしてもやめればいい。作業も PBI も一緒。

 

----

 

いつ PBI を追加するとか、やめるとか考えるといいのか?

 

要は、いつスプリントゴールに向かっているかを確認すればいいのか。

 

結局のところ、Daily Scrum がそれに当たることになる。

 

Daily Scrum でなにを話すと良いのか。要は進捗。

 

何に対する進捗を見ればいいのか?となると、お察しの通り、スプリントゴールに対する進捗であって、スプリント計画でやると決めたスコープが終わっているかどうかではない。

 

日々完成させた PBI を通じて、スプリントゴールを達成できるかを検査する。

 

となると、スプリントバーンダウンチャートなんて見てても、進捗なんて追えないってことがわかってくる。

 

バーンダウンチャートで進捗が追えると思っているということは、スプリントゴールが見えていないことの裏返しになる。

 

「計画したことが終わるかどうかが進捗であり、その過程での変化を拒絶する」

 

これって計画駆動の忌避したかったウォーターフォール脳じゃないの?

 

----

 

そもそもスプリントゴールは何で記載すべきか?

 

スプリントゴールは、スプリントで予定していた PBI の総量という訳ではないはず。

 

プロダクトゴールに進む上で、どういうステップで進んでいくかという作戦目標がスプリントゴールになる。

 

ゴールなので、「〜〜をやる」という表現ではなく、検査可能な “状態“ で記載されることが望ましくなる。

 

----

 

というわけで、

 

ゴールに向かって進むのであって、与えられた PBI をチームで仲良くやっていればいい訳じゃないよね、っていう話。(終わり)