ScrumButしてリードタイムがクッソのびちゃう話。
ScrumButは簡単にいうとスクラムアンチパターン集みたいなものです。
上記によればこういうフォーマットをとります。
(ScrumBut: スクラムやってるよ。けど)(Reason:理由)(Workaround: 応急処置)
今回はそのScrumButの一つの話です。
スクラムやってるよ。けど...
今回の例のScrumButは下記のような事例です。
スクラムやってるよ。でも1スプリントでundoneが多くあるから、 doneにできるように開発しやすい形にタスクを分けて、1スプリントで完結できるようにしたんだ。
例えば、調査、サーバーサイドのAPI開発、フロントエンド開発、というタスク群があったとして、下記のようにしてしまう状態です。
何が起きるか?
これによって、doneはすると思います。doneするようなタスクわりにしているわけですから。 でも、これは結局APIだけリリースしてもユーザーに価値を提供しません。
むしろ、元々のやり方に比べ、途中に他の案件をしてしまったりして待ちが発生し、doneしているのにリードタイムをいたずらに伸ばしてしまっている状態になってしまっています。
なぜこうなるのか?
引力は色々あるかと思うのですが
- 何がなんでもdoneしなければならない
- 調査は見積もりをぶらしてしまうので、スプリントを分けたい
といった引力があるのかな、と思います。
派生して起きる厄介なこと
この事例にはまってしまうと、開発内部は自分たちを「予定通りに安定して開発をしているチーム」と認識するかもしれません。 しかし、ステークホルダーから見ると、これはリードタイムがただただ長くなっているだけの状態です。
こうなると、開発に何かを依頼する側は「開発してもn週間かかるから、よく練って確度上げてから開発に依頼しよう」となる引力が働きます。 しかし、開発内部がもし勘違いしていると、「俺らアジャイルなのに、ステークホルダーが全然案件を小粒で出さねーから仮説検証できねー」といった軋轢がおきかねません。
どうするのか
月並みですが、なんのためにスクラムやっているんだろう?を問い直すことからかな、と思っています。
スクラムをやっている、ということは検査、適応、透明性のサイクルが回っているということなので、スプリントを回すことによって何を明らかにしたいのか、あるいは明らかにしたことから何を考察してきたかをトレースすると良いのではないでしょうか。ここまでの例で言えば、undoneになるのが課題だったとすると、それがなぜ課題なのかを考えるとか。undoneはとにかくいけない、なので無くさねば、というのはその背後にあった目的を見失ってしまう場合があります。
その明らかにしたいものに開発のリードタイムが入っているのであれば、その観点でふりかえりしたり計測してみたりすると良いですね。場合によってはスクラムにこだわる必要もないかもしれません。 私が似たような経験をした時は、手戻りの可視化してたりしました。それは別エントリーで。
まとめ
結局は目的に忠実な点にフォーカスした検査・適応・透明化をしていきましょう。って話でした。