beyond-hardware-agile.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていきます。
OSTなので、話し合ったことを上から順につらつらと書いていきます。
モチベーションとか、問題意識具合がバラバラで、各ロールが集まったチームが、開発の足回りを揃える方法
以下のような話が出ていました。
- タスクやスクラムイベントのファシリテーションをサインアップしていった結果、チームが少しずつ自律を持っていけた。
- 色々な課題が見えてしまうと、これもやらなきやあれもやらなきゃ、と考えてしまう。それよりも、ここはコストパフォーマンス低いけど効果がありそうだな、と思えるようなものからやっていってもいいかもしれない。チームでステップを踏んで成長していく。
- 何が問題だと思っている、というのをみんなでシェアしてみる。
- 改善することに慣れていない人もいる。まず、自分から見れば大したことのないような問題でもいいので小さな問題を改善してもらう。
- やめることをしてみてもいいかもしれない。これもやらなきゃの足し算ではなくて、これはやらない、の引き算をするといいのでは？と思う。
- インセプションデッキとかでまずチームで話し合いをしみてる。会話の練習をしていく。
- メンバーを信じる。もちろん信じてるだろうと思うが、信じていないような態度を取っていないか見直しする。
- メンバーと対話する準備のために、自己開示する。三段階具体化する。「SMAPが好き」ではなくて、「SMAPが好きでファンクラブにいる」→「10歳の時からSMAPが好きでファンクラブにいる」→「10歳の時からSMAPが好きでファンクラブにいて、ライブを見るために上京してきた」
- しっかりしている人に対して相談しにくいという経験があった。そのため、だめな自分や困っている自分をもっと出せると、色んな人が話しかけてくれるかもしれないし、自分自身も楽になる。
- 頑張らなくていい。うまくいかなかったらまた相談すればよい。
アジャイルコーチや参加者の皆さんがヒアリングをしながら、ポイントを絞って質問に対する回答を考えていく様子を見るのは毎度のことながら勉強になりました。
スクラム途中参加のデベロッパ，技術のキャッチアップに苦労して定着してくれない
以下のような話が出ていました。
- 技術的な指標を測る。まずはコード行数。できればCIに組み込んで、継続的にどういう指標がどのように変化しているか、というのを見てみる。
- モブプロで癖(=コードの判断基準)の共有をする。この癖は個人の能力ではない。
- プロダクトバックログが大きすぎてしまわないか？を考えてみる。プロダクトバックログを半分捨てるといい。「いや、バックログを半分捨てたらビジネス成り立たないよ」というのはそもそもビジネスが間違っている。
- 実証実験(POC)のコードを使っているなら捨てた方がいい。問題を理解するためのコードと解決策を導き出すコードは違う。今動いているんだからいいじゃん、では危ない。
- 開発手順書を作る。どこを直す時はどういう調査をするのか？という話をその手順書に書いておく。
話も収束しかけたかな、と思ったら最後にとんでもないカミングアウトがあったりと、予想できない進行があって面白かったですww
全体を通した感想
最近はなかなか疲弊していたこともあったのか、テーマを出していない自分自身にもよく刺さる言葉が多かったです。
akiraさんの話がどちらのテーマでも、あたたかみがあって心に入ってくるような話で、印象的でした。
