私の働く会社ではプロダクト2つ持っており、それぞれでチームが独立しています。
数ヶ月ほど前、私のチームでは私がスクラムマスターとなり、本格的なスクラム開発の導入を推進することになりました。 当時、会社にはほとんどスクラム経験者がいませんでしたが、ちょうどその頃、元トヨタでスクラム開発の経験者がもう一つのチームにジョインしました。その方と連携しながら知識をインプットし、なんとか本格的にスクラムを導入して約1ヶ月が経過。
スクラムの体系的なインプットは『スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) 』をチームの教科書とし、週一の輪読会を行いながら全員で理解を深めました。
スクラムに関する知識が網羅的にインプットできるのはもちろん、他社の導入事例が紹介されていたのが印象的でした。
事例として紹介されていたのは、GMOペパボ・mixi・DeNAという有名テック企業たち。今ではテック企業としての確固たるポジションを確立している彼らも、スクラム導入においてはちゃんと失敗していたことを知れました。
「スクラム素人の自分たちだって失敗して当然だ」と、ある意味開き直ることができました。
読了。全体の1/3のページ数を割いていた「スクラムにおいてのありがちな失敗例」は、とても有益で実用的。GMOペパボ・mixi・DeNA社の導入事例で最初はちゃんと失敗しているのを見て、自分達だって失敗して当然なんだといい意味で開き直れた。これはチームの教科書にしていきたいな。 https://t.co/XxlDQ0krjA
— Shimpei Wakida 🛠 Engeneering Manager (@kiwatchi1991) 2022年8月28日
失敗事例を見ると、その失敗の根底にある課題は
あたりに集約されそうだと思いました。
スクラム導入初期は、必ず困難にぶち当たります。うまくいってる実感を感じられない瞬間もあるはずです。そもそもスクラムは、課題をあぶり出すフレームワークでもあるので、当然です。そんな時に、スクラム導入の目的・スクラム導入によって得られるメリットを正しく理解できていないチームであれば、「やっぱりうまくいかないからスクラムやめよう」という思考になってしまいます。
事例では、上記のような理由で一度失敗したあと、チームメンバーでスクラム勉強会を実施し、スクラムマスターだけでなくメンバー全員がスクラムに関する解像度を高める活動をすることで、状況の改善を図っていました。
「成功はアート、失敗はサイエンス（成功に再現性はないが、失敗には再現性がある）」などと言いますが、同じ失敗を繰り返さないよう私のチームではスクラムに関する知識のインプットをしっかり行ってから実際の開発をスタートさせました。
おかげさまで、スクラム開始から2ヶ月ほど経過しましたが、全員がスクラムの価値や原則をある理解できているので、課題を前向きに捉え、改善を繰り返しながら少しずつ良い形になってきています。
スクラムをやって実際に感じているメリットについても、別記事でまとめようと思います。
