１５ポイントルール

最近チームが改組されました。

メンバーも入れ替わりました。

さて、私はイテレーションの最後に、常にふりかえりを行っています。

目的はいくつかあります。

・成功を再現するため

・失敗を再現しないため。

・開発を改善するため(スクラムにおける適応)

・われわれのプロダクトやリリースが市場にどのような変化を与えたかをフィードバックするため(スクラムにおける検査)

・チームで持つべき情報が何かを判断するため(スクラムにおける透明性)

ところが新しいチームのメンバーはこの行為に意義を見出しづらい人が多かったように思います。

「なぜそんなことをしないといけないんです？」

「いまでもプロダクトは十分成功しているでしょう？」

「今までのやり方でいいじゃないですか。なぜ不要な苦労をしてまで新しいことをしないといけないんです？」

振り返りの意義をメンバーに浸透させたいと思いました。

そこでふりかえりに１５ポイントルールというものを追加しました。

チームのヴェロシティが現在２００ポイント弱程度あります。

「もし、新たに１５ポイント使えるとすれば、何に使うか」

 を各人が３分で発表します。

プロダクトバックログアイテムの特定のアイテムの消化に当ててもよいですし、CIシステムの改善をしてもよいです。ベータテストやその評価をする提案もありです。

 最初は、振り返りによって開発が改善されれば１５ポイントが仮定ではなく実際に使える、という点を意識させることで振り返りの意義を定着させる目的で始めました。

たしかに振り返りの意義は定着しました。

しかし運用してみると、異なる効果も得られました。

[メンバーのマネージメント力が分かる、上がる]

自分一人で情報を取得し、次はどれをやるか？を判断する訓練を行う必要があります。そこで以下の成果が得られました。

「メンバーの全体の見わたし力が分かるので、各人のマネージメント力の成熟度合いがわかる。」

「メンバーのマネージメント力が上がるので私のチームのマネージメント負荷が大きく提言された。」

[メンバーの興味関心の方向がわかる]

メンバーが提案するのは自分が興味あるトピックであるケースが多いです。なので、提案した人間にそのカテゴリのタスクのエキスパートと判断できます。突発タスクでも、誰に任せるべきか、という判断で迷いません。

メンバーの提案が一方向に集中している場合は、より優先すべきタスクがほかのものによってブロックされているケースが多いです。バックログの見直しが必要な兆候です。

メンバーの提案が二方向に分かれている場合は、どちらを優先すべきかをプロダクトマネージャーが決断すべき兆候です。

メンバーの提案が四分五裂に見える場合は、プロダクトの検査や適応、あるいはビジョンがメンバーに浸透しておらず「何をすべきか」がメンバーに明示されていない状態です。あらためてプロダクトマネージャーとメンバーが同期すべき兆候です。

 メンバーのモチベーションとスキルが上がるとプロダクトマネージャーの負荷を上げずともヴェロシティは上を向きます。

１５ポイントルールはチームのメンテナンスプラクティスの１つとして現在有効に機能しています。