上の記事読んだらいいこと書いてあって同感！という感じだった。
最近社内向けにも記事を書いてたのですが、以下の三つを目的として自分のチームにスクラムを導入しました。
- ベロシティを計測しつつ、仕事を安定させられるようにする
- 長期タスクのリリース予測をしやすくする
- 開発者の幸福度をあげる/高い状態を維持する
現状ではまだうちのチームは仕事を安定させることが優先なのでこうしていますが、全ての仕事が安定的で最高な状態になったら次のゴールはベロシティをあげるのは納得します。
ただし上に書いてあるように、「開発者の幸福度」を維持することも大事な観点の一つなので、幸福度が下がるような形でベロシティをあげることを目標とするのは長続きせずよくない。具体的には、「次スプリントは今スプリントより高いベロシティ、+10pt載せましょう」と根拠なく増やし続けるとか、残業して終わらせようとか。スクラムでは「障害物を取り除く」がキーワードな気がしていて、メンバーの足をひっぱるマイナス要素を取り除いてあげたり、メンバーのモチベーションがあがるようなことをしてあげたりすると間接的にベロシティがあがりそう。開発者が「リファクタリングしたい」とか「ここは自動化したい」とか言ってたらそういう発言は尊重してはやめにやらせてあげると後のベロシティはさらにあがって嬉しいとかもありそう。
