distributed-agile-team.connpass.com
今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。
長めの前段(?)
OSTのテーマ選定前に、hisaさんの論文あれこれと、先日の本編後の本編で話されていた形跡があったMaking Softwareのお話を聴いていきました。
hisaさんは、論文を絶賛執筆中ということですが教授からのダメ出しなどが本当に大変なようで、何に悩んでいるのか分からないけど焦ってしまっている気がする、というお話をしてくれていました。
皆さんからは、論文を書くコツやどういう論文が見やすいか？という観点で幾つか記事が紹介されていました。
次に、前回の本編中の本編で話されていた内容(Making softwareが紹介されていました)が気になった自分が、きょんさんにどんな話がなされていたのか教えてもらいました。
どうやら、きょんさん森さんが「この本いいよなあ(きょんさん森さんのニーズが満たされているなあ)」と思っている本を挙げた結果紹介されていたようで、この流れから、きょんさん森さんが本にどのような要素を求めるのか、森さんがいいなあと思った本*1、ICSE勉強会の話...を教えてもらったりと、いきなりエンジン全開でした笑
本編後の本編でこれだけ面白い話がされているのを知って、参加できていないのがより悲しくなりました。
Impediment Listってどう管理してるの？
久しぶりに会に来てくれたなべさんから、OSTのテーマとしてImpediment Listの管理方法について話したいというテーマが挙げられてきました！
なべさんは、色んなものをインプットにしながらスプレッドシートやMiroでImpediment Listを蓄えて、その上でどんな所に影響があるんだっけ？を状況把握して、チームやPOと問題になりそうな部分を話し合いながら優先順位づけしていたそうですが、短期的な視点に偏る傾向にあるようで、今回テーマを挙げてくれたそうです。以下、話されていたことを箇条書きで書いていきます。
- タスクと同じように管理する。あんまりタスク/impedimentで区別はしない
- オーナーは明示的に決めておく。決めておかないとやらないので
- No/妨害していること/何が問題か/完了条件/コミットメントポイント/オーナーで管理
- 直ぐにチケット管理する
- 見える場所にチケット(課題)を貼っておく
- 政治力がある人を味方につける
- この辺の知識が必要そう、を言語化。分かっていないことは調べて勉強
- そもそも、impediment Listをあまり必要としないというコンテキストもある。例えば、フィージビリティー起因で出てくる障害が少ない, ディスカバリー・フェーズだからこそといった理由だったり、毎日ふりかえりをして小さくアクションを決めていく運用をしていたり...
- 制御可能性に注目する。毎回障害になっているのにいつまでたっても消えないものは制御可能性が低いと言える
- 気分屋の人のせいでスプリントレビューが思うように進まないことがあった。こういう場合、例えば上司を連れてくると気分屋が治ったりする可能性がある。
- 忙しくて改善の余裕がない、という状況を改善するために生まれたSaPIDは役に立つかもしれない
- ちょっと話題に出たらメモレベルでいいから書いておく
- それぞれの立ち位置でしか見えないimpediment Listがある。その人の認知の枠組みが透けてみえるし、その人だからこそ障害だと思えることとかがある。こういったことを観察していると面白い。どのようにチームに共同所有できるようになっていくのかな、とか
全体を通した感想
分散アジャイルチームらしいOST祭りで、今回も参加者皆さんから全然異なる視点の意見を聴けたり、贅沢なお話が聴けたり、幸せな時間を過ごすことができました。
impediment Listについての知見が溜まったという意味でも勿論有意義なのですが、皆さんがどのように物事を捉えているのか/どのような思考の過程を辿るのか、というバリエーションが非常に豊かなお陰で学びも深いし、何か特定の考えを押し付けられているような感じもなくて受け入れやすくて、改めて分散アジャイルチームの会の良さを実感しました。
久しぶりにお見かけしたなべさんが相変わらずなべさんで、今回も神回でした！
*1:学習科学ハンドブック、マンキュー経済学、世界標準の経営理論
