スクラムチームの引き継ぎで崩壊した話
この記事はDevLOVE Advent Calendar 2018の20日目の記事です。
概要
先日イベントに参加してLTしようとしたが、仕事忙しすぎて参加できなかったので、資料の行間を文章にまとめておこうと思います。
↓発表予定だった資料
引き継ぎ前の我流スクラム
- 2wスプリント
- プロダクトバックログはスプレッドシートに羅列
- ホワイトボードと付箋でタスク管理
- 担当者ごとにタスクレーンを作成
- ストーリーに対して見積もりはほぼ行わず、「だいたいこれくらいできるかな？」をメンバーが各々に判断してスケジュールを作成
- リファインメント、レビューは未実施
- デイリースクラムは実施
所感
メンバーとしてはスクラムに関する知識が浅く、当時のリーダーに運営を頼りきりでした。
また、「見積もりが担当者に依存している」＆「タスクレーンが担当者ごとに分かれている」ことで、お互いの作業に対して積極的に情報を取りに行かないといけない状態になっていました。ここは当時のリーダーが交通整理をしていました。
そして、チームとして達成すべきゴールが不明瞭であるため、計画したタスクが終わらないことに対する危機感が薄い状態になっていました。（そもそも妥当な計画がわかっていない）
チームを引き継いだ結果
見よう見まねでスクラムマスター的な振る舞いをした結果
- プロダクトバックログは優先順位もつかず、やるべきもの、捨てるものがごちゃまぜに
- スクラムボードには数ヶ月前に貼られたタスクがdoingに残りっぱなし
- いつdoneしたかわからないタスクも残りっぱなし
- そして実際にメンバーが取り組んでいる作業はボード上にはない
所感
スクラムで開発する目的が不明瞭でした。
自分たちがなぜこの方法で開発しているかを理解していない上、手法についても理解が浅かったため、ふりかえりすらも義務感からやっている状態でした。
さらに、過去ある程度コミュニケーションをお互いに取らなくてもリーダーが補完してくれていることで回っていたことに気づかず、少人数ながらお互いにやっていることがわからず、お互いのサポートができない状態になっていました。
改善フェーズ1
- とりあえず物理ホワイトボードからTrelloに移行
- ふりかえりの学びを活かすためにホワイトボードに気をつけるポイントとかを明文化
所感
根本的な問題に気づかずに場当たり的にツールを試していました。
結局問題は解決できず、ツール上でもすぐに荒廃してしまいました。
改善フェーズ2
所感
自分の現在のスキルではどうにも対応することができないことに気づきました。
そこで勉強会に参加して生の声を集めること、書籍からメソッドを学ぶことにシフトしました。
ここで重要だったことは「学んだことを素直にそのまま試す」ということでした。
中途半端に知ったかぶりをせず、学んだことをそのまま実践したことで、チームの成長が加速していきました。
また色々なことを同時に試すと、何が良くて何が悪かったかが見えなくなってしまうため、1スプリントで1つずつ改善をしていきました。
まとめ
- ぶっこわしてもいいんだ。 →何をやってもうまくいかないフェーズは避けては通れないので、大きく失敗する。ただし、信頼できるチームメイトに恵まれていないと危険。
- 人に依存していると退職のダメージは大きい。 →全員がチームの成長を実感してそこに貢献していることを感じていないと、依存している1人がいなくなった時に死にます。
- 近くにいてもチームであるとは限らない。 →コミュニケーションは場を設けなければ自然発生させることができません。そのためにスクラムのイベントを活用しましょう。
- スラム化してしまったら、意識のドラスティックな変革を。 →過去にしがみついても仕方がない、今まで自分たちがやってきたことは捨てるという勇気が必要です。
- 書籍は実際に試さないと勿体無い。 →逆に言うと、現場ですぐに実践できないような内容の書籍を読んだとしても、スキルを身につけることは難しいので、投資効果が悪いです。
- 経験者はやさしいから思い切り甘える。 （ただしできる限りのアウトプットを） →無料の勉強会を続けているコミュニティを尊重しましょう。タダ乗りはダメです。Twitterで呟くもよし、参加レポをブログで書くもよし。
- 認定スクラム研修はいいぞ。 （参加前にあがいていたからこそだったかも） →参加前にいろいろとうまくいかなかったことの答え合わせができました。そこで知識として頭に定着した感じがあります。
チームの引き継ぎで悩んでいる人に届けば幸いです。
