気付いたら冷房をつけっぱなしの季節になっていて、真夏が来ることに毎日震えています。
真夏なんてウルトラマンくらいの時間分しか外に出れなさそう...
自分はSMARTCAMPでエンジニアとしてBOXILというプロダクトを開発しています。
主にバックエンドに興味がありTDDやらモブプロやらを積極的に使っています。
ですがスクラムにも興味があり、スクラムについての勉強会や書籍を読んだりしています。
そんな中でタイトルにもある通り、スクラムをどうチームに導入するかについて最近考えがまとまってきたのでアウトプットさせてください!!
結論
社会人なので先に結論を述べると適切なタイミングで適切なスクラムの文脈を含んだ施策を動かすです。
背景
BOXILでもスクラムを導入していたり、新しいチームでもアジャイルにやっていこう!!という雰囲気が漂っていて、自分は開発メンバーをしながら自分が学んだスクラムの知識などをチームに共有したりしています。
新しいチームでは明確にスクラムは組んでおらず、 できるだけ早く開発しているものをリリースすること 目的として動いています。
スクラムの導入
自分は効率的に開発することも大事だと思いますが、早く失敗することも早くリリースするためにかなり大事だと思っており、そのためにはスクラムというフレームワークはかなり良い手法だと思っています。
失敗 : とりあえずスクラムをする
自分 : スクラムのフレームワークを全部入れよう!!
チームメンバー : スクラム分からんけど会議多いな...
上司 : スクラムはあくまで手法で、チームに合った形に進化させたいな...
自分はスクラムを導入する際には守・破・離の順で自分たちの形にあったスクラムにしていくべきだと思っています。
そのため、守のために一気にスクラムのイベントやスプリントの概念を入れようとしていました。
これはアジャイルの思想とは違うということに気付けたのは本当に環境(上司や同僚)のおかげだと思います。
スクラムをしたい理由はアジャイルに開発したいからで、そのスクラムをアジャイル的に徐々に導入しないなんて本末転倒だなと振り返って思います。
「カイゼン・ジャーニー」や「正しいものを正しくつくる」などの著者である市谷さんも「Become」なアジャイルというNoteを投稿されていました。
得た学び
冒頭の結論にも書いた通り、適切なタイミングで適切なスクラムの文脈を含んだ施策を動かすと徐々にスクラムに近づいて行くのかなと思います。
ただでさえ不確実性を持ったプロダクト開発をしているので、開発プロセスではせめて確実性をできるだけ持っておきたいです。
そのため、チームのやり方を踏襲しつつ問題が顕在化したタイミングでスクラムの文脈を含んだ施策を動かすのが良いのではないかと思います。
ただ、自分たちのチームが守・破・離のどの地点にいるかを俯瞰的に把握しておく、ということは心がけたいなと思います。
まとめ
今回はここ1年ほど悩み、最近気がついたことを雑多にまとめました。
スクラムに魅了された一人としては、早くリリースするためにはスクラムが良いフレームワークだと考え、一気にチームにスクラムを導入したい気持ちは山々ですが、守・破・離を意識しつつ適切なタイミングで徐々にスクラムにしていくのが良いのかなと思います。
これはあくまで執筆当時の考えであり一年後には「一気にスクラムをいれる方がいい!!」や「スクラムよりももっといいフレームワークがあった!!」となっているかもなので、ご容赦くださいw
Discussion