こんばんは。
某広告サービスでスクラムマスターを担当していたりょーまです。
私事ですが、先日夏期休暇を頂きハワイに出かけました。
滞在先のホテルがまさかのストライキ。。
暑い中、朝から晩まで皆絶えず声を出し続けるあの一体感は何なんだ。
素晴らしいチームワークを見させてもらった。
毎日自分で部屋の清掃をした件は水に流すことにします。
悔しい。
さて、今回はスクラム体制が出来上がるまでのタイムラインのお話です。
スクラム採用から約一年半が経ち、大分チームとして確立してきました。
実際にどのような流れでそうなったのかをスクラムマスター目線で簡単に紹介します。
具体的なやり方やツール、というよりは考え方とか気持ち的な話です。
スクラムって
何それって方のために。
複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。(スクラムガイド引用) https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
なんだかすごそうですね。
プロダクト開発のためのイイ感じな何かと認識して頂ければ！
もう少し詳しくって方はまずは上記のスクラムガイドを3周くらい読んでみることをお勧めします。
タイムライン
ではポイント毎に見ていきます
チームJOIN
スクラム体制を確立する
それが私の至上命題でした。
※大目的はチームとしての生産性の向上です。
当時は私自身もスクラムをするのがほぼ初めてで、しかも元々在籍していたチームとは別チームへの合流。大きなチャレンジでした。
まずは現状分析
最初に始めたこと、それはチームの現状分析です。
1ヶ月程はスクラムどうこうとは言わず、現状のチームとじっくりと向き合うことにしました。
主にやったことは、1on1と既存会議への参加です。
1on1~2
今何を思って業務に取り組んでいるのか、不満や満足、得意や不得意、個人にフォーカスしたヒアリングを行いました。
少しアレンジして1on2も実施しました。メンバー同士で対話が発生するので、気付きも多くオススメの手法です。
観察会議
JOIN当初は会議では殆ど発言せず、徹底して観察に回りました。
素のチームポテンシャルを見たかったためです。本当にお地蔵さんだったかもしれません笑。
話す前に聴く
このフェーズですごく大事にした姿勢があります。
それは「聴く」ことです。傾聴とも言いますね。
仕事をする上で問題解決が重要なのは当然です。しかしながら、いきなりあれだこれだ俺はこうしたいんだーって人に、周りはついてきません。
分析という目的を果たしつつも、しっかりと聴ききることで信頼関係の構築を図りました。
分析結果(一部)
(ちなみにこのチーム、私が来る以前にスクラム自体には取り組んでいました。)
- そもそもスクラムについてメンバーがあまりわかっていない
- ロールが不透明。SMとPOを兼務している
- メンバー間のスキル差(依存)が激しい
- 対話が成立していない(話についていけていない人がいる)
- 会議のリスケ、消化不良が多い
- なんか色んなこと(複数プロダクト)やっている
- 仲はとても良い
- 信頼関係はすでに出来てる
- 皆ポジティブ
このような結果となりました。
勉強&勉強
スクラムについての知識がほぼ0だったので
本
スクラムやアジャイル関連の書籍を10冊程度読みました(読書嫌いだったのですごく頑張った方笑)。
実践と知識は別と言いますが、実践の効果を促進させるために知識は必要不可欠だと思います。また、自己完結できる事なのでおすすめです。
セミナー
講義系のものやディスカッション系のもの、今でも月1~2回は参加してます。
知識の習得もそうですが、似たような仲間に出会えることが大きいです。
悩みや考えを共有することで、本では知り得ない事にも出会えます。
プランを立てる
分析がある程度済んだところで、スクラム確立までのプランを立てました。
まずは軸を作ろうと思い、以下のような10の観点を立ててみました。スクラム確立をゴールとしたKPIとも取れますね。
- 全メンバーがスクラムを理解している
- ロールが明確になっている
- ステークホルダーが明確になっている
- メンバー間のスキル差が少ない
- 全メンバーが対等である
- チームの目的･方向性が一致している
- タイムボックスを守っている
- 1チーム1プロダクトである
- スクラムを深く理解し、ファシリテートできるSMがいる
- ビジネスに限らず、エンジニアの事を良く理解しているPOがいる
それぞれのアクションプランを立てました。
なんか上手くいかない
スクラム学習を終え、皆ある程度理解した。プランも立てた。
いざスクラム！！
と思いきや・・・
終わりの見えないプランニング
見積もりいつまでやるの。もう夜だよ。。
問題提起だけの振り返り
それ確かに良くないね！直したい！いつかやろう！！
不安定なベロシティ
ベロシティグラフ凸凹すぎでしょ。。
圧倒的未達のスプリント
ごめんなさい。
これ、スクラム経験者は皆頷いてくれると信じています笑
本当に一筋縄では行きません。
理解は容易、習得は困難とはこういうことなんだと。
スクラムの学習を終え、チーム全体的にモチベが上がっていたので、このなんか上手くいかない期は結構辛かったですね。
※現状はいずれも改善されてます。
失敗に慣れさせる
語弊を招くかもしれないワードですが、これはいい意味での慣れです。
人間は変化が嫌い
そもそも論、人間は今までのやり方を変えるという行為を本能的に嫌います。
その変化がプラスをもたらす可能性があったとしても、マイナスを生み出す可能性に怯えてしまうのです。
ってなんかの本で書いてありました。
つまり、すぐには上手く行かないという事。
失敗したらやり直せばいい
失敗したという事実を認め、じゃあどうすれば良いのかと考えられるチームは強いです。
そのためにした事主に二つ。
声にする
「失敗しても良いから」「ダメだったら違う方法考えよう」
声に出し、言い続ける事が一番伝わります。
成功イメージを絶やさない
何でもかんでもがむしゃらにやればいいってものではないです。
それをする事でこんな良いことがあるんだよ！って事を示し続けます。
改善サイクルが出来てくる
失敗に慣れ、学ぶ習慣が出来るとそれは改善に繋がります。
アジャイル開発において改善サイクルは肝といっても過言でないぐらい大事な事ですね。
振り返りは手段、改善が目的
改善のために重要なアクションは振り返りです。
KPTやYWTといったテンプレートは知っている方も多いでしょう。
色々な方法はありますが、改善につながれば何でも良いと思います。
振り返りのポイントを三つ紹介します
人ではなく事
誰がやったのかではなく、何故そうなったのかに着目する。
事をチームで共有の持ち物にしましょう。
誰かがミスをした。本当にその人だけの責任ですか？
事に着目する事で、チームに心理的安全性が産まれ、意見交換も活発化してきます。
事実、問題、手段を切り分ける
それを問題と認めていないのに、「こういう方法で解決できるんだよ」って言われても困りますよね。
これ、ダメな会議で良くある現象だと思います。
何かしらの出来事があり、それが損失を産んだ時(リスク含む)初めて問題となり、解決の手段を考えます。
話の象限を明確に分けると良いと思います。(ファシリテータの腕の見せ所)
最初の一歩を決める
完璧な計画はすぐに立てられません。
まず最初に何をやるべきか。これだけで良いのでチームでコミットしましょう。
小さく、具体的にがポイントです。
デリゲーション
(権限委譲のことをデリゲーションと言います。)
分析にある、メンバー間のスキル差が少ないが我々のチームでは大きな課題となってました。
プログラミング、マネジメント、ディレクション、デザイン、ファシリテーション、etc
誰かにしかできない事は、チームプレーをするにあたって基本障壁となります。
積極的にデリゲーションを行うことで、チームとしてバランスよくタスク消化できるようにしました。
T字型組織
スキルの幅と深さを表したTのようなスキルセットを持つことがスクラムチームの理想として挙げられます。
チームの技術リーダーと協力し、まずはこの幅を十分にする事を目標に、皆が出来るべき事をスキルマップとして明確に定義しました。
そして、ストーリーの担当を出来ない事、知らない事を積極的に取っていく方針にしました。
今では誰でも殆どのタスクを担当できるようなチームになりました。
デリゲーションポーカー
権限委譲は0,1ではありません。
全部任せる、任せるけどレビューする、任せないけど相談に乗って欲しい、任せない。
このように、権限委譲の中でもいくつか選択の幅が存在します。
それをディスカッションするときに有用なのがデリゲーションポーカーです。
詳細は割愛しますが、ゲーム的に権限委譲の話をできるのでお勧めです。
さいごに
本記事冒頭：スクラムマスターを担当していたりょーまです。
次回「僕がスクラムマスターを辞めたワケ」
※12月のアドベントカレンダー投稿予定
