はじめてのスクラムマスター振り返り

去年の12月から約半年間、はじめてスクラムマスターを担当したので振り返りです。 プロジェクトの概要や技術的なアレコレはQiitaのSIの現場のiOSアプリケーション開発 - Qiitaという記事にまとめてあります。

チーム構成

開発チーム

開発チームは5人で、(アンチパターンですが)自分がスクラムマスターと開発者を兼任していました。 5人中スクラム経験者は1人のみ、技術的にもiOS開発経験者が1人というメンバー構成で、若手中心(2年目2人、3年目1人)かつ開発経験浅めのメンバーが多いチームでした。

また、2スプリント目から1人追加になったり、他プロジェクトの対応で2人抜けて戻ってきたりと、プロジェクト途中での人数の増減が何回か発生しました。

f:id:tenten0213:20170605171349p:plain

スクラムマスター

スクラムマスターは自分が担当しました。 タイトルの通り、初めてのスクラムマスターでした。

2011年頃から社内のアジャイルサムライ読書会に参加したり、社外の勉強会に参加したりして興味を持って勉強していたので、なかなか感慨深いものがありました。 f:id:tenten0213:20170605142727p:plain

仕事でスクラムを採用するのは初めてでしたが、予備知識があったのでわりとスムーズに開始できたように思います。

プロジェクト開始直後の12月に認定スクラムマスター研修を受講し、認定スクラムマスターになりました。 プロジェクトの序盤での参加でしたが、課題に感じていたことや改善したい点を持って研修に参加することができ、学ぶことが多かったように思います。 プロジェクト中、何度も研修時のノートを開いて参考にしていました。

スクラムマスターと開発者の兼任

若手中心(2年目2人、3年目1人)かつ開発経験が浅いメンバーが多かったため、それなりに開発経験がある自分が開発者とスクラムマスターを兼任しました。

ずっと兼任していた訳ではなく、アーキテクチャが固まり、開発のリズムが出てきた4スプリント目以降はほとんどタスクを担当せず、ほぼスクラムマスターに専念(プロジェクトとは別の仕事もしていましたが)することができました。

兼任で苦労したのが、同じ開発者でもあるはずなのにスクラムマスターとして「開発チームとしてどう思う?チームとしてどうしたいの?」と自分が開発チームから抜けているような立ち位置から発言しなければならないことでした。

上記については、自身の立ち位置を明確にしてから話したり、スクラムマスターとして発言する際はチームの決定を左右するような発言は極力避け、チームに考えてもらうようにするなど工夫することで混乱を回避しました。 プロジェクト完了時の振り返りでもチームに混乱しなかったか確認しましたが、混乱するようなことは無かったようです。

ただ、個人的にはやりづらく、「大丈夫?混乱したりしない?」と頻繁にチームに確認していたように思います。

また、担当するタスクの量も専任の開発チームメンバーよりは少なくなるため、チームから不満がでないかヒヤヒヤしていました。 他の仕事や新卒のリクルータ、人事的なアレコレであまり時間が割けなかった時期もあったのですが、プロジェクトに関係ないことでも何をやっているかを表明し、透明性を保つように意識していました。

兼任でチームメンバーもやりにくい面が多々あったと思いますが、協力してくれ、理解を示してくれたメンバーに感謝です。

プロダクトオーナー

プロダクトオーナーは顧客側から出すことができず、社内からアサインしました。 基本的にはプロダクトオーナーに優先順位をつけてもらって開発を進めましたが、適宜顧客へのデモや優先順位の確認などを実施しました。

プロダクトオーナーの時間が取れなかったため、プロダクトバックログの作成、メンテナンスはすべて開発チームで行い、スプリントプランニング時にプロダクトオーナーに説明・合意するようにしていました。

プロダクトオーナーと他案件の兼任

プロダクトオーナーが他案件との掛け持ちや障害対応などで忙しく、スプリントプランニングやスプリントレビューの時間をなんとか確保できる、といった状況でした。

ただ、チームに対しては協力的で、必要な情報は声をかければすぐに貰えていました。 以下で書いてあるように、プロジェクト特性上あまり優先順位などが変化しなかったので、どうにかなったようにも思います。

顧客との関係

関係は悪くなかったですが、積極的に関わるような感じでもありませんでした。

プロジェクト序盤はあまりコミュニケーションが取れませんでしたが、一通りの動くものが出来てからはデモなどを通して関わる機会が増えたように思います。

今後どう顧客を巻き込んで行くかはスクラムマスターとしての課題だと思っています。

時系列での振り返り

2週間1スプリントで9スプリント実施しました。

もともとスケジュールが決まっていたプロジェクトだったので、予定通りのスプリントを実施して完了した感じですが、成果が出なければもっと早く中止になっていた可能性もありました。

プロジェクト開始前

初めてのアーキテクチャ開発プロセスということもあり、バタバタしていました。

アーキテクチャ周りはプライベートで勉強したり調べ物を予めしておいた内容をまとめ、唯一のiOS開発経験者にPoCをお願いし、アーキテクチャを固めていきました。

今まで担当してきた案件で作成していたようなプロジェクト計画に該当するものは、インセプションデッキとスプリント全体計画で代替しました。

お客様もあまり興味がなさそうだったので、設計書などの成果物はかなり省力化しています。

Qiitaの記事を書いた時点ではMarkdownで、と書いていましたが、途中からホワイトボードに書いた内容を写真で取ることで代用するようになりました。

プロジェクト序盤(1〜3スプリント) ⚡️

1スプリント目の開始翌日に、緊急で対応してほしいという案件の割り込みが入り、いきなり開発チームから自分と唯一のiOS開発者が一旦離脱という羽目に。

スクラムマスターとしてはチームを守らなければならないのですが、なかなか難しいです…

スタートを切った直後のタイミングだったので、再度スプリントプランニングを行い、縮小した体制でリスタートしました。 しかし、1スプリント目は開発経験の浅いメンバーのみで実施したため、成果はほぼゼロという状態になってしまいました。

課題としては、設計・実装スキル不足、ストーリーの設計〜実装を1人で担当することによる属人化といった感じでした。

このタイミングで認定スクラムマスター研修を受講しています。

チームへの正式な復帰は3スプリント目からだったのですが、研修で"スプリントプランニング中に全員で設計を行い、1h以下のタスクになるように詳細化する“という方法を学んだので、チームに取り入れてみました。これがかなり有効でした。

2スプリント目ではまだチームに復帰していなかったのですがスプリントプランニングには参加することにし、自分がホワイトボードの前で実際に設計を行ってみせ、タスクの詳細化を行うことで設計の考え方やポイントなどを伝えることで設計スキル不足を補いました。

設計はかなり詳細に行い、必要に応じてコードを書いて挙動を確かめたりもしていたので相当時間を使っていました。ちなみに、最長340分スプリントプランニングを行っていたこともあります。

プランニングに時間がかかるのですが、その後のタスク消化は迷うことなく進めることができるようになりました。

また、全員の前で設計を行いタスクを詳細化することで全員がどのタスクでも実施することができるようになり、朝会(デイリースクラム)でタスクをプルできるようになりました。

実装スキル不足はチームでSwiftの勉強会を行ったり、ペアプロを行うことで解消していきました。

チームのルールとして"同じストーリーのタスクは連続で実施しない" などを定義して、属人化を防ぐ工夫も行いました。(やり過ぎると生産性が上がらないのでほどほどに)

他には"15分ルール"、"ボーイスカウトルール"など自分たちで考え、ルールを導入していきました。

ルールの中には途中で外したものもあり、適宜チームに合わせて選択するようにしていました。

プロジェクト中盤(4〜6スプリント) ⛅️

メンバーのアーキテクチャへの理解が深まってきて開発のリズムが出てきたので、少しづつ"タイムボックス"や"Doneの定義"など厳しく守ってもらうようにしていきました。

朝会や振り返りが長引きがちだったので、朝会は15分、振り返りは1.5時間のタイムボックスをしっかり守るように伝えました。 “会議には必ずファシリテーターとタイムキーパーを配置する"というルールが追加になりました。

また、ストーリーやタスクによって完了条件が曖昧なものがあり、メンバー毎の認識齟齬によるタスクの漏れが出ていました。 これに対してはストーリーに前提条件や完了条件を記載し、必ずレビューをしてもらうようにし、対策しました。

4スプリント目ではプランニング時に約束したストーリーが実施できる状態でなかったことがスプリント開始後にわかり、プロダクトオーナーに謝ってストーリーを入れ替えさせてもらいました。これはプロダクトバックログのメンテナンスが出来ていなかったことが原因だったので、このスプリント以降プロダクトバックログリファインメントを実施するようになりました。

スクラムのプラクティスやルールを一気に全て守ってもらうのではなく、一歩一歩確実に理解を深めてもらうようにしました。

特に、安全に失敗させ、自分たちで考えて改善してもらうように意識しました。

プロジェクト終盤(7〜9スプリント) 🌞

ここまでのスプリントは開発者とスクラムマスターの兼任、スクラムマスターとしてのティーチングという役割を担ってきましたが、6スプリント終了時点でかなり自律的なチームになっていました。 なので、7〜9スプリント目では困ったときに頼ってもらう程度の関わりに抑え、自分たちで考えて進めてもらいました。

関わりを薄くしても自分たちで改善を続けベロシティを上げていたのでかなり頼もしく、安心して任せることができました。

その他

スキルマップの導入

以下のようなスキルマップを作成し、得意な人と苦手な人でペアプロやペア調査などを行うことでチーム全体の戦力の底上げをしました。 また、習得したいスキルに印が付いているものに関連するタスクは優先的にその人に担当してもらうようにし、個人のキャリアや志向も重視するようにしました。

http://www.ryuzee.com/contents/blog/images/7065/01.png スキルマップ作成のすすめ | Ryuzee.com

特に2年目の2人には、初めてお客様との打ち合わせや説明する機会を設けることができ、かなり成長してもらうことが出来たと思います。 上司からも半期前と比べて見違えるようだと言ってもらえたので、かなり嬉しかったです。

ニワトリとブタ

タイトルはスクラムで有名な寓話です。自分のチームでも意思決定権のないお客様の意見に振り回され、計画変更を余儀なくされる事態が発生しました。 立場としてはお客様なので言っていることを信じて要望に応えようとしてしまいがちなのですが、お客様の中でも意思統一が出来ていない場合があります。

お客様の総意なのか、意思決定権をもっているお客様の意見はどうなのかを確認する必要があることを身をもって学ぶことができました…

振り返り

振り返りはKPTA で行いました。 KPTだとTryに上がったものの実施されない、みたいなことが経験上多かったのでKPTAを採用し、確実に改善Actionが実施されるようにしました。

以下は9スプリントで出たKPTAの数です。

  • KEEP: 92
  • PROBLEM: 153
  • TRY: 83
  • ACTION: 71

細かいものも出ていましたが、かなりの数の改善が実施されました。

はじめてのスクラムマスターをやるにあたり参考にしたもの

まとめ

まとめてブログに書こうとしたら膨大な量になってしまいました。 もう少し短いスパンでアウトプットしないとダメですね…

はじめてのスクラムマスターとしての経験を振り返ってみました。 はじめてということもあり探り探りでしたが、自律的で自慢できるチームにすることができました。

今後は他チームや別部門など組織を跨いだ影響を与えていくこと、お客様を巻き込んで進めていくことが課題だと思っているので、そこらへんに取り組んでいこうと思います。