DevLove関西 FearlessChange実践編SREチームにおけるスクラムの実践株式会社はてな SREid:hokkai7go
View Slide
はてなSREチームから来ました
突撃！隣のDevOpsで紹介されましたhttps://dev.classmethod.jp/devops/dev-ops-hatena/
今日話すことは既にブログ記事化済みSREチームにおけるスクラムの実践https://blog.hokkai7go.jp/entry/devlove-kansai-sre-scrum
概要我々SREは日々割り込みを処理しつつ、技術的負債の返済や新しい仕組みの導入といった予定されたエンジニアリングタスクにも取り組んでいます。プロダクトオーナー兼スクラムマスターの上長からスクラムマスターを引き継いだときから現在に至るまでに取り組んだこととチームの変化についてお話します。
チーム● 人数数えるのに片手以上必要な大きなチーム● インフラ構築から、SREのいないチームの運用までを担当し、SREのいないチームでこぼれたものを拾う役割もある。基盤となるソフトウェアやミドルウェアの面倒を見ているチーム
チーム● 機能横断的かと言われると、SREに寄りすぎている組織ではある
チームでのスクラム● スプリントは2週間、スプリントレビューはできていない● チームが見ているスプリントバックログと、POとチームで見ているプロダクトバックログがある。
チームでのスクラム● 昼にデイリースクラムをやっている● 東京と京都両方にメンバーがいるので、コミュニケーションは基本的にオンライン（Slack, GitHub projects,Hangout meet)● 振り返りもオンラインでKPT→YWT→KPTと変化
チームでのスクラム● プロダクトを持っているチームと違って、横断的に全チームが使うソフトウェア/インフラを提供するためのリポジトリがたくさんある状態
チームでのスクラム● インクリメンタルな仕事以外、つまり割り込みについては見積もりを付けずに管理している。計画可能なインクリメンタルな仕事についてはプロダクトオーナーがプロダクトバックログに登録し、チームがタスクの分解、見積もり、といったプロセスを関係者で経てからタスク着手としている。● ストーリーポイントにはフィボナッチ数を使っている
スクラムマスターを引き継ぐ
スクラムマスターを引き継ぐ● プロダクトオーナー兼スクラムマスターの上長からスクラムマスターを引き継ぐ● 前職で開発チームの一員(インフラ担当)として働いていたときにスクラムを初めて体験した● スクラムマスターについてはPOとの対話という点において大変そうだなとしか思っていなかった
スクラムマスターを引き継ぐ● エンジニアリングに集中するものの、マネジメントにも興味があるということで入社した。スクラムマスターやりませんかという打診を上長からされて、2019/2にスクラムマスターになった● 正式な推進担当者(29)
(昔話)スクラム導入時の話● id:hokkai7go入社前(入社後にはすでにスクラム始まってた● プロダクトオーナー曰く、スクラム始める前には、割り込みが多すぎてまじで何もできんって状況だった● 少しでも前進したということを確認しようという意味でスクラムを導入した
ここからはスクラムマスターになってから取り組んだこと
チームのスクラムの知識ベースを揃えた● メンバーによってスクラムについての知識、経験がバラバラだったので、スクラムブートキャンプ本を読んでもらい全員が読み終わるのを見届けた● 外部のお墨付き(12)
スクラムマスターになってすぐ直面した問題1● チームがまだスクラムに慣れてない頃、スプリントバックログアイテム着手時の違和感をプロダクトオーナーではなくスクラムマスターに伝えられたり、プロダクトオーナーとの対立の原因となりうる捉え方をされてしまった
スクラムマスターになってすぐ直面した問題1● スクラムマスターとしてはサポートするが、プロダクトオーナーとの直接の会話でのみ解決されることを伝えた。また対立するのではなく協調して働く必要性を伝えた。対立の原因については、タスク分解のタイミングまたはバックログリファインメント、デイリースクラム等で違和感を共有して解決までもっていけるように促した
スクラムマスターになってすぐ直面した問題2● タスク間の重複がないため、昼会(デイリースクラム)が意味のないものになりかけていた○ 昼会についての改善はたくさんやっているので後ほど話します
最近直面した問題● 急に思いつきのように昼会の一部変えようとしたら抵抗された話○ 課題感の共有なしにふわっとした提案だけしてしまった○ 「つまり何が良くなるの？」(＝効果測定してほしい) という反応が来た○ 学んだこと: 提案には背景(の考え)を添える、振り返りなど課題に向き合いやすい場に持っていく○ 結果的には、振り返りの場で提案が受け入れられた
チーム運営のオープン化
チーム運営のオープン化1● ある日の振り返りからチーム運営についての内容が多く出るようになってきた。POとスクラムマスターでチーム運営を考える会議をしていたが廃止。チーム運営に関する話題はスクラムイベントで話すようにした● これによりチームメンバーが自分たちの手で日々のプロセスを変えられるようになってきた。例えば昼会のアジェンダとか、スクラムイベントのアジェンダとか。
チーム運営のオープン化2● 最近では、自分たちの手で日々のプロセスを変えるための変更コストにも気を使えるようになってきた。スクラムに関するドキュメントをGitHubから、scrapboxに移したことで簡単に変更できるようになった。● イノベーター(16)● やってみる(17)● みんなを巻き込む(33)
その他にチームとして取り組んだこと● チームランチ開始○ ブラウンバッグ・ミーティング(7)、何か食べながら(9)● 割れ窓タイムの導入○ ふりかえりの時間(5)、グループのアイデンティティ(13)、みんなを巻き込む(33)、お試し期間(47)● 基盤開発タイムの導入○ グループのアイデンティティ(13)、お試し期間(47)● タスク集中タイムの導入○ グループのアイデンティティ(13)、お試し期間(47)● モブレビュータイムの導入○ グループのアイデンティティ(13)、お試し期間(47)● 合宿をしてミッションの確認○ 場所重要(36)● 振り返りのやり方変更 KPT→YWT→KPT○ やってみる(17)
その他にチームとして取り組んだこと(昼会関連)● 昼会(デイリースクラム)にコンディション共有追加● 昼会(デイリースクラム)のファシリテーター持ち回り● 昼会(デイリースクラム)にミッションの確認コーナー追加● 昼会(デイリースクラム)で未アサインのタスク確認コーナー追加● 昼会(デイリースクラム)にその日時点のベロシティ確認コーナー追加(mackerelでグラフ！！)● 昼会(デイリースクラム)で各自のタスク進捗状況確認コーナー追加、お互いに進捗状況にツッコミを入れるようにした
その他にチームとして取り組んだこと(昼会関連)
昼会の変更をなぜ行ったのか● コンディション共有追加○ 振り返り時に体調不良者がそこそこいることがわかり、日々のコンディションもお互い気にしてみることにした● ファシリテーター持ち回り○ スクラムマスターのファシリテーション疲れ● ミッションの確認コーナー追加○ ミッション作ってみたので日々意識するようにしたかった● 未アサインのタスク確認コーナー追加○ 割り込みタスクアサインしないと進まないことが振り返りでわかったのでその対策● その日時点のベロシティ確認コーナー追加○ 進捗している/前進している感じを日々味わうため● 各自のタスク進捗状況確認コーナー追加、お互いに進捗状況にツッコミを入れるようにした○ 進捗が異常に悪いスプリントの振り返りで出た。止まってる状態を打破するための施策
昼会の変更を行った結果● メンバーそれぞれのコンディションに配慮しつつ仕事できるようになった● スクラムマスターが楽になり、次なる改善に向かえるようになった● ミッションを意識して仕事できるようになった● 割り込みタスクを処理できるようになった● ベロシティ増えてないことが検知できる● 進捗が止まったタスクに気が付き、相互にツッコミできるようになった
振り返りの変更をなぜ行ったのか● KPT→YWT→KPTと変更した● たぶん深い理由はなくKPTで始まった● YWTにした理由○ 新メンバーが他の人の作業がわからないという課題があり、スプリントでやったことを確認したかった○ Pばかり出てくると気が滅入ってくる● チームの改善がまったりしたと感じたためKPTに戻した○ Pを建設的に議論できるチーム状況になった○ Pが出てこないとキレがない。改善のネタが出てきにくい
振り返りの変更を行った結果● 他の人の作業内容がわからないことで困っていることがわかった● Pばかり出ても建設的な議論ができるようになった（と思う● やっぱりKPTの方が改善が進むと感じた
直面している課題● チームのプロジェクト進捗が停滞するときがあり、停滞の本当の原因にたどり着けているか不安がある● 長く取り掛かっているDoingタスクが片付かないときがある○ 他チームのプロダクトのリリースに関わる作業についてはコミュニケーションコストも高いし、完了タイミングもこちらではハンドリングしきれないとか● スプリントバックログアイテムの完了の定義が足りているのか、過剰なのかがタスク着手後にしか温度感がわからない
まとめ
まとめ● プロダクトオーナーいわく、改善するぞって意識がチームにできたのが一番よかった● スクラムマスターとしてもだいぶ良いチームになったと実感がある● 割り込みたくさんあって大変だけど、インクリメンタルにやる仕事の部分はスクラムのエッセンスを取り入れつつやれています● 変化をもたらすということが、スクラムマスターやプロダクトオーナー以外からも起こるようになってきた● とは言え悩みもあるのでお話させてください
まとめ業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。素早く変えてもし仮にダメだったら素早く戻せばよい。Songmuhttps://developer.hatenastaff.com/entry/2018/04/04/111410変化するには、こうした変化を受け入れる発言や態度とともに同僚、古参、上長とかからのフォロワーシップつまりやっていきに対するのっていきが重要だと感じている参考: https://speakerdeck.com/kentaro/the-secret-of-leadership-and-followership
各職種絶賛募集中https://hatenacorp.jp/recruit/career/
hokkai7go
suzukihoge
ivargrimstad
uhooi
chatwork_hr
manfredsteyer
star_zero
mascii
mkeeda
stanby_inc
rabbitmagician1
hsawaji
daisukeshinoku
chrislema
chriscoyier
colly
eileencodes
maggiecrowley
cromwellryan
akmur
shlominoach
lara
aki_iinuma
scottboms