分散アジャイルチームについて考える会の登壇資料です。
スクラム開発におけるマネジメント、評価指標・サポート・オンボーディング https://distributed-agile-team.connpass.com/event/195425/ https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14619
スクラム開発におけるマネジメント、 評価指標・サポート・オンボーディング 常松祐一 2020/12/17
View Slide
自己紹介 ● 常松祐一 (つねまつ ゆういち) ○ Engineering Manager ○ Software Engineering Coach ○ Agile Development ● SNSアカウント ○ tunepolo : ○ tune : ● 顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースする開発体制のあり方を模索しています。
3自分にとってBESTなお店が見つかる 日本最大級の"実名型"グルメサービス レビューよりもレコメンド。 Rettyは他人におすすめしたい 美味しいお店を投稿するサービス！ 食の好みは人それぞれ。 自分と嗜好が合う人をフォローして、 BESTなお店を見つけられるSNS型！ 実名制の口コミだからこそ 「信頼できる」「ポジティブ」な 情報が集まっています！ 批評ではなくオススメの口コミ 自分と好みが近い人から探せる 顔が見えて信頼できる実名制
Rettyの開発プロセスにおける私の立ち位置 POBackLogPdM TeamPdMPlannerDesignerPdMPlannerDesignerFeature Team x 5ユーザーストーリー追加ユーザーストーリー追加ユーザーストーリー並び替え開発着手Engineer TeamリファインメントSM EngineerSM EngineerManager&プロセス全体の問題解決EngineerSM
前回登壇(Scrum Fest Osaka 2020)のおさらい 1. スクラム開発におけるマネジメント → 開発チームに対しての話 2. 目標設定・フィードバック・評価 → 個人に対しての話 Photo by Hans-Peter Gauster on Unsplash
Photo by Hannah Busing on Unsplash前回登壇(Scrum Fest Osaka 2020)のまとめ @nakayama_sanのTweetより引用
今日の発表の前提・立ち位置 ● 議論を好む勉強会だと思い、モヤモヤポイントもそのまま持ってきています。 ● 「スクラム開発におけるマネジメント」ですが、所々「スクラム開発をやっている現場でのマネジメント」になっているかもしれません。
評価指標
スクラムチームの評価 ● ステークホルダーに素直に聞く ○ ここで不満がでるなら他に何を取り繕ってもダメ ● チームメンバーに素直に聞く ● 実験を評価する ○ 一時的にチームパフォーマンスが落ちても新しいやり方を模索して欲しい
スクラムチーム個人の評価 - よかったもの ● やることが変わっても変更の必要性がない ○ チーム開発に貢献するスタンス、着手からリリースまでの日数、障害数など ● 複数観点で設定する。施策・不具合対応・チーム外貢献など ○ 調整の余地がある ● 可能であれば持ち場を持たせる ○ ドキュメントの整理、QAプロセスの改善、リファクタリングのリードなど
スクラムチーム個人の評価 - 悪かったもの ● やりきり目標 vs 定量目標 ○ 人によって向き・不向きがある。 ○ ほどよい難易度に定量目標を置くことは難しい →月1くらいで調整しないと実態からずれる。 ● 個人・チームでコントロールできないものが含まれている ○ 会社都合・外部都合でリリースがブロックされるとか
サポート
1on1の開催 ● 週1回 最大30分 ○ よかったことも悪かったことも、早めにフィードバック ○ 伝えたいことがある時だけ設定すると相手が身構える。 ● マネージャーと行う。 ○ PO/SMと行うことは止めないが、権威化・上下関係が生まれるのではないか? ● 気をつけていること ○ スクラム開発の進捗報告は適当に聞き流す ○ チームの問題はチームで解決してもらう
問題のエスカレーション ● 複数チームでスクラムを行っているため、振り返り結果の共有会を毎週実施する ● チーム内で解決できない課題をエスカレーションしてもらう。課題はマネージャー間で相談して対処する。 ○ すぐに対処する問題 ○ すぐに対処しない問題
オンボーディング
チームを立ち上げるとき ● チームメンバーの構成 ○ 案1)スキルマップを考慮してバランスよく考える ○ 案2)メンバーに決めてもらう ● スクラムマスターの選び方 ○ 案1)やる気がある人、立候補 ○ 案2)場・役割を与えられて動く人 ○ 案3)リーダーや管理職候補ばかりにしない
スクラムマスターを育てる ● まずはスクラムの基本をキチンと守らせる ○ 2〜3ヶ月経つと開発の各所に違和感を感じるようになるのでそこからスタート ● 専任か兼任か ○ Rettyでは今のところ全員「兼任」 ■ 自身の希望抜きに専任させるのどうなんでしょう?キャリアに繋がるのか？ ■ スクラムマスターを外部から雇い入れる？ ○ 専任ならチーム外まで目を光らせて欲しいけど
メンバーをチームに入れるとき ● 早々にチームに入れる。準備期間は特に設けない。 ● チーム開発を意識させる ○ 「〇〇さんのために簡単なタスクが欲しい」は怪しいサイン
マネージャーの育成
マネージャーの育成 ● プレイヤーとして手を動かすのを止めてもらう ○ プレイングマネージャーとして評価されることと、マネージャーとして評価されることは別 ● テコ入れするポイントを見極める ○ 縛りプレイを心がける ● マネージャーにとっての成功 ○ メンバーの成長、生き生きと働いてくれていること
まとめ
まとめ ● 今回の発表は「ベストプラクティス」というより、常松が悩んでいるポイントの吐き出し ● アジャイルな開発を支えられるマネジメントのレベルアップをしていきたいので疑問・質問・議論は歓迎です。
tunepolo
shoheitokumitsu
yasslab
kuzen
mitsu9
libinc
takagishokai
turing
xmile
andforce
gmofh_hr_team
toranoana
supership
carmenintech
rmw
pedronauck
revolveconf
panda_program
dougneiner
malarkey
jasonvnalue
brettharned
dotmariusz
yeseniaperezcruz
caitiem20