ちょっと前までチームでは、スクラムフレームワークを使ったスクラムチームを名乗っていた。
でもだんだん実態として形骸化されたスクラムだったり、ゾンビスクラムのような状態になってしまい、自分たちの自己評価が落ちてきて、元気もなくなってきてしまったため、スクラムに挫折し、スクラムチームを名乗るのをやめた。
なぜ挫折したのか
個人的な解釈ではあるのだが、スクラムはとにかく早さを意識して１つのゴールにフォーカスをして、ゴリゴリと進めていくフレームワークであると認識している。（めっちゃくちゃマサカリ飛んできそうですがね。）
このフォーカスを促進するために、スクラムを利用するケースが多いのだと思う。だが、そもそもフォーカスをするためには明確な使命が必要であると考えている。
うちのチームには、フォーカスするべき明確な価値要求が見えにくい流動的なものを相手にしていることが多かった。
その結果、どこにフォーカスをしていいのかわからなくなり、スクラムイベントが形骸化していってしまった。
Adaptive Software Developmentに出会う
そんなときに適応型ソフトウェア開発という1980年代初頭に生まれたらしい古いフレームワークの存在を知った。
現在は、この適応型ソフトウェア開発（Adaptive Software Development）通称ASD開発をチームで採用して活動を進めている。
ASD開発ではフォーカスがフレームワークの価値ではなく、創発という概念が重要になっているものだった。
その結果、以下のメリットが生まれている。
メリット
フォーカスできない状況に即していた
1つの機能領域に対して、Nの価値を追いかける姿勢が正しいものであると諭され元気になった。
PDS(Project Data Sheet) という全体俯瞰できるシートを中心に置きながら、複数のコンポーネント開発を同時多発的に行う多動的なフレームワークだった。
カオスの淵にこそ創発の価値があるというマインドがここに反映されている。
複雑なルールがない。
よりカオスな状態に適応することを目的に考案された精神的なフレームワークであるため、ゾンビだの、形骸だの悲しいことを考えなくてよくなった。
むしろ、ASD開発文脈においては、うちのチームはかなり優秀な複雑適応系だった。
複雑な行動をするためには、豊かな人間関係と簡単なルール
とにかく失敗しようぜ！ってマインドセットで、私と一緒だった。
デメリット
良くも悪くも関係値を大事にしなければ破綻する。
定量的に数字を出す方法がまだわかってない。
スクラムみたいなベロシティがない。
代わりにマイルストーンってのと、ゲートって概念があるようだ。
あんまりわかってない。
寄り道は多いフレームワーク。
振り返り
スクラムは道具だったので、固執していることが下手くそだったなと思う。
ASD開発も道具としての側面をきちんと理解して、使いこなせるようになっていかないとまた、手段に固執してしまう気がするので、きっちり挫折していく。