今いるチームの開発フローは、しばらく「Asanaのステータスを隔週で更新して状況を教えてください」くらいのゆるいものだったのを、開発のサイクルやリズムを作りたい、ということで、スクラムに寄せていこうとしている。
ただ、小さな1チームが独立して集中できるというよりは、既存のチームをだんだんスクラムにあてはめようとしている、という形で、教科書通りのプロセスがいきなり始まって大成功、とはなっていない。
複数チームが存在する場合にどうしたらいいか知りたくて、本を読んでみた。
今のチームの特徴
- すでに存在するチームである
- チーム、チーム内チームであるユニット、チーム内チーム内チームである村…のように、階層構造のチームになっている
- 村のメタファーが気に入りすぎていて、村長（村の長）、村役場（スプリントプランニングなどをする会）、村八分（村で行動しているのに、タスクの配分がうまくいかず、一人で仕事を抱え込んでしまった状態のこと）、などの概念が誕生している
- アプリ担当、インフラ基盤担当、のような、連携が必要な隣のチームという概念が存在する
スクラムイベントだけでないイベントがいろいろできていたり、用語なども既存用語とスクラム用語の対応を取ろうとして独自解釈な用語になっている。
その様子を、「これは真のスクラムではなくて、なんちゃってスクラムですよね」と言われて、それはそうですが…アジリティを手に入れたいという目標は同じで…とか言い訳をしている。
独自に無理しているのか、世間の知見を再発明しようとしているのか知っておこう、スクラムを拡張した概念も知っておこう、と思って、読んでみた。
この本は、Scrum@Scale、という、複数チームのスクラムをうまく連携させるための手法を紹介してくれる本。
本を読んでみて、良いな、と思ったのは、式次第の設計。待ち時間が発生しないように順番に、立て続けに会が設定されている。
今の我々のチームだと、村の朝会、昼にユニットの会、夕方に村の相談会、というような感じで、わりと無計画に発達してきているし、スクラム開始前から続いている会議体が残っていて、目的感が希薄になっているような会もある。
Scrum@Scaleを直接我々も取り入れるぞ、となるのはまだ先で、現状のスクラムをうまく回すことに集中することになりそうではあるけど、我々のやってるこの会議は、Scrum@Scaleではどの会議に対応しますか？という観点で見直して、誰が集まってどういう情報を渡していったらスムーズか、という観点で、見直していけるとよさそう。
15分のデイリースクラム、その後にデイリースクラムで解消できなかった課題を持ち込む会、そして続けてさらに上位の会…とリズムよくやっていけると、情報がうまく渡されている…スクラムっぽい！となりそうだけど、皆の勤怠を合わせる必要があり、フレックスな働きとは相性が悪い気がする。
この時間だけは絶対に来てね、というコアタイムを設定しましょう、が答えになりそうだけど、みんなが来ているような良い時間帯はすでに社内外の他の会議に占有されていたりして、チーム開発の予定が第一になれない、という実態もある。いろんなすでに設定されている会をよけて開発やスクラムイベントを設定していると肩身が狭い。ここですべての会の予定を調整できる権限を持った人がいる会に、自然と参加できれば、スムーズなのだろうと思う。
たとえば、全社的にスクラムサイクルは火曜日開始を推奨として、それにあわせて、そのあたりに入っている会議をずらしていってくれる、とか。
