はじめに
本記事は、スクラムプロセスに慣れてきた社内メンバー向けの簡単なディスカッション資料です。
Agenda
- あなたは今「アジャイル」な状態なのか？
- 困ってそうなコトと個人的アイデア
- 振り返りのマンネリ化
- スクラムマスターチェックリスト
- みんなでディスカッション
今「アジャイル」な状態なのか？
- 「スクラム」は目的ではない。あくまで、「手段」。
- なんの手段だったのか？「アジャイル」を実現する手段だったはず。
- なぜ「アジャイル」を実現したいのか？そこに「課題」があったから。
今も「課題」がどんどん解消されている状態ですか？
参考：結果的にスクラムになってる！なのがいいと思う！ #RSGT2017
参考：スクラムとは何か？〜Certified ScrumMaster 研修を受けて〜
困ってそうなコトと個人的アイデア
- 振り返りについて：アジャイルレトロスペクティブ
- スクラムマスターチェックリストってのがあるよ
振り返りについて：アジャイルレトロスペクティブ
アジャイルレ・トロスペクティブという本がある。
各プロセスでどのようなアクティビティを行なうかについては、いろんなアイデアが乗ってるのでお薦めです。
紹介も兼ねて、ちょっとだけ紹介します。
アジャイルレトロスペクティブでは、具体的に以下プロセスで行なうと良いよ！って書いてあります。
- 場を設定する
- データを収集する
- アイデアを出す
- 何をスべきか決定する
- 終了する
場を設定する
- アイスブレイク
- 誰もが話しやすい空気を出す
- タイムボックス・目標を説明
- 何について振り返るのかを決める：例えば、「このスプリントは不具合が多かったので、開発プロセスついて振り返る」など。
- チームの約束を確認する
- 心理的安全に関する約束が多いが、心理的安全に関連する必要はない
データを収集する
「意見・気づき」を支える「事実」を捉えるために、データを収集する。
「意見・気づき」を元にアクションを決めると、本質的な問題が解決しない。
アイデアを出す
- データを元にアイデアを出す
- 思いつきのアイデアはだいたいダメなので、どんなに「イケてる！」と思っても、分析的に考える。（事実と照らしてみる）
何をスべきか決定する
SMARTなアクションであること
- Specific：何をするかが具体的であること
- Measurable：完了条件が測定可能であること
- Achivable：達成可能であること
- Relevant：目標達成に関係があること（を説明できること）
- Time-boxed：「時間」で見積もりが行われていること。「日」レベルでは大きい。
実行に移すアクションは選別する（全部はやらない）
終了する
- 議事を残す
- レトロスペクティブ自体を振り返る
- 圧倒的感謝！
スクラムマスターチェックリスト
本来は、スクラムマスターが開発チームの状態をチェックしたりするものですが、開発チーム自身が使っても良いと思います。
参考：スクラムマスターチェックリスト
（私が翻訳しました！褒めて！）
チェックリストから「開発チーム向けのチェック項目」を抜粋してみました。確認してみてください。
- ☐ スプリントプランニングのタスクに集中できてますか？（チームは”フロー状態”にありますか？）
- ☐ チームメンバーはお互いが好きで、一緒にバカができて、お互いの成功を祝っていますか？
- ☐ チームメンバーはお互いに、高いレベルで責任を持ち、成長を目指して挑戦していますか？
- ☐ 議論するのを極端に不快に思うあまり、議論を避けているような問題はありますか？
- ☐ スプリントレトロスペクティブにおいて、いろんな場所ややり方を試しましたか？
- ☐ チームはスプリントゴールをずっと大切にしてきましたか？ もしかしたら、このスプリントでコミットされたPBIの受け入れ基準の見直しとして、スプリント内点検を実施しても良いかもしれません。
- ☐ スプリントのタスクボードはチームが実際に行っていることを反映していますか？ 一日では終わらないタスクや隠されたタスクの「ダークマター」に注意してください。 スプリントゴールに関連しないタスクは、スプリントゴールに対する障害です。
- ☐ あなたのチームは、出荷可能なプロダクトインクリメントを構築するのに十分なスキルを備えた3～9人のメンバーで構成されていますか？
- ☐ あなたのチームのタスクボードは最新の状態になっていますか？
- ☐ チームが自己管理してる成果物は、チームから見えるようになっていますか？チームにとって使いやすい状態ですか？
- ☐ これらの成果物は、チーム外のお節介焼き達から保護されていますか？ チーム外の人による過度なチェックは、チーム内部の透明性と自己管理を妨げる可能性があります。
- ☐ チームメンバーは自主的にタスクを行なっていますか？
- ☐ 技術的負債を返済する必要性が”Done”の定義に明示的に示されており、徐々にコードをより楽しい場所にできていますか？
- ☐ チームメンバーは、合意された作業（テスト、ユーザードキュメントなど）のすべての側面を包括的に担当するように、チームルームのドアにチームの役割を張り出してますか？
チェックリストには、「プロダクトオーナー」「開発プロセス」「所属する組織」などを対象にしたチェック項目もあるので、確認してみてください。
最後に
気づきのインプットになりそうな情報提供はここらへんにします。
後はみんなでディスカッションしましょう。
以上です。