2019/5/25 DevLove関西『「カンバンゲーム」と「宝探しアジャイルゲーム」ワークショップ』に参加しての気づきや学びをまとめた

2019/5/25(土)にDevLove関西『「カンバンゲーム」と「宝探しアジャイルゲーム」ワークショップ』に行ってきました。
非常に楽しく、気づきや学びに溢れる会でした。

devlove-kansai.doorkeeper.jp

メモを取る暇もなかったので、ふりかえってみての学びや気づきを纏めておきます。多少ネタバレも含まれるので、未体験の人は読まない方が良いかも。

なお、カンバンゲームは下記でルール説明とカード全種が公開されているので、準備してやってみたら良いんじゃないかな！

カンバンゲームルール説明
 カンバンゲームカード(全種類)

※名刺用紙やカード用紙に印刷すると良いと思います。

■気づき・学び

カンバンゲーム

進捗してからの仕様変更はやっぱり辛い。
余力があってDoneしちゃうと、勿体ない感があった。
- これは多分稼働率的な考え方。
金銭等の得られる物があって、期限が決まっていると、一気に複数Storyを進めるよりも、1つずつ確実Doneに持ってくのに注力できる
- 最初に期限が決まっていなかったら進め方が変わっていたと思う。
- 現実では、いつまでにどのStoryは最低欲しいとか、Biz的な要件や戦略もあると思うので、ケースバイケース。
マルチスキル持ち（多能工）が多いとスムーズにDoneに持って行きやすい
（解決策をスキルと考えると）如何にスキルを多く持っておいて、かつ持っているスキルをチームで共有できているかが、早く問題を解決するために重要
自己組織化されていて、チームでStoryをDoneすることに注力する方向で意識統一されているのであれば、専属のPrMとか要らなくね？
- ルール上PrMはないんだけど、実際要らないな、と。
詰まっている問題が見えること（共有されていること）も重要
- チームで問題解決に当りやすい
イテレーション毎に進め方が上手くなっていく感ある
工数残が見えると良い
- 現実には見積もり工数そのままでDone出来るワケではないので、その辺りの違いはある。（少なかった多かったり）
- この辺りもルールに組み込めたらもっと学びがありそう
イテレーションの最初に、誰がどのステージを担当するか決めてたけど、柔軟に変更できたらもっと良かった。
- ただ、現実はターン制ではないので現実的な進め方ではない
複数人で同じステージの同じタスクをこなすのは、現実ではペア・モブワークに当たるのかな
- ステージ毎に人を変えてたけど、その進め方だと現実には他の問題が出てくるはず。
- WFによくある仕様等の情報連携の不備とか。

宝探しアジャイルゲーム

イテレーション毎に進め方が上手くなっていく感ある
- （ふりかえりによるものを含めて）気づきがあって、改善していく
BizとDevの情報共有超重要。
- お互いのルール、戦略（システム的・コスト的・営業的、色々）
BizとDevは違う家ビジネスルールで仕事してるので、共有して総合的に戦略策定した方が良い
Bizの要件を早く解決・リリースすることを優先してソフトウェアの綺麗さを蔑ろにすると負債が溜まってコストに直に返ってくる
- Bizにとっては（特に初期の）スピードが大事だけど、コストも大事。
- ケースバイケースだと思うので、適宜情報共有・検討することが重要かな
コスト意識重要
- もう１イテレーションあったらキャッシュがなくなってた
BizがDevのルールや考え方を知らず／無視して仕様まで決めちゃうと負債になりやすい
- ルールを共有した上で、要件（色）だけ出して貰えると、Devがやりやすい
負債を返したいけど、そのイテレーションで何も生み出せなくなると心理的に辛くてよう提案できない
如何に１つのイテレーションで多くの要件をリリースするかを考えるのが面白い
- 同時に、何とか絞り出して追加でリリース出来た時に、Bizに喜ばれるとうれしい