最近、
状態と
対策と
この
記事の
記事を
読む前から、 偶然にも 同じ プラクティスは 実施していた
記事を発見したのは、 実際に チームビルディングの カリキュラムを 実施したあとでしたが、 偶然にも 同じような プラクティスは 実施していて 方向性と しては 間違ってなさそうで 安心しました。 RACIチャートは
PMBOKで 紹介されていた
アジャイル｜スクラムの対義語に もなっていそうなPMBOKですが、 RACIは 確かPMBOKの 第6版あたりで 紹介されていた 気が していて、 ウォーターフォールでも アジャイル｜スクラムでもどちらでも 使える プラクティスだなと 思いました。 また、 チーム内に 限れば、 デリゲーションポーカーでも RACIチャートの 役割は 満たせそうです。
職能別の役割分担を 記載できるのが、 RACIチャートの メリットで、 スクラムチーム外の 人の 役割も 書いても 良さそうに 思いました。 （実際に 書いて 役割を 定義するのが 正しそう） シェアードバリュー
ワーキングアグリーメントを作っていると、 この シェアードバリューに あたる ものが 出現する ことがあり、 これを 個人的には 行動規範と呼んでいました。
この記事上で、 ラベリングされていて 腹落ちしたので、 この 言葉を 今後利用していこうと 思いました。
記事の
今まさに
まず、
プラクティスは
サーバント・リーダーシップの
不足
EM自体が、アジャイル｜スクラムの 経験が 少なく、 自己管理型チームではなく、 従来型の 強い リーダシップを 発揮している 可能性が あります。
EM自体もリーダーシップの 学び直しが 必要に なりそうです。 失敗を
恐れている
現状のチームメンバーを 見ていると、 極度に<wbr>失敗を<wbr>恐れているように見えています。
複雑系の問題であれば 失敗は 恐れる 必要が ない 気が しており、 失敗を<wbr>恐れて<wbr>検討する<wbr>時間を<wbr>とるだけ<wbr>無駄で実際に 検証して フィードバックを 得る ことを 優先した 方が いい 問題も 多く ありそうに 思っています。
失敗をとらえ 直すと いう 文脈で 以下の 記事が 参考に なりそうに 思いましたので、 リンクを 貼って おきます。
｢失敗｣を｢早期フィードバック｣と 捉え直すべき 訳 ナラティブに 未来を 紡ぎ出す 創造的失敗の 知恵 | 企業経営･会計･制度 | 東洋経済オンライン ワーキングアグリーメントに
本当に 必要な 項目を 抽出できていない
個別にヒアリングを していると、 今話した<wbr>トピックこそ、<wbr>ワーキングアグリーメントに<wbr>すべきことでは<wbr>？という トピックが 上がる ことが あります。 チームメンバー自身が、 自己管理型チームに なる ために 必要な ワーキングアグリーメント項目を 認識できていないのかも 知れません。 コミュニケーションの
不足
チーム結成から1月程度です。まだ、 チームメンバー間の コミュニケーションが 単純に 不足しているようにも 思います。 インセンティブの
設計や ルールの 認識合わせが 不足している
チームメンバーの中には 損得の 意識が 強めの 人間と、 そうでもない 人間が 混ざっているように 感じます。
会社、チームと してどのような 行動を 望んでいるのか ？インセンティブの 設計に ついてどこまで 制度化するのか ？
などを擦り合わせる 必要が あると 感じています。 ソフトウェアプロセス技術を
知らないことが 自己管理型への 変化を 阻害していそう
ソフトウェアプロセス技術がロストテクノロジーに なっている - きしだの Hatena が 2015年の 記事でもう 完全に ロストテクノロジーに なっているのかもしれません。
ルールやプロセスを 定義した 方が 良い 場面で、 それらを 定義する ことに 考えが いかないと、 自己管理型チームへの 変化が 阻害されそうです。
コメント