こんばんは今年の3月から3ヶ月だけですがPOをやり今月からスクラムマスターをやることになりましたhirokinishizawaです。
スクラムマスターになってから1ヶ月がたつので本記事で振り返りつつ、スクラムマスターになってから失敗したなと思ったことを話していければと思います。
はじめに
SARDINEの開発チームは2軸でやっています。その中で1チームだけ10月頃からスクラムを導入し始めました。
当時自分はスクラムを導入した方のチームに所属しており、3月からもう一つのチームがスクラムを導入するタイミングで3ヶ月だけですがPOをやりました。そして今月6月から現在そのチームでスクラムマスターをやっています。
スクラムチームのそれぞれの役割
- PO(プロダクトオーナー): 開発チームから生み出されるプロダクトの価値を最大化すること
- 開発チーム: 開発チームの開発効率を最適化すること
- スクラムマスター: スクラムの促進と支援をし目的を実現する確率を最大化すること
スクラムマスターの責任
スクラムマスターはスプリントを円滑に進めることに責任を持ちます。
その中には
- 開発チームが行ったスプリント計画の障害になるものを取り除く
- 次のスプリントをよくするために気づきやコミュニケーションを促す
- プロダクトオーナーのプロダクトバックログの作成や並び替えを支援する
- プロダクトオーナーと開発チームの会話を促す
などまだまだありますが基本的になにかを決定をするのではなくあくまでサポートする動きをしてスプリントを円滑に進めるように動きます。
スクラムマスターになってからの失敗談
POをやっていたときはなるべく要件から仕様までやってプランニング(見積もり)readyの状態をつくるようにしていました。なるべくというのはどうしてもバックログの調査や整理などが間に合っていなく、必要なときはタスクを作っていて開発チームがプランニングをするために障害がなくなることに注力してしまっていました。
その状態のままスクラムマスターになって失敗したなと思ったことを書いていこうかと思います。
POから要件を受け取りプランニングreadyの状態にする
POをやっていた時はゆくゆく仕様なども開発チームに降ろすようにしなければいけないと思っていました。ですがスクラムも始まったばかりだったので基本的にはプランニングの時に見積もりが出来る状態を意識してやっていました。そんな状態のままスクラムマスターになり、POから降ってきた要件を見積もりが出来る状態までタスク分解をやったことにより
- プランニングがただポイントをつけるだけの作業になってしまっていた
- スクラムマスターで閉じてしまっているため質問がないと共有出来ていないことがあり共通認識があわなかった
のような状態になってしまった。
開発チームの中継役になってしまう
実際にスクラムマスターとしてサポートするというのがどういうことなのか深く理解できていませんでした。最初はサポートとしてタスクの管理やアサイン、スプリント内であった開発チームの不安要素などを吸い上げPOに確認を自分が行っていました。ですがそれを続けたらPOと開発チームの中継になりコミュニケーションをスクラムマスターを通すというルールになっていきそうだったためやめました。基本的に開発チームがPOやステークホルダーとコミュニケーションを取っては行けないというルールはありません。
現在はスプリント内で上がった不安要素や技術課題などの優先順位をつけるためにPOとのコミュニケーションを促すようにしています。
まとめ
スクラムマスターの最終目的としてスクラムチーム にスクラムマスターってもういらないよね？ というチームにしなければいけないと思っています。なのでスクラムマスターが見積もりが出来る状態までやるのはやりすぎに入ってしまいます。
見積もりするために何を準備すればいいのではないか、またどのように解決すればいいのではないか。というのように決定・命令はせずスクラムチームに気づきを促すサポートをしていくのがスクラムマスターなのではないかと思います。
まだまだ未熟なので間違っているところなどご指摘いただけると幸いです！8/7~8/9の間CSM行ってまいります！
最後に
で8/7~8/9でCSMを受けに行ってくるので終わったらいろんな人が書いていますが自分もブログを書きたいと思います！
現在、株式会社SCOUTERでは、エンジニア、デザイナーの募集をしております。
興味のある方は、是非下記からご応募お願い致します！
