最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。
- 小さく導入する
- 短く導入する
- 振り返る
小さく導入する
なんか導入する時は出来るだけ小さく導入してる。
理由は
- いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する
- いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける
みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。
小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。
小さく導入する方法はいくつかあって
- スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする
- チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さくする
などといったことが考えられる。
例えば、
- ホワイトボードやプラニングポーカー、バーンアップチャートなどの仕組みを、新しく始まった新機能プロジェクトにのみ適応する
- その中でうまくいったホワイトボードの仕組みだけ、全体に適応する
とかそういう感じでやってたりする。
短く導入する
導入する時はなるべくまずはこの期間導入するっていうのを決めてやってる。例えば一週間とか。
理由は
- 期限を決めずに導入すると、なんとなくで続けられてしまうので、それを防ぐため
- 区切りを付けることで、自分の中で振り返る機会を決めておく
などがある。
大体、これまでのやり方は良くなかったのでやり方を変えます！と意気込んだやつは、ある部分は良くなるけどある部分は悪くなる。ただ、期限や区切りを決めてないと、大体そのままなあなあに運用され、全員があんま良くないのにと思ってても、なぜかそのまま続いてしまうことが多い。なので、期限や区切りは自分の中で決めるか、みんなに共有する。
これもやりかたはいろいろあって
- 今月はこのやり方でやろうと決める -> 時間で区切る
- このプロジェクトではこのやり方でやろうと決める -> 終りがあるプロジェクトで区切る
などがある。
振り返る
小さく導入すると、変数が少ないので何が良くて何が悪かったかが分かりやすい。短く導入すると、それを振り返るきっかけが出来る。それで、最低でも自分の中で、可能ならチームを巻き込んで振り返りの機会を作っている。
最近はチームを巻き込むんだったらKPTでやるのがやりやすいなと思ってて、関係する人たちを集めて(出来るだけ少人数で)、
- Keep 今後も続ける
- Problem 問題だったこと
- Try 次からやること
を出し合って議論したりする。
やり方は結構柔軟にやってて、例えば、事前に考えてきてもらって議論するとか。けど最近はもうちょっとゆるく、何も準備なしで来てもらって、10分くらい付箋にいろいろ書いていってもらって、ホワイトボードに貼ったりしながら議論するという方が楽だし、議論も進みやすかったりするなーと思ってそうしてる。
まとめ
なんとなく思ったこと書いた。
チームの文化に合う、チームがやりやすい、というようなやり方はかなりそれぞれだと思ってて、大抵の場合全体的におすすめされているやり方をそのまま導入するとあまりうまくいかないと思ってる。なので、導入する時は合わなかったらすぐやめられるように小さく短く導入したり、何が良かったか振り返って次に活かす、みたいなことが大事だなと思う。
それでなんかミスったら、ごめんなんかうまく行かなかったって謝って一回仕組みをなくしたらいい。文化にあう仕組みみたいなの結構難しいし、それは仕方ない。自分のミスを認めずにそのままなあなあで導入しておくというのは一番良くないと思う。
このへんの話、もうちょっと本とか読んで知りたいとか思ってるけど、あまりいい本が見つけられずにいるので、おすすめの本あったら教えて下さい。
ちなみに文化大切にしたいというのはチームギークとかの影響です。
