0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

[スクラム] 1週間スプリントを目指して失敗した話 〜理想のスクラム運用と現実のギャップ〜

0
Posted at

はじめに

この記事では、4人チームで

  • 2週間スプリント → 1週間スプリント
  • シフトライト → シフトレフト
  • 個人作業中心 → チーム作業中心

を目指したものの、うまくいかなかった取り組みと、そこから得られた学びをまとめます。
( 理想と現実というと大げさではありますが、ふりかえりがてら記事として残しておきたいと思いました )

前提

チーム構成

  • 正社員: 2名
  • 業務委託: 2名

スクラムへのとりくみ

理解度・経験値

  • スクラムによる開発経験: チーム全員が経験済み
  • ファシリテーター経験: 1名のみ

やっていたこと

  • スプリント
  • デイリースクラム
  • スプリントプランニング
  • レトロスペクティブ

現状と目指すゴール

これまでは

  • スプリント期間: 2週間( 10営業日 )
  • 成果物: スプリント単位で提供できていない
  • QA: シフトライト( 成果物ができてからまとめて実施 )
  • スクラムチーム: 個人単位での動きが多い
  • スプリントの状態: ストーリーが1スプリント内に完了しないことが多い
  • スプリントレビュー: 成果物があるときは実施する
  • ファシリテーター: デイリースクラムを除くイベントは担当が固定されていた

ゴール

  • スプリント期間: 1週間( 5営業日 )
  • 成果物: スプリント単位で提供する
  • QA: シフトレフト( スプリント内で実施 )
  • スクラムチーム: チーム単位で動く
  • スプリントの状態: ストーリーが1スプリント内に完了する
  • スプリントレビュー: 毎スプリントで実施する
  • ファシリテーター: デイリースクラムを含むイベントの担当をローテーションする

表にすると

項目 これまで ゴール
スプリント期間 2週間( 10営業日 ) 1週間( 5営業日 )
ファシリテーター 1名固定 ローテーション制
QA シフトライト( あとでまとめて実施 ) シフトレフト( スプリント内で実施 )
チーム 個人単位での動き チーム単位での動き
スプリントの状態 ストーリーが1スプリント内に完了しないことが多い ストーリーが1スプリント内に完了する
スプリントレビュー 成果物があるときは実施する 毎スプリントで実施する

ゴールに向けて

目指したことは

これまで箇条書きで示してきたゴールを、あらためて文章にしてみます。

すなわち、チームがチームとして動くことで自律性を高め、スプリント内で完了するストーリーを増やし、成果物を毎スプリント提供できるようにすることです。
これによって、チーム全体の生産性向上と品質向上を目指しました。

また 2週間スプリント では進行にメリハリがなく、ダラダラと時間が流れてしまっていたことも課題と感じていました。
そこからメリハリの利いたスプリントにしたいと考え、1週間スプリントで小さく素早く価値を提供することを目指しました。

※ この「メリハリをつけたい」という動機が、結果的に自分たちの成熟度を超えた挑戦になっていたと、今では感じています。

スプリント内でやりたかった流れ.png
( 図1: スプリント内でやりたかった流れ )

取り組んだこと

  • ストーリーマッピングを行い、やるべきことを明確にする
  • それを元にプランニング時にタスクを明確化する
  • リファインメントによる作業項目の見直しと優先度見直し

取り組もうとしたができなかったこと

  • 1スプリントで取り組む作業( ストーリー ) を一つとする
    • 想定以上にストーリー分解の精度が低かった
  • ストーリーに対して実装とQA準備で担当を分担する
    • QA観点を持ってテストを実施できていなかった
    • それを改善すべくQAとして明確な役割を持たせたかった
  • 次スプリント予定タスクの調査
  • スプリント中の QA 実施
  • 上記の担当に加えてスクラムイベントのファシリテーターをローテーションする

ふりかえり( W/H/T( わかったこと / 反省点 / つぎやること ) )

わかったこと

細かいことはいくつも出てくるのですが、大きなトピックとしては

  • いきなり理想のゴールを設定してもチームがそれを目指して走れるほど成熟していなかった

これに尽きるかな、と思っています。
上記に付随するものとして細かいものを挙げると

  • ストーリーマッピングは難しい
  • ファシリテーターをいきなりローテーションしようとしても心理的障壁がある

といった点が出てくるかな、と思います。

補足すると
描いていた道筋はこうでした。

  1. ストーリーマッピングをすることで価値提供に向けたストーリーが分解される
    1. このストーリーは1スプリントで対応できる価値を提供する単位になっている
  2. プランニングではストーリーを 実装・QA の実務単位で担当をアサインする
  3. 実務担当ではないメンバは次スプリントで対応するストーリーの調査を行う
    1. これによってスプリント中にスパイクが発生する可能性を減らす
  4. 各作業はローテーションすることでチームメンバの知見の平準化を目指す

これらによって、ゴール に辿り着くことができると考えていたのです。

反省点

理想をゴールにするのではなく、自分たちがいま目指せるものはなにか、までゴールを分解することから始めるべきだったな、と今では思います。
これもストーリーマッピングになると思うのですが、

  • 自分たちの現状を把握すること
  • そこからゴール( 要件 )に対してどう歩んでいけばよいのかを整理すること

これができていれば、いきなりゴールに向かって走ろう、という動きにはならなかったのではないか、というのが反省点になります。

つぎやること

( 冒頭に記載の通りいまは別のチームに異動しているのですが )
もし今後スプリント運用を任されることになったら、反省点 で挙げた 2点 と、心理的安全性が確保された良い雰囲気のチームを目指して、

  • 自分たちにあったワーキングアグリーメントを設ける
  • 自分たちの現状を把握すること
  • そこからゴール( 要件 )に対してどう歩んでいけばよいのかを整理すること

上記の 3本 を意識して取り組もうと思います。

まとめにかえて

私たちのチームと同じように、

  • 少人数チーム
  • スクラム経験はあるが成熟していない
  • 改善意欲は高い

という状況のチームでは、いきなり理想の運用を目指すよりも「今できる一段階上」を合意するところから始めるのが大切だと感じました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?