ブログ

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

スクラムを失敗させる方法

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

How to make Scrum failが良い記事だったので、抜粋・意訳にてご紹介します。

1. ふりかえり(レトロスペクティブ)をしないか、間違ったふりかえりをする

ふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか? ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。 そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない(形式的なふりかえり)なら、ふりかえりは役に立っていない。

2. ダメなプロダクトオーナー

プロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。 プロダクトオーナーはスプリントプランニングやふりかえりに参加しなければならない。 また一方でプロダクトオーナーはスプリント中のタスクは見積りしてはならない。見積りはチームの責任なのだ。 プロダクトオーナーはビジネス上の優先順位に基づいてプロダクトバックログアイテムの優先順位を付けなければならない。 このため、プロダクトオーナーはビジョンやビジネス計画やリリース計画を持っていなければならない。 また、プロダクトオーナーはチームが十分理解できるようにはっきりとしたプロダクトバックログアイテムを定義する必要がある。スプリント期間中のスプリントバックログの変更は行うべきではない。

3. ダメなスクラムマスター

スクラムマスターはチームの「管理者」であってはならない。チームは自己組織化されているべきなのだ。 スクラムマスターは指示に従わせるのではなく、必要なときに助言すれば良い。 スクラムマスターはチームメンバー間で合意できない事項について最終決定を下す必要がある。 スクラムマスターは優先順位をつけたプロジェクトの障壁事項のリストを用意し、できる限り早く解決していく必要がある。 スクラムマスターはチームを集中させ、物事が継続的に改善するようにする。物事はいつももっとうまくできる方法がある。 タスクを個人に割り当ててはならない。タスクはチームメンバー自身が自分たちで選択・担当していく。

4. スクラムの儀式(スタンドアップミーティング、スプリントプランニング・・・)にとっても時間がかかる

スタンドアップミーティングでは、全員が、やったこと、これからやること、困っていることについて発言すべきだ。 言わなければいけないことはこれで全てなのだ。 スタンドアップミーティングはおしゃべりの場ではなく、詳細な情報について話す場でもない。 スタンドアップミーティングはチームサイズによるが、10~15分以上かけてはいけない。 ふりかえりとスプリントプランニングも時間を決めて行う。ミーティングの本質にこだわろう。 スクラムはおもしろいはずだが、それは、遊び場であることを意味してはいないのだ。

5. 「完成(Done)」の定義を間違えている

各スプリントの終わりには作ったソフトウェア製品は製品としてリリース可能でデモが可能であるべきだ。 これはソフトウェアがユニットテストと結合テストが手動ではなく自動で行われる必要がある、ということを意味する。 もちろん、開発者はテスターがテストの合否を決める判定基準について知っておくべきで、自動テストと手動テストでは大きな違いがあるだろう。

6. ベロシティをトラッキングしていない

チームのベロシティをトラッキングしなければならない。 スクラムマスターはもしチームのベロシティが停滞していたら、何らかのアクションを取らなければならない。 スクラムマスターは「5回のなぜ」や石川教授が開発した「特性要因図」を使って根本原因を見つけなければならない。

7. スプリントの中でウォーターフォールをやっている

全てのプロダクトバックログアイテムを75%完成させるより、75%のプロダクトバックログアイテムを100%完了させた方が良い。 (完成の定義を参照)。 一個人ではなくチーム全体でプロダクトバックログアイテムを担当し、テスターもチームの一員とすべきである。

8. 技術的負債がある

技術的負債は、最後に更なる別の問題が発覚し、本来各イテレーションでは同じように機能を作れなければならないところなのに、最後の方のイテレーションが新しい機能を作れなくなりうる、という理由で、避けなければならない。 リファクタリングや再設計は必要と思ったときに速やかに行われなければならない。 なぜなら、最後にまとめてやろうとすると。多くのコストと時間がかかりすぎて行うことが難しいからだ。 バグについても同じようにできる限り早く解決しなければならない。

9. 割り込み/プロダクトオーナーを経由されない

チームは集中し続けなければならない。これは多すぎる割り込みは「悪」である、ということだ。 もちろん、誰でも助けを求めることができるが、新しい機能に関してはプロダクトオーナーに要求すべきである。 プロダクトオーナーは新しい機能に関する要求をバックログに追加し、優先順位を振りなおすべきである。 もしそれが重要な機能なら、チームは次のスプリントの最後には納品することができるだろう。 誰もチームメンバーに直接機能の追加要求を行ってはならない。

10. 分析やドキュメントがない

スクラムは何の分析もしなくて良いし、何のドキュメントを書かなくても良い、と言っているわけではない。 分析のとドキュメントの作り方は既存のやり方とはちょっとだけ違っていて、その違いは継続的なプロセスであるということだ。 バックログに記載されたプロダクトバックログアイテムはチームがタスクに分割し、スプリントプランニングで見積もるのに十分なだけ、はっきりさせる必要がある。 (スプリントで実装できそうであれば、それは十分に詳細化されている、ということだ。) これはプロダクトバックログアイテムはプロジェクトの開始時点で細かくし過ぎるのではなく、バックログを作る時にストーリーポイントで見積もれるくらいにしておくべきである、というこである。

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

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

詳細はこちら
  • スクラム実践者が知るべき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』の著者がコンパクトにまとめた変化のためのガイドブック