チームはそれぞれのケイデンスを持つべきか？

先日のTwitter上で、作業計画用と学習および改善用、というように、チームが複数のケイデンス(cadence)を持つことの是非に関する議論があった。ケイデンスを分離することで、最適なケイデンスを検討する余地がチームに与えられる。適応性と自立性が向上し、よりよい成果を得られる可能性がある、というのだ。

きっかけはMatt Barcomb氏のツィートだった。

Barcomb: Protip: 十分に検討されたMVPと優先順位の決定方法があれば、スプリントを計画する必要は(あるいは、当然、スプリント目標を持つ必要も)ありません。

Ron Jeffries氏がこのツイートを引用して、次のように付け加えた。

Jeffries: 予測可能性の向上やサイクルタイムの短縮、コミュニケーション改善を望まないのであれば(それでもよいのですが) ... ケイデンスとある程度の計画はあった方がいいでしょう ...

その後のTwitterでの議論で、Barcomb氏が計画と改善のケイデンスの分離を認めたのに対して、Jeffries氏がその理由について疑問を呈した。

Barcomb: もちろん。 私は常々、計画と改善それぞれのケイデンスを持つことを勧めていますし、それらを分離するように提案しています。

Jeffries: なぜ分離するのですか？定期的に計画を立案して、何が行われたかを一緒に見直す方がすっきりしませんか？

Barcomb: 私が不満だったのは、かつては別々のケイデンスが必要だったものが、スクラムではないという理由で許されなくなったように思われる(あるいはそう言われた)ことです。

Jeffries: なぜ別々のケイデンスが“必要”なのですか？スプリントのサイクルよりも遅いからですか？なぜでしょう？

続いてJohn Cutler氏が議論に加わり、複数のリズムが必要な理由をいくつか挙げた。

Cutler: 顧客のフィードバックループ
“デリバリ”ループ
統合ループ
分解作業
レトロスペクティブ・ループ
ゴール設定ループ

これらすべてをひとつの固定されたケイデンスで行なうことは有効かも知れませんが、そうでない場合も少なくありません。ジャストインタイムのものもあれば、もっと長いものも、短いものもあるのです。

Matt Heuser氏はツイートで、異なるケイデンスを使用した企業の例を挙げている。

Heusser: Ron、次回のAgile&Beyondで私たちは、インドのある企業での成功例を紹介する予定です。それを顧客に紹介してみてはどうでしょうか。 @Hopasaurus

Matt Barcomb、John Cutler、Matt Heusser各氏に、ケイデンスの分離とそのメリットについて質問した。

InfoQ: 計画と改善をひとつのケイデンスで行なうことのメリットとデメリットは何でしょう？

Matt Barcomb: 明確にしておきたいのは、私が問題だと思っているのは、計画と改善を実際にひとつのケイデンスで行なうかどうかではなく、チームが独自のケイデンスで自分たちのイベントを実行できることなのです。“スクラムだから”という理由だけでケイデンスをひとつに限定することが、あまりにも多すぎます。

ケイデンスの分離が許されないことによるデメリットは、チームの自立性を失わせることと、最適でない結果をもたらすことです。メリットは言うまでもなく、その反対です:)

チームがケイデンスを切り離せないために生じたことで、実際に私が目にしたのは、次のようなものです。

• たかが“スプリントレベル”の作業のために、あまりにも多くの量と種類の計画作業が行なわれている。
• 計画が質的に低い、成果が少ない。
• チームが吸収可能な変革の量に対して、改善率が適切に調整されていない。
• 改善のアイデアを忘れる、必要な改善が遅れる。
• 役割や改善レベルの多様性が考慮されない。

もちろん、関与する要因は他にもありますし、ケイデンスを統一したまま上記の問題をある程度解決する方法も存在します。しかしながら、チーム独自のケイデンスを認めれば、彼らにとって最良のものを探し、学ぶことが可能になるのです。そして、それは多くの場合、よりよい結果を得るために有効です。

John Cutler: 改善と計画のケイデンスを結合する大きな根拠としてしばしば挙げられるのが、その便利さです。1回で“会議をまとめる”ことの重大性が選ばれるのです。さらに、レトロスペクティブでは、話題が計画サイクルの“成功”に集中する傾向がありますが、ケイデンスを結合しておけば、そこでの情報が“フレッシュ”であることを保証できます。

潜在的なデメリットはいくつかあります。まず、チームが吸収可能な進捗/プロセスの変化には限りがあるので、頻繁なレトロスペクティブは、雑用と見なされて精神的な負担となり、活力を失わせます。一方で、計画の２週間というケイデンスは、効果的な判断を下すには長過ぎるかも知れません。“一緒にやるか、まったくやらないか”という考え方は、チーム独自のニーズに合わせたアプローチの採用を不可能にするのです。

Matt Heusser: 統一することのメリットは簡単です。改善には、それを現実のものにするチャンスがあるからです。多くの企業は多忙な生産活動に追い回されているため、深く検討するような時間的余裕はありません。あるいは、彼らが熟考して何かしら提案したとしても、それを次のプロジェクトに提供するための公式な方法が存在しないのです。例えば私が所属したある会社は、多義性レビュー(ambiguity reviews)という考え方の虜になっていました。そのためプロジェクトマネージャのマネジメントが、“今後はすべてのプロジェクトで曖昧性レビューを実施して”チェックリストを作成する、と宣言しました。ですが、それだけです。実際にそれを行なったチームはありませんでした。スプリントの概念を導入すれば、実験(次回のスプリント)を開始する時間と終了する時間、次に何をするかを検討する(次回のレトロスペクティブ)時間が決まります。

“Customize Your Agile Approach: Select Your Agile Approach That Fits Your Context”という記事では、Johanna Rothman氏が、プロダクトやプロジェクト、あるいはチームのためにアジャイルアプローチをカスタマイズし、提供、計画、考察のケイデンスを設計する方法について検討している。

チームはすべてユニークであり、独自のアジャイルアプローチを必要としています。スクラムやXP、かんばんメソッドといった、既製のフレームワークを使用できるチームもありますが、私の経験では、ほとんどのチームが、自らの状況に合わせてアジャイルアプローチをカスタマイズする必要があります。(...) [ある状況においては]計画、デモ、リリースというケイデンスが必要かも知れませんし、別のチームでは、私たちがアジャイルの慣習だと考えているその３つすべてにおいて、同じケイデンスが機能しないことを見出すかも知れません。

InfoQ: ケイデンスの分離が推奨されるのは、どのような状況下なのでしょう？

Cutler: 私(あるいはチーム)は、エネルギのミスマッチないし情報フローのボトルネックを感じたときに、ケイデンスの分離を勧めています。例えば、2週間のスプリントの終わりのレトロスペクティブを考えてみましょう。状況はよくないのですが、誰もその“原因”を突き止められていません。情報がないのです。その一方で、継続的改善のかんばんボードは、EIP(experiments in progress)の枠が限界に達しています。継続的改善に関して実施中のイニシアティブは、すべてがまだ一般的な適用方法が可能なので、それらの有効性を再検討するような思い切った作業を行なう決心はついていません。

このような状況下で私たちは、いくつかの分離を試してみたいと考えました。1)スプリントの短縮、2) 問題が実際に発生している時点で、ジャスト・イン・タイムで15分間の“臨時”レトロスペクティブの実施、3) 隔週での短めのレトロスペクティブと、月毎のより深いレトロスペクティブ、などを試したかったのです。新たな認知負荷を獲得し、学習結果を行動に転換する上で、プルシステムが望ましいと思ったからです。

Barcomb: チームの柔軟性のために、どのような状況であってもケイデンスを分離することを推奨します。ケイデンスの分離はある意味“高度”なテクニックであって、新しいアジャイルチームにはマスターできない、アジャイルで仕事を始めたばかりのチームはケイデンスを結合する(基本的な“スクラムのやり方”)べきだ、という主張を聞いたことがあります。

個人的には、これは事実ではないと思っています。私は新しいアジャイルチームと仕事をする時でも、ケイデンスの結合を特別に勧めたり、逆に反対したりすることはありません。それよりも私は、チームにどのような習慣が必要か、そのためにはどのようなケイデンスが好都合か、といったことに関して、チームが議論するようにしていった方が有効だと思っています。神秘的だとか、あるいは高度なテクニックだとは、私は思っていません。逆に、誰かに“その方法はアジャイルではない”と言われるまで、すでにこのような方法で作業していた、という声もあるくらいです。率直に言って、ケイデンスの分離というコンセプトは、子供の雑用スケジュールよりも難しくはありません。

Heusser: 改善が実際に行われていて、チームが実験のデザインに長けているのであれば、計画と同じペースで進める必要はありません – 時間通りに、あるいは必要に応じて実行すればよいのです。私の見るところでの違いは、リアルタイムな意思決定に向かうためには、より多くのスキルが必要であることです。その点に関しては、さまざまな計画幅を試してみるとよいでしょう。スプリントは状況の一面に過ぎません。例えば野球ならば、打席、イニング、試合、シーズン、さらには今後数年間というレベルでチームを計画することができます。

計画と改善が混乱していたり、あるいは見掛け倒しであるような場合、私はまずスプリントを追加するようにしています。チームの作業にリズムが戻り、デリバリフローが予測可能な状態になったら、それらを取り除くのです。私は以前、インディアナ州のある組織で働いていました – Matt Barcomb氏が前任者で、長期に渡って成功を収め続けていました。そこで最初に試した実験のひとつが、ジャスト・イン・タイム・レトロスペクティブです。レトロスペクティブで話すべき問題がある場合には、ピンク色のカードをボードに貼るようにしました。カードが5枚になれば(あるいは適当な時間が経ったら)、レトロスペクティブを行なうのです。赤いカードは停止チェーンを引く意味で、可能な限り早急にレトロスペクティブをスケジュールします。

InfoQ: ケイデンスを分離することで、どのようなメリットが得られますか？

Heusser: 人為的なスケジュールではなく、起きるべきことが起きるようにすることは、よい結果をもたらすでしょう。同時にそれは、さらなるスキルを必要とします – 判断を必要とするような複雑なモデルは、規則に従うよりも難しいのです。

Barcomb: ケイデンスの分離は、最終的に適用性と自律性というメリットをもたらします。もしも自分たちの状況において理に適っているという理由から、チームが同じケイデンスを持つべきだと判断したのならば、それもよし、そうしましょう！他によいスタート方法がなければ、構いません、それをやってみましょう！ただし、ケイデンスを統一するように義務付けることはしないでください。それがチームの状況に適さなくなる日が来た時、彼らの期待に応えるために、自分たちの作業の方法を変えざるを得なくなるかも知れないからです。

Cutler: ケイデンスの分離は認知の多様性、チームの作業スタイル、情報の流れ、その情報に対する私たちの処理能力、複雑な作業に付きものの変動性といったものによく適用します。複数の人間がまったく同じケイデンスで、さまざまなタイプの作業や考察を行なうことができると考えるのは、ちょっと単純です。すべてをジャスト・イン・タイムかつ“フローベース”で行なうという意見にも、これと同じことが言えると同時に、高慢であるとも思います。チームの人間が、週末は何も考えたくないと言ったらどうしますか？