スクラムマスターロールプレイ。
筆者がtwitter上でフォローしている方の中に、吉羽龍太郎氏がいます。
氏のtwitter上での呟きで、スクラムマスターロールプレイなるスライドが公開されていました。
内容を拝見してみると、まあ表題の通り、開発スタイルとしてスクラムを適用していることが前提にはなっている
のですが、必ずしも限定しなくても実務ケースでのシミュレーションとして使えるのでは?
のですが、必ずしも限定しなくても実務ケースでのシミュレーションとして使えるのでは?
.....と考えて、6月の定例会の中で60分ほど枠を取って実施してみました。
(これまでにスクラム/アジャイル関係の勉強会やワークショップなど、幾つかやって来てましたし...)
(これまでにスクラム/アジャイル関係の勉強会やワークショップなど、幾つかやって来てましたし...)
ちなみに、同日の出席者の中で、スクラムを実務で適用していた経験者は1人のみでした。
研修中の新人(第二新卒的な人)もいるので、
同じく吉羽氏の作成されたスクラム概説図を使わせて戴き、用語などの要点のみ"おさらい"を最初に行いました。
同じく吉羽氏の作成されたスクラム概説図を使わせて戴き、用語などの要点のみ"おさらい"を最初に行いました。
60分の枠の中で、最初の数分を上記のおさらいに充て、残りをディスカッション形式にしてみました。
保険として?、反応が悪い場合に備えて、自分でもどんな回答が考えられるか?、を
可能な限り挙げておいてみました。
場が余りにも展開しないようなら、"例えば"という形で小出しにしてみようかな?、というつもりで.....
可能な限り挙げておいてみました。
場が余りにも展開しないようなら、"例えば"という形で小出しにしてみようかな?、というつもりで.....
結果、話題に挙げられたのは最初のスライドから3つ。
スライドの p.5:"常態的にスプリントバックログが消化し切れない、何故か?、どうする?" に対しては、
おおよそ下記のような発言がありました。
おおよそ下記のような発言がありました。
・スプリントの振返りの場で、全員で考える。
・"完了"としているストーリーの精度も疑問がある。完成の判定基準に問題が有るのでは?
・各ストーリー/タスクに対しての見積が甘く、しかも学習&改善がなされていない。
・他プロジェクト等からの頻繁な割込みが有るのかも?
⇒割込みを抑えられえるなら抑える
⇒割込み対応要員を分けてしまう。←の人数は、チームメンバー数としてカウントしない。
⇒残業対応で賄うことはしない!
⇒プロダクトバックログの全数消化は無理になる、或いはプロジェクト終了日の延期の了承をもらう。
・スプリントバックログの各々の単位が大き過ぎるのでは?、見積精度が下がるのを避けられない
⇒粒度を小さく、分割する
・メンバー間の繋がりが弱いのでは?
⇒"個人の集まり"ではなく、"チーム"としてスプリントの完遂を担保する意識を共有できるように
・勤怠が悪いのでは?
・"完了"としているストーリーの精度も疑問がある。完成の判定基準に問題が有るのでは?
・各ストーリー/タスクに対しての見積が甘く、しかも学習&改善がなされていない。
・他プロジェクト等からの頻繁な割込みが有るのかも?
⇒割込みを抑えられえるなら抑える
⇒割込み対応要員を分けてしまう。←の人数は、チームメンバー数としてカウントしない。
⇒残業対応で賄うことはしない!
⇒プロダクトバックログの全数消化は無理になる、或いはプロジェクト終了日の延期の了承をもらう。
・スプリントバックログの各々の単位が大き過ぎるのでは?、見積精度が下がるのを避けられない
⇒粒度を小さく、分割する
・メンバー間の繋がりが弱いのでは?
⇒"個人の集まり"ではなく、"チーム"としてスプリントの完遂を担保する意識を共有できるように
・勤怠が悪いのでは?
上記に出なかったもので、筆者の方で想定していたのは下記のようなものでした。
・ストーリーの仕様が不明確(確認に時間が掛かる・矛盾が見付かる等)、プロダクトのinputとして不適切?
・メンバー構成が拙い(スキル問題)?
・スクラムの各種プラクティスの理解不足?、或いは手段が目的化している?
・メンバー中の何名かが?プロジェクトを掛け持ちしている?
・タスクへの分解の仕方、タスクの取り方が拙い?
⇒複数タスクが同時にDoing(仕掛り中)になると、生産性・品質は低下する。
・メンバー構成が拙い(スキル問題)?
・スクラムの各種プラクティスの理解不足?、或いは手段が目的化している?
・メンバー中の何名かが?プロジェクトを掛け持ちしている?
・タスクへの分解の仕方、タスクの取り方が拙い?
⇒複数タスクが同時にDoing(仕掛り中)になると、生産性・品質は低下する。
これら↑に関しても、軽く触れてみました。
で、3つの課題に関してディスカッションした後に、今回のセッションに関しての振返りを行ってみました。
Problem:
・スクラムに関して(自分達が)実戦的な理解が無さ過ぎてイメージが湧かない。分からない。
・やっぱり回答例(スクラム的に望ましい現実的な例)が欲しい!
・スクラムに関して(自分達が)実戦的な理解が無さ過ぎてイメージが湧かない。分からない。
・やっぱり回答例(スクラム的に望ましい現実的な例)が欲しい!
Try:
・出題されたPOが余りに無能過ぎるので、そのPOのペルソナを作ってみたい。(恐らく半分以上は怒りか?)
・スクラム経験者のワークを見学してみたい。
・POとしての社内的な教育機会が有るべきでは?!
・出題されたPOが余りに無能過ぎるので、そのPOのペルソナを作ってみたい。(恐らく半分以上は怒りか?)
・スクラム経験者のワークを見学してみたい。
・POとしての社内的な教育機会が有るべきでは?!
Keepに分類できそうな発言は残念ながら無かったのですが、
スクラムの実務経験が無いメンバーが殆どだった割には、ある程度のディスカッションにはなったように
思うのだけれど...手前みそでしょうかね...。
スクラムの実務経験が無いメンバーが殆どだった割には、ある程度のディスカッションにはなったように
思うのだけれど...手前みそでしょうかね...。
なお、当"ロールプレイ"を実施してみよう!、と判断した筆者の反省としては、
・案の定ではあったが、実戦経験が圧倒的に足りない...
⇒機会が有れば、請負・自社内で作業がほぼ完結する案件で実践してみたい...
・せめて事前にお題を公開しておくべきだった、かも...(タイトルしか事前告知していなかった)
・案の定ではあったが、実戦経験が圧倒的に足りない...
⇒機会が有れば、請負・自社内で作業がほぼ完結する案件で実践してみたい...
・せめて事前にお題を公開しておくべきだった、かも...(タイトルしか事前告知していなかった)
最後に、これは言い訳がましくなるのですが、
今回の定例会には、技術メンバーの半数未満しか出席していませんでした。
(繁忙期の大所帯プロジェクトが複数、ピーク状態だったため)
今回の定例会には、技術メンバーの半数未満しか出席していませんでした。
(繁忙期の大所帯プロジェクトが複数、ピーク状態だったため)
先月も同様の状態で、5月度は定例会自体を開催中止にしたんです。
さすがに2ヵ月連続で中止はしたくなかったので、コンテンツを少人数でも展開できそうなモノに入れ替えて実施しました。
("実プロジェクトで利用した技術ベースでのUI・UXデモ"も予定していたのですが、勿体ないので次月に繰り越してもらいました...)
("実プロジェクトで利用した技術ベースでのUI・UXデモ"も予定していたのですが、勿体ないので次月に繰り越してもらいました...)
7月度の出席者は改善されるはず。
...と言うより、改善すべく、"定例会自体の開催時間帯を見直すべき!"、との案が出されました。
...と言うより、改善すべく、"定例会自体の開催時間帯を見直すべき!"、との案が出されました。
小さなお子さんの子育て中のお母さんエンジニアが何名かいて、常態的に出席出来ていないという問題点への改善も必要という事です。
現在、Googleフォームベースでのアンケートを配信し終わり、回答待ちの状態です。
| 固定リンク
「定例会、勉強会など」カテゴリの記事
- 最悪トラベル・ワークショップ。(2018.09.19)
- "ペルソナ"設定ワーク(後半戦)(2018.04.24)
- "ペルソナ"設定ワークをやってみた!(2018.03.13)
- OKRワークをやってみた!(2018.01.15)
- SESだけどリーンキャンバスで顧客のビジネスを分析してみた!(2017.12.20)
コメント