フレキシブルなチームを目指す場合に、最も必要なのは、チームを停滞させないこと。
世にあるなんちゃら開発の殆どは、この状況を未然に防ぐため、予防的なプラクティスを提案する。
ぶっちゃけ、停滞しないチームは進み続けるので、後は仕事量の問題です。と、だいたいごまかされるのが本のお決まり。
停滞の原因はいくつかある。ぱっと思いつくのは
萎縮。
プロジェクトメンバーが萎縮してる状態で、個々への責任が超えてる状態。
これはミスや失敗が発生した場合に、本人が責任を追っている思い込みすぎているか。か、過度に個人の責任に追わせている。
比較的、分かりやすいのが特徴だが、責任の塩梅という対処の難しさから放置されやすい。
無関心。見抜くのが難しい。
一見チームは滞りなく進んでいるように見えて穏やかに死に向かってる場合が多い。
外部刺激によって改善されるいことが多いが、これも力の塩梅によっては反発やさらなる無関心を呼ぶ
予防的なプラクティスと書いたが、それと同時に改善にも効果的なモノが多い。
朝会は、単なる進捗共有会だと利用されてしまうことが多いが
チームの信頼関係が弱い場合、そのリズムを共有することで信頼関係を築く。
さらに、個々のメンバーのリズムがおかしい場合、それをリセットする場にもなる。
とまあ、ここまで書いて、後は、朝会を実行するためのチームがあれば検証できそうですが どこかに良いチームってありますかね。
朝会は辛いので夕会ぐらいをダラダラとやってるチームで、 その割に各個人の目的意識がそれなりにあって、なんだかんだ上手く行くチームで仕事したいっていんだが、俺ぐらいしかい...
中間層って下を見て安心してるだけで実際は適当にやって上手く回せるほど有能なわけではない人がほとんどだから どちらかに寄るしかないと思うよ