tl;dr

海外記事を読みます

なぜスクラムは地獄の火の中に投げ込むべきものであるか

Giles Bowkett: Why Scrum Should Basically Just Die In A Fire

先に書いておくと自分(原著者ではない)はこのエントリにまったく共感していないのだけど、最後まで読んでしまったのでスクラムアンチパターンとして記す。

  • ストーリーポイントとプランニングポーカーについて。
    • 一番目上の人が、ストーリーポイントが何ポイントになるか決めるという風になる。
    • 制限時間を設けて長々と話が続くのを止められる仕組みがあるが、対話を尊ぶアジャイル手法においてこれは皮肉。
  • スタンドアップミーティーングについて。
    • 結局長いミーティングになってしまう、しかもマネージャだけは座っていて残りのメンバーは立っているという形。
  • アジャイルマニフェストでは動くソフトウェアを進捗の最も重要な尺度とするが、ベロシティという概念によってこれが骨抜きにされる。
    • ストーリーポイントの消化具合がエンジニアの生産性を表す数字としてマネージャに利用される。
  • そのあとアジャイルマニフェスト自体への批判もあるが省略。

具体的な話とか著者の考えについては原文を参照されたい。ここまで盛大にまずいスクラムというのもなかなかないのではないかと笑ってしまうけれど、真面目に考えてみると何がスクラムでないか、というところが見えてくると思う。手法それ単体はスクラムではなく、スクラムはマネージャが開発者を使ったり評価したりするものではない。スクラムはチーム全体で自発的に進めていくもので、それができていないのならスクラムマスター(元のエントリには scrum master という単語は一度も登場しない)の失敗だろう。そしてスクラムそれ自体を行うことを目的とせず、スクラムの一貫として定義されている手法のそれぞれを手段として吟味し、チームにあわせてカスタマイズしながら採用し、チームの仕事の達成につなげるというのが本来の目的のはずだ。Wikipediaスクラムの方法を読んでわかった気になる、などとしているとこういう失敗が起きそうに思う。チームで本を読むか、スクラムマスターがしっかりと解説することから始めていれば、こんなことにはならないのではないだろうか。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK