RSGTの飲み会であった、アジャイルとスクラムの話をまとめておきたい。自分の中で整理をするのが目的だ。他の方の意見を否定したい意図はないことを強調しておく。
飲み会での話（と整理した自分の意見）
ある方と話していて、アジャイルやスクラムについての捉え方について自分と差異があった。
その方の意見としては「スクラムはツールだ。本当に立ち返るべきはアジャイル開発の原則だ。アジャイルを始めるときにはスクラムというツールが適していて、スクラムガイドに書いてある内容から外れても自分たちに合った方法にカスタマイズしていくのが良い」というものだった。（ニュアンス的には「べき」みたいな話ではなく「好き」ぐらいのものだったと記憶している。）
その場では上手く言えなかったけど、自分の意見としては「スクラムはツールではない。スクラムを（に）やるなら、本当に立ち返るべきはスクラムの理論であり、アジャイル開発の原則は補助的なものにすぎない。」というものだ。（これは議論の後で自分の中でまとまった。）
考え方の違いはあれど、以下は同じ気持ちだったと認識している。
チームに合ったものを採るべき
盲目的にスクラムやアジャイルを信仰しているわけではない
方法だけ取り入れても上手くいかない
結局のところ、アジャイル開発の原則を根幹とするか、スクラムの理論を根幹とするかの違いでしかないように思っていて、どちらが悪いわけでもない認識だ。
自分の意見の話
ここからは自分の意見だけになる。
アジャイル開発の原則の話
RSGTに限らず色々な方と話していて、自分はあまりアジャイル開発の原則に重きを置いていないようだ。もしもスクラムを採用しているならスクラムの理論のほうが大事だし、もしもXPを採用しているならXPの価値と原則が大事だという考え。既存の枠組みに囚われない方法を模索するときだけ、アジャイル開発の原則を頼りにするかもしれない。
これは、「スクラムはアジャイルの一部」ではなく「スクラムとアジャイルは重なっている部分がある」という考えだからかもしれない。
雑なベン図を書いたが、自分は右側の考えだ。アジャイルとスクラムは互いに含まれていない部分があるので、目指しているものがアジャイルかスクラムかは区別したい。そしてだいたいのケースでスクラムが採用されるので、スクラムの理論を重視していることが多い。
分類の話
上の文章を書いていて気づいたが、自分は結構、分類にこだわるタイプなのかもしれない。もちろん世の中には地続きで明確な境界が見えないものは多くある。抽象のレベルでは明確な分類をしないほうが良いことも多い。一方で何かしらを具体に落としたときには明確に分類をしたい気持ちが強い。分類をすることで今まで見えていなかったものが見えることが多いからだ。
何かの変化を持ち込むときも、「これはアジャイルなんだろうか？スクラムなんだろうか？」と考えることが多い。上の図の認識をしているため、それがアジャイルかスクラムかで取り組むポイントが大きく変わる可能性があると考えているからだ。もしも両方の側面を備えている場合、その変化は大きくて、分解可能な可能性があるかもしれない。「いやこれはリーンやんけ」みたいな場合、さらに違う観点が出てくるかもしれない。もちろん白黒付けられるものではなくグラデーションになっている場合が多いが、グラデーションの構成の割合を考えると、見落としポイントを見つけられることが多いかなと思う。
邪道スクラムの話
スクラムは「フレームワーク」だが、このフレームワークという言葉が非常に曖昧で、多くの人が別々の解釈をしているように思う。
自分は ryuzee さんのブログにあった「スクラムは抽象クラス」に強く影響されているので、結構ガチガチのスクラム寄りになっている。
ただ、最近はもう少し緩くてもいいんじゃないかとも思い始めている。それは、「スクラムの方法ではないが、スクラムの理論を中心に置く」というものだ。これは抽象クラスではないので、「邪道スクラム」と今さっき命名した。
例えばWIP制限を1にすればデイリースクラムはしなくてもいいかもしれない。スプリントゴール達成のための再プランニングの場も、デイリーではなくタスクを完了した際に毎回行ってもいいかもしれない。そんな感じのやつだ。
「それはスクラムか？」と言われたときに「スクラムではないかもしれません。でも、透明性・検査・適用を常にやっていて、スクラムの価値に共感し体現しているチームですよ」みたいに言えるチームは目指したい姿だなと思う。
まとめ
まとまりがなさすぎてまとめられない。