スクラムよ！私は帰ってきたぞ！スクラムをやめたけど戻したチームの経験談

こんにちは。アニメ『日本三国』を見終わって、横山光輝さんの『三国志』を読んだときの興奮を思い出した daipresents です。天命をまっとうするぞー。

少し前に、Slackを眺めていると、エンジニアリングマネージャ友達のなかしょーさんが「スクラムをぶっ壊す」とフンフンされていたのをみつけて、そう思った理由を伺ってみるとなかなか面白かったので、今日はその話を書いてみたいと思います。

スクラムじゃないかもと思った理由

なかしょーさんチームでは、スクラムが導入されていました。社内でも古株プロダクトでもあることから、比較的スクラムを長く続けていたチームです。

そんなチームは、スプリントを1週間でまわしていました。しかし、だんだん変化への対応タイミングが増えてきて、週単位での対応が必要になってきたそうです。

結果的に、立てたゴールが変化でくずれてしまい、なんとかならんものかなぁ。と改善を考えるきっかけになりました。

さらに、開発の状況にも変化がありました。AIです。

AIの登場によって、コーディング時間が減ってきました。その代わりに、設計に時間を使うことが多くなってきました。

「何を作るべきか」の重要性は変わらないのですが、AIの登場によって文字通り「どんどん作れる」ようになりました。計画に時間をかけるより、はやくリリースして、はやくフィードバックをもらうほうがアジリティが高くなるのではないか？と、チームの考えが変わってきました。

結果的に、計画よりも、優先順位が重要になったのです。

チームは、スクラムのやり方を見直すために、いろんなことを「止めて」みました。

かんばんボードやかんばんプロセスについては、前日に書いた「流れを自由自在に操りアジリティを高める「かんばん」方法論」を参考にどうぞ。

スクラムをやめた後、変化に対応しながら進んでいった結果、現在は以下のようになっています。これは「現在」の状況でしかなく、どんどん変わっていく可能性があります。

まず、かんばんボードは、単純なタスクとその状態管理でまだ使い続けています。

計画づくりは復活しました。1週間スプリントを3日と2日にわけ、短いスプリントで変化に対応するようになりました。

デメリットとしては、スプリントの回数が増えるので、スクラムイベントの時間が少し伸びたそうです。でも、「計画がころころ変わってバタバタするよりまし」という感覚だそうです。

スプリントが復活したので、スプリントゴールも復活しました。これにはいくつかの理由がありました。

スプリントゴールは、そのスプリントの評価指標になりえるものなので、端的に言うと「うまくいった」、「うまくいかなかった」を判断する材料として使えます。

かんばんでもゴール設定は重要ですが、方法論として扱っていないので別の仕組みが必要になります。結果的に、使い慣れたゴールを扱う「スクラム」にもどったということなのだとおもいます。

完璧な開発プロセスというものは存在しないので、世の中のほとんどのチームが、上記のチームのようにいろいろ試行錯誤しながら、開発プロセスの改善を続けていると思います。

今回の事例では、方法論自体を大きく変えた事例となり、2つの方法論を比べることで、その良さや違いを体験できたのが、チームとしての大きな学びなのかもしれません。