"bennyou.cpt1"は他のことに集中するためにスプリントを中断することについて質問している。
スプリントを実行したり停止したりするのはとても大変です。チームは同じプロジェクトや製品に従事しているので、より大きな状況を見失ってしまうという構造的な問題が発生しがちです。長いスプリントをいったん停止して、何らかのスプリントを開始することで体制を立て直そうとしたり、そうしようと考えたことがある人はいますか。
[...]
私が良く使うたとえは、地図を見ながら運転するのは難しい、というものです。正しい道を確実に進むには止まって、考え直すことも必要です。
Wolfgang Wiedenroth氏は体制を立て直すことの必要性を認めない。
- プロダクトオーナが地図を管理し、製品の向かう先を修正している。[...]
- 各スプリントはタイムボックスで管理されているので、休止もチームの計画に織り込まれている。このタイミングでチームは地図を確認すること機会が得られる。まずはスプリントレビューで、後にスプリントプランニングで道筋を調整することもできる。
したがって、これ以上の休止または"調整用のスプリント"は必要ないです。リリース直前に"バグ修正スプリント"を行うのが望ましくないのと同じです。
チームは持続できる速さで作業をして、計画のための十分な時間を確保するべきです。
Dave Barrett氏のスクラムの経験では、少なくともバーンアウトの観点からは、スプリントを一時停止する必要はない。
確かに、一時停止せずに継続的に機能追加を繰り返すのは、それ自体が大変なことになるのではないかと思います。しかし、7年間次から次へとスプリントを休みなく続けて問題になったことはありません。私が思うに、スクラムへと移行することでチームのメンバは悪い影響をほとんど受けません。チームはいつも成功するようになります。期限も自分で決められますし、合理的でない顧客/ユーザからの要求はほとんどの場合、"プロダクトバックログに入れておきます"という言葉で対処できます。だから、彼らに毎月成果物を提供できるでしょうし、成果物を受け渡したらすぐに新しい期限の中で、成功が約束されている新しい成果を生み出すことができます。
Jon Archer氏は製品のバックログから距離を置く手法を紹介する。
私たちは各四半期毎にリリースをしていますが、各リリースの間に"革新的な"スプリントを実施しようと決めたところです。息抜きのためでもありますし、少し好きなことをやらせるためでもあります...そのかわり、みんなはスプリントに復帰したら自分の学んだことを"みんなに説明する"必要があります。実際にはまだ実施していませんが、私はこのアイディアを気に入っていますし、値打ちがあると思っています。
Jussi Mäkelä氏も同じような考えを持っているようだ。しかし、氏の手法はテンポが速い。
3週間のスプリントを実行している会社を知っています。スプリントの最後の日は、学習と試行錯誤に当てます。この方法は上手くいっているようです。"普通"のことでスプリントを停止して、面白いと思ったことに着目できるので、優れた方法です。
Alan Dayley氏は対局を見るための他の方法を列挙する。
イベントを通じて共有文化を作っているチームがあります。いずれのイベントも内容を提供するチームの外から参加することもあります。チームの垣根を超えた参加者がいることはよくあることです。
- 最低でも、スプリントで新しいアーキテクチャを表現したり、利害関係者へプレゼンしたり、設計についての議論をしっかりする時は、"テックトーク"を行います。このトークのトピックは製品についてのコミュニケーションに必要なことでもいいでしょう。または、誰かが自発的に知識のギャップを埋めるのもいいでしょう。このトークは一時間くらい行います。
- 一ヶ月に一度はラーニングランチを行います。2、3人がどんなことでもいいので発表します(庭いじり、写真、ピンボールマシンの収集と修理、本のレビューなど)。皆、昼食を持ち寄ったり、宅配ピザを頼んだりしながら参加します。
- 設計とコードのレビューは一度のスプリントに４回、断続的に行うように計画します。スプリントプランニングや毎日のミーティングの間にチームのメンバの作業がレビューされます。最初のレビューワーは決めておきます。興味があるならチームのどのメンバでも参加できます。時間は一時間くらいです。必要なら他のセッションでもレビューを続けます。一時間を超えるレビューは急速に価値を失いがちです。