スクラムガイドの更新のまとめを読んで思い出したこと

 後から出てくるものは過去の埋もれて誰もが忘れていた手法やアセットにもう一度スポットライトを当てたり、忘却の彼方に追いやってしまった当時はその意味に気づかなかった仕組みを思い出させてくれることがあるのです。

スクラムガイドの更新

次のようにスクラムガイドが更新されたとのことで、変更点をまとめていただいているので感謝しつつ見させていただいた。

2017年11月7日(現地時間)にスクラムのルールブックであるスクラムガイドが更新されましたので、Webinarの資料をもとに変更点をご紹介します。

www.ryuzee.com

引用先の冒頭でも気になる点として取り上げられているのですが、 気になったのは↓これです。

レトロスペクティブ（ふりかえり）で出た項目を、次のスプリントのスプリントバックログに含めること

 どうして気になったのか

 ですけれど。これを読んで思い出したことがありまして。

このふりかえりで出た項目を次のスプリントのバックログに入れなさい、ということは、今回実施した作業工程で学んだことの中からtryをactionに繋げることを確実にするために入れておきなさいね、ということなのだと思ったのです。

これはさらに連想が2つのことに繋がりまして。

tryをやるかはクリティカルか否か

色々とエンジニアと話していると、ふりかえりを導入しているチームは増えています。これはいい傾向だと思っていますが、一方、当事者のチームが自ら気づきを得られるという観点から様子見とした方が良さそうなので経過観察しようと思っていますが、tryに出たことをどこまでチームが拾うかと言えば、実態は、クリティカルなtryしか拾わない、拾えないという状況が見受けられるのです。

まあ、tryにあげたら全部やらないといけないかと言えば、これまでは運用的にも次の工程で当初から予定しているテーマがあるのでそこにtryをどこまで入れるのかというシーソーゲームをするときにやはり、当初のテーマが優先されると、いわゆる負債が積み上がっていくので悩ましいところです。解は、tryの中で落ち葉拾い的なものも一定量やるだけの道幅を持っておきなさい、なのですが。

次のバックログに入れるということ

 もう一つは、この工程で得られた知見を次の工程に再投入しなさい、という考え方です。

これを読んで、思い出したのは、2000年頃のプロジェクトの品質管理の工程内レビューのポリシです。どんな内容だったかというと、

• 工程内レビューを行いなさい
• 品質分析をして、工程内で改善しなさい

というものです。つまり、今週レビューをしたら、その場で品質状況を分析して、次週の作業工程に反映しなさい、という考え方です。

まあ、1週間かどうかはレビュー計画によるのですが、最後にまとめてレビューをするようなことは作業量の平準化からそんなことはせず、順次レビューに投入する計画を建てるとき、工程内で品質不良の傾向をみて、残りのアウトプットを作るときに品質の確保を計るようにしておきなさい、と。

言わば、親心のようなものですね。

それを思い出したんですね。実際の現場でそれができていたかどうか、出来ていれば以降のプロジェクトに採用され、広がったはずだろうと穿った物の見方はできるけれどそれはあまり意味がないような気もするので。

ただ、そういった標準の仕組みの意図を理解して、実利があることを認めて理解者を増やすのは気づいた人だけというところがアレな訳ですが。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き