はじめに
- スクラムやアジャイルなどの文脈で「自社の都合に合わせてスクラムの形を変えるな」という話がちらほらある。
- この言説が伝えたいことには賛成なんだけど、これを真に受けるとそもそも導入できないやんけ！みたいなケースはあると思ってる。
- 重要なのはゴールを間違えないことで、「自社の都合」をゴールにするのではなく「スクラム」をゴールとして定義するのが大事だと思ってるよ、という話。
「自社の都合に合わせてスクラムの形を変えるな」という話
「スクラムは既存の組織文化にあわせて修正できるような手法やプロセスではない。スクラムをうまくやれるように文化を変えなければいけない。(略)スクラムはソフトウェア開発の障害となるような文化的機能不全をすべて明らかにする」(Software in 30 days)
— Ryutaro YOSHIBA (@ryuzee) December 9, 2022
これはあくまでサンプルだけどちらほら見かける。
SAFeと呼ばれる大規模アジャイルの導入研修でも同じようなことを言われた。
- 自社の都合に合わせて導入したところは失敗してる。
- 成功しているのはそのまま導入したところだけ。
自己解釈
現実問題として「形を変えずに導入」できるか？（できないと思ってる）
そのまま導入できるのが理想なんだけど、何か一つでも変えちゃダメと言われると、多くの現場では導入できなくなるのでは？（自分の観測範囲が狭いだけだったらすんません）
例えば「フィーチャーチーム」ってのが実現しにくいケースとかあるだろうし、スクラムマスターやプロダクトオーナーが本来の役割を果たせていないケースもあると思う。
たまに見かける「失敗したのであれば、それはアジャイルじゃなくて、成功したものだけがアジャイルを名乗れる」みたいな話に近い気がしてる。
現実的には多かれ少なかれ自己解釈する部分は生まれるし、まさにそのまま導入ってわけにも行かない状況は多い。
スクラムは組織課題を表面化させる
スクラムを導入するときに障壁を多数感じる場面はある。
以下記事のあたりとか。
表面化した課題をどう取り扱うかがポイント。
大事なのは「スクラム」をゴールにすること
自社のルールをゴールにして、スクラム側を改変してしまうと、何も変わらない。
目指すものを自社の都合にしてしまうと、当然自社の現場がそのままゴールになるので、状況は変わらない。
一時的に現れた組織課題も語られなくなる。
大事なのは「スクラム」をゴールにすること。
今のルール改変は一時的なものであり、その障壁として組織課題がある。
組織課題を解消させることを目指すことができれば、その一時的な改変はさほど大きな問題ではないはず。
自社都合に合わせることについて
スクラムの効果は出ない。何も変わらない。
逆に言えば、現場においてマイナスになる部分はないとも言える。
なので、個人的にはスクラムの中で取り組みやすいところから取り組んでいけば良いと思う。
だって、あれこれ言って何も取りれないなら、今と状況変わらない。
今がまずいなら何かしら変化を入れるしかない。
それがダメなら別のアプローチを試すしかない。
そうやって試行錯誤する以外に現場を打破する道はない。
まとめ
- スクラムやアジャイルは多少改変しないと導入なんてできない（と私は思っている）
- ただし改変は一時的なものとして取り扱い、あくまで「スクラム」をゴールに据え、自社都合に甘んじない。
- 取り組みやすいところから取り組んでいくアプローチでも良い。大事なのは、未来に向けて一歩でも変えていくこと。
次回予告
本記事は、2022アドベントカレンダー「受託アジャイル」です！
次回は、「今の現場におけるマネージャーとしての心理的安全性を高めるアプローチ」。