KPTが出てこないケース - 技術をかじる猫

カイゼン・ジャーニー読んでたら、ふと思い出したので。

Keep Problem Try の頭文字で、スプリントの最後に、「こう言う事良かったね続けようか」「こういう所問題だったよね」「なら問題解決にこう言う事やってみようか」を行うのが agile では定例。
これをチームによって期間はまちまちだけど、こちらは 2 週間に1回やった。

で、問題があったプロジェクトは、これが全く回らなかった。
どういうことかというと、problem がその場限りの問題解決になってしまったのだ。

そもそもイテレーションの運用内部「このプラクティス無駄だよね、こうしてみない？」とかそもそもプロジェクト運用に関わる問題が出てきてくれる方が望ましい。
でないと取り組みが改しないのだ。

これが 2-4 イテレーション位なら疑問にお思わないのだけど、結局最終スプリントでもそんなだった。
問題がなかった？というのは考えにくい、大なり小なり問題はあったハズだ。

何が問題だったのだろう？そう考えた

これはあったかもしれない。
そのプロジェクトは遠隔地 2 拠点での開発だった。
当然情報の粒度や格差の問題は大なり小なり出る。

何より、相手の姿が直接的に見えない。
もっと言うと気づいていないだけで、各拠点が排他的な村になっていた可能性はある。

Agile のプラクティスには大体鉄則がある。
同じ場所でやること とアジャイル・サムライにはあり、実にその通りと実感する。

そうでなくとも、そうした事を理解したキーマンを両拠点に常駐させておくべきだったのかもしれない。

元々 SIer のニアショア拠点。言われた事への作業に慣れ切ってる。
果たしてその状況で開発プロセス自体が改善できただろうか？

そりゃ温度感が違うのにプロセスを見直す発想を求めるのは酷というものだ

後からなら何とでも言えるケースだが、こうした拠点でアジャイルするなら、有識者を常駐させ、好きに言える土壌を作らなければいかなかったのかもしれない。

problem を出すときのコツは、自分がやってて詰まらないと思った作業、ド嵌りした事象だ。
ド嵌り事象は情報共有で済む場合もあれば、プロセスを変える事でそのポイントをそもそも回避できる場合がある。

何にしても言ってみる事が重要だったりする。

作業中とは面白いもので、上記のような事があっても喉元過ぎると熱さを忘れるものだ。
良くアプリが思ったように動かなくてイライラしているユーザも、どうすれば良いか分かった瞬間から問題に思わなくなる事象と一緒だ。
（いやそれユーザビリティが悪いんだからね？（汗）

SI 現場でそういうシーンは結構ある。

みたいなことが往々にしてある。
これらを解決可能だと思ってないか、過小評価して（だから改善するまでもないと思って）いるケースが多い。

どうすればわかるのだろう？
個々人が、30分以上同じ作業をしたらとりあえず紙に書いてみるという、要するに時間の使い方の見える化だろうと思う。