ScrumButしてリードタイムがクッソのびちゃう話。
ScrumButは簡単にいうとスクラムアンチパターン集みたいなものです。
上記によればこういうフォーマットをとります。
(ScrumBut: スクラムやってるよ。けど)(Reason:理由)(Workaround: 応急処置)
今回はそのScrumButの一つの話です。
スクラムやってるよ。けど...
今回の例のScrumButは下記のような事例です。
スクラムやってるよ。でも1スプリントでundoneが多くあるから、 doneにできるように開発しやすい形にタスクを分けて、1スプリントで完結できるようにしたんだ。
例えば、調査、サーバーサイドのAPI開発、フロントエンド開発、というタスク群があったとして、下記のようにしてしまう状態です。
何が起きるか?
これによって、doneはすると思います。doneするようなタスクわりにしているわけですから。 でも、これは結局APIだけリリースしてもユーザーに価値を提供しません。
むしろ、元々のやり方に比べ、途中に他の案件をしてしまったりして待ちが発生し、doneしているのにリードタイムをいたずらに伸ばしてしまっている状態になってしまっています。
なぜこうなるのか?
引力は色々あるかと思うのですが
- 何がなんでもdoneしなければならない
- 調査は見積もりをぶらしてしまうので、スプリントを分けたい
といった引力があるのかな、と思います。
派生して起きる厄介なこと
この事例にはまってしまうと、開発内部は自分たちを「予定通りに安定して開発をしているチーム」と認識するかもしれません。 しかし、ステークホルダーから見ると、これはリードタイムがただただ長くなっているだけの状態です。
こうなると、開発に何かを依頼する側は「開発してもn週間かかるから、よく練って確度上げてから開発に依頼しよう」となる引力が働きます。 しかし、開発内部がもし勘違いしていると、「俺らアジャイルなのに、ステークホルダーが全然案件を小粒で出さねーから仮説検証できねー」といった軋轢がおきかねません。
どうするのか
月並みですが、なんのためにスクラムやっているんだろう?を問い直すことからかな、と思っています。
スクラムをやっている、ということは検査、適応、透明性のサイクルが回っているということなので、スプリントを回すことによって何を明らかにしたいのか、あるいは明らかにしたことから何を考察してきたかをトレースすると良いのではないでしょうか。ここまでの例で言えば、undoneになるのが課題だったとすると、それがなぜ課題なのかを考えるとか。undoneはとにかくいけない、なので無くさねば、というのはその背後にあった目的を見失ってしまう場合があります。
その明らかにしたいものに開発のリードタイムが入っているのであれば、その観点でふりかえりしたり計測してみたりすると良いですね。場合によってはスクラムにこだわる必要もないかもしれません。 私が似たような経験をした時は、手戻りの可視化してたりしました。それは別エントリーで。
まとめ
結局は目的に忠実な点にフォーカスした検査・適応・透明化をしていきましょう。って話でした。
JJUG CCC Fall 2017でしゃべってきた。
というわけで@shimashima35さんとSelenideとGebの話をしゃべってきました。
当日のスライド
思い
今まで登壇するときは、Geb推しでGebの良さを語ることが多かったです。その場合もコンテクスト大事、というのは気をつけて発表していたつもりだったのですが、最近自分の周りで必ずしも幸せなツールチョイスをしていない場合があるかも、というのを気にしていました。
というわけで、今回はそういうツール選びで悩んでいる人に寄り添える形のセッションにしようと考えました。
結果、特定のツールを強く推すの色を薄めにして、 @shimashima35さんとタッグを組んだ対話型にすることで、複数のツールのスイートスポットがどんなところにあるのか、というのを細かいコンテクスト含め明らかにするのを目指したセッションにしました。
それがどういう結果になったのかはわかりませんので、参加してくださった方はぜひアンケートでフィードバックいただければと思います。
最後に
JJUG CCCでの登壇は2度目でしたが、しゃべることでむしろ元気をもらえる良いイベントだと思います。
参加してくださったみなさん、スタッフのみなさん、ありがとうございました。
Scrumは、おバカさんでも、うまくいく
私はScrum好きです。でもなぜScrumなぜ好きなの?っていうとタイトルの通りです。
どういうことか。
まずはこれを見てみてください。Scrum生みの親 Ken Schwaberのプレゼンテーションです。 最初は認定スクラムマスター研修でみた気がするのですが、以来時々みています。 13分33秒くらいからが好きなところ。
14:22くらいからを特に話題にしたいので、雑に日本語にします。
スクラムはおバカさんともうまくいきます。 おバカさんを集めグループを作ったとしましょう。 コンピュータサイエンスやソフトウェアエンジニアリングの技術を学んだことはないでしょう。 お互いを嫌っていて、ビジネスドメインを理解せずツールも使い慣れない。 そうすれば毎インクリメントで「ゴミ」ができます!(会場笑い)
こんな感じ。でもこの後がとても興味深いです。
これは良いことです! あなたは毎スプリントの終わりに、自分たちがどこにいるのかを知りたかったはず。 (中略) 透明性です。つまり全ての人が、今どこにいるのかをいつも知っている、という状態です。
そっか。これが透明性の確保ということなのか、というのが最初にみたときの感想でした。 最終的には価値を出すのにコミットするためですが、そのための方法として検査、適応、透明性を確保する。この無理のない感じが好きです。 以来、これがScrumを導入しようとするときの私の一番のモチベーションになっています。
おまけ:心理的安全性の確保
透明性を実現しようとすると、とっても大きなマインドチェンジが必要になると経験上思っています。 それは、「うまくいかなかったことでも積極的に明らかにしていく」ということです。
誰だって失敗談をせっせと話すのとか、うまくいかなかったこと、苦しかったことを共有するのは心理的にも辛いと思うんです。
でも、それをすることでチームの現在地がわかる、なので安心して共有していきましょ! という空気作りするのがとても大事ですし、導入時はそこに気を遣っています。今だと心理的安全性の確保とも言えるかもしれません。
透明化して安心して改善していける強いチーム作っていきましょう。