この記事は、適応型ソフトウェア開発 アドベントカレンダー 2024 の 2日目です。
スクラムフレームワークをやめた背景
もともと筆者はスクラムフレームワークを用いたアジャイル開発を行っているチームに属していたが、スクラムフレームワークをやめる判断を下す必要が生まれた。
そもそもスクラムフレームワークを利用していた背景には、アジャイルといえばスクラム！というある種の思考停止が混じっていたことが根本的な原因でもある。
しかし、今回はより具体的に何が通用しなくなったのかを解説していきたい。
通用しなくなった要素: バックログを作成できない
まずは現象として、バックログを作成できない状態に陥ったことだ。
そもそもスクラムは作るべきものに集中して取り組む必要がある。
その集中に対して優位性をもっているのがスクラムフレームワークだ。
しかし、今回筆者はこの「作るべきものに集中する」というところに行きつく、前段の部分で頓挫してしまった。
とん挫した理由
作るべきものが明確に決めづらい商材を取り扱うことになったことも大きい。
それはどんなものだったかというと、１つの機能というより、全体を包括的にまとめ上げる機能だ。
私たちが全体を考えずに、価値提供を進めることもできたが、どうしても全体の足並みを揃えながら進める必要がある難しい商材だった。
私たちがあゆみを進めようとすると、別のところで問題が発生したり、ほかのチームからの緊急度の高い要望が差し込まれたりと集中できる状況下になかった。
そんな中でも価値を提供しなければならないというつらさがあり、スクラムフレームワークの一番大切なバックログが様々な文脈単位で乱立することになっていった。
明確な完了基準を持ちにくい
このようなあちこちから差し込まれてくるタスクが、単発で完了できるものならまだよかった。
実際に差し込まれたタスクというのは、非常に文脈的なもので、背景やコンテキストを意識しなければならないハイコンテキストなタスクが多かった。
それ１つに対して、明確な完了の定義を作ること自体もとても労力がかかってしまう。
そのため、タスクを完了させるために必要なタスクがバックログへ大量に詰め込まれた。
見積もりが難しい
そんな完了の定義や見通しを立てることが困難なバックログに対して、ストーリーポイントという概念で数字を割り振り、見通しを立ててみることはやってみたが、全然あてにならない。
でもスクラムフレームワークを取り扱っているものだから、しっかりとそのプランニングには時間をかけてしまっていた。
そして、特に何の進捗もでないまま、レトロスペクティブに突入し、次の見通しもわからないままイテレーションだけは回している。
そんな状態がずっと続いていた。
いつまでも進捗が出ない。
このいつまでも進捗が出ない状況というのは、とても苦しいものだ。
自分たちの無力感がとても辛かったり、ほかのチームが輝いてみえてくる。
そんなときに、このままではいけないとやり方を改めることにした。
これがきっかけだった。
適応型ソフトウェア開発
ここでフレームワークを変えてみることで、スクラムフレームワークでは見えづらくなっていた進捗を明らかにすることができるのかもしれないと考え、別のフレームワークを試してみることにした。
今回選定したのは「適応型ソフトウェア開発」である。
結論から述べるが、私たちはスクラムフレームワークから適応型ソフトウェア開発に乗り換えることで、以下の観点において救われた。
見通しを立てやすくなった
スクラムとは別の「状態」に対する哲学を持っているこのフレームワークを用いると、見通しが立てにくい状態でもマイルストーンを適切に置き、前に進んでいる実感を持つことができるようになった。
自分たちの「状態」を把握しやすくなった
自分たちが陥っている「状態」、つまり適応地形をしっかりと把握することができるようになり、認知負荷が軽減されていくことになった。
フォーカスではなく、マルチタスクで動くことが求められる
１つに集中する形ではなく、あちこちの文脈や視点から１つの価値に向かって取り組んでいく方法が、私たちを取り巻いているカオスを乗りこなすためには有効だった。
このように、スクラムからフレームワークを乗り換えるだけでも、成果を実感できるようになることが分かった。
次の記事から本格的にASD開発について述べていく。