ブログ

ryuzeeによるブログ記事。不定期更新

スプリントの期間を長くしたいと思ったら...

みなさんこんにちは。@ryuzeeです。

元記事はLichard Lawrence氏のWhy Longer Sprints Probably Won’t Helpです。 良記事でしたので抜粋・意訳にてご紹介します。

本文に入る前に若干前提事項を補足しておきます。

  • 以下で言っている「スプリント期間を伸ばす」というのは、あるスプリントだけの期間を伸ばすのではなく、スプリントのサイズ自体を変えることです(例:2週間スプリント→4週間スプリント)
  • タイムボックスであることに意味があるので、ご存知の通り「あと1日あれば終わる」とか言ってスプリント期間を延長することは許されません
  • そしてスプリントの期間は原則固定なので、今回は2週間、次回は4週間、その次は1週間、というのも無しです。ただし変化への対応はもちろん大事。今回はその点に関するお話です

コーチとしてよく、「スプリント期間が短すぎるので、XからYに変更したい」と言われます。

タイムボックス(スクラムではスプリント、XPやその他の方法論でのイテレーションなど)は、アジャイル開発における問題を浮き彫りにする最も効果的なツールの一つです。私が経験した中で、実際にスプリント期間が短すぎるというケースは少ないです。それより、スプリントの期間が短いと感じる背後には、深刻な問題が隠れていることが多いと思います。単純にスプリントの期間を伸ばすのは、問題の本質的な解決ではなく、問題を覆い隠すことになるでしょう。

スプリントの期間を伸ばす前に、以下のような点について「なぜ?」と繰り返し問いかけてみてください。そして、これらの問題へまず取り組みましょう。確かにスプリントの期間が短いこともあるかもしれませんが、その点だけに焦点をあてずに全体を見るべきです。

1. ミニウォーターフォールを試みている

ミニウォーターフォールのサイクルを1〜2週間に詰め込むのは大変です。スプリントの後半で急にテストを開始し、時間が足りなくなる場合、ATDDなどの手法を活用して早期にテストを行ったり、取り組むタスクの量を減らす必要があります。

2. プロダクトバックログアイテムの分割が上手くできていない

無駄な手間をかけずに進捗を予測するために、私は1スプリントで6〜10のプロダクトバックログアイテムに絞ることをおすすめします。スプリント期間内でこれらのアイテムを適切に分割するのが難しい場合、スプリントの期間を伸ばしたくなるかもしれませんが、それよりもアイテムの分割スキルを高めることが重要です。

3. イベントが長すぎる

おそらく、スクラムのイベント、特にスプリントプランニングは長引きがちでしょう。もし2週間の作業を3週間でやると50%の成果が上がると感じるなら、スプリントプランニングでも50%多くの議論が必要になります。しかし、実際にはその効果は期待通りには出ないでしょう。

その代わりに、イベントの効率を向上させる努力が求められます。私が指導したチームでは以下の方法で、スプリントプランニングの時間を大幅に短縮することができました。

  • チームの必要なメンバーで、毎日または2日に1回の頻度でバックログリファインメントを実施
  • タスクの見積もりよりもベロシティに基づいて計画を進める
  • タスクはスプリント中に必要に応じて整理
  • スプリントプランニングは段階的に行い、必要に応じて詳細な議論を重ねる

このようなアプローチは、あなたのチームにも適用できるかもしれません。

4. デプロイやマージが難しい

スプリント毎に完了したプロダクトバックログアイテムをステージングサーバや本番テスト環境にデプロイすることは一般的です。時には外部のリリースマネージャの協力が必要かもしれません。しかし、これには時間がかかり、煩わしいと感じるのも当然です。

私はJez HumbleとDavid Farleyの「Continuous Delivery」という本のアドバイスに深く同意します。 「苦痛な作業であれば、それを頻繁に実施して苦痛を解消すべきだ」という内容(p. 26)です。問題を先送りにするのではなく、解決策を探るべきです。もし毎スプリントのデプロイが難しいなら、夜間ビルドや各コミット毎のデプロイの方法を模索しましょう。

5. 2週間での成果が乏しい

チームは「2週間では価値あるデリバリーが難しい。よって、もっと長いスプリントが必要だ」と感じるかもしれません。だが、スプリントを2週間から4週間に伸ばしても、2週間でのデリバリーの量は変わりません。スプリントを伸ばすより、以下のアプローチを試みると良いでしょう。

  • プロダクトバックログアイテムをまとめて、価値のある単位に整理する
  • プロダクトバックログアイテムの進捗を明確にして、どれがリリース可能かを明示する
  • デリバリーが少ない原因を「5回のなぜ」などの方法で分析する
  • 技術的負債やプロセスの過剰なオーバーヘッドが問題かもしれません
  • あるいはチームの技術的なスキルの偏りや、古いプラットフォームの利用が生産性を下げているかもしれません

6. フィードバックが遅い

プロダクトオーナーが質問の回答に1週間かかる場合、短いスプリントでの完了は難しいでしょう。しかし、スプリントを3週間に延ばすことが解決策とは限りません。フィードバックサイクルを速めるための方法を検討すべきです。

  • プロダクトオーナーの他の役割を減少させ、彼らの主要な役割に集中させる
  • 必要以上にステークホルダーに質問しないよう、プロダクトオーナーやチームにもっと決定権を委譲する
  • チームが自ら問題を解決できるような知識やスキルを蓄積する

7. 外部のスペシャリストへの依存

チームが外部のスペシャリスト(DBA、テクニカルライター、特定技術者など)の協力なしにプロダクトバックログアイテムを完了できない場合があります。これらのスペシャリストは多くの場合、複数のチームでのパートタイム作業をしています。スプリントを長くする前に、以下のような方法で依存関係を削減する試みが必要です。

  • スペシャリストをチームにフルタイムで参加させる
  • スペシャリストのタスクを減少させて、チームへの参加時間を増やす
  • チームがスペシャリストのスキルや知識を習得する

まとめ

上述した問題に直面している場合、スプリントの期間が短すぎると感じるかもしれません。スプリントの期間を延ばすことも一つの方法ですが、まずは現状のプロセスを見直し、問題の根本原因を解決することが重要です。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック