SRE兼スクラムマスターのブログ

チーム開発が好きなエンジニアブログです。検証した技術やチームの取り組みを書いていきます。

Agile Talks vol.1に参加した話:ふりかえり 「チームは問題解決を見てはいけない」について考える

Agile Talks vol.1に参加してきました。 楽しい話がたくさん聞けたので自分の頭の中を整理するためにも メモを記録に残そうと思います。 agiletalks.connpass.com

Agile Talks とは?

@teyamaguさんが企画しているです。 ただただ@teyamaguさんが聞きたい講演や参加したいワークショップを聞く/参加する会で XP祭りでもRSGTでも経験できない…かもしれない貴重かつほっこりする会だと認識してます。

コンテンツ

今回のコンテンツは大規模アジャイルとレトロスペクティブのお話でした。

1.「アジャイルコーチから見たScaled Agile Method.. ~SAFe and LeSSから学ぶ勘所~」

www.slideshare.net

Masataka Mizunoさんが司会を務めてくださり SAFe派のIwao HaradaさんとLeSS派のTakao Kimuraさんが原理・原則を紹介しつつ 互いの相違点や類似点を話していく会でした。

SAFeの話

メモ・感想

  • チーム毎にプロダクトバックログがある
  • Release Trainに全てのチームを巻き込む? -> Train everyone, Launch Train
  • 小さなスプリントが上位の大きなスプリントを回していく?
  • 歯車みたいなイメージ?
  • デリバリーまでのLTは長いが、小まめにチーム間でsyncするのが重要
  • 手戻りのムダを軽減できる
  • 始めるにあたって様々な認定セミナーがある
  • お金があったら受けられそう
  • PI 計画を立ててScrum をやっていく
  • PI 計画はとても熱気があり、各チームが集まって2日くらいかけてるっぽい

LeSSの話

メモ・感想

  • 大規模スクラム Large-Scale Scrum(LeSS)
  • 原理・原則が存在しておりLeSSの中心となる、複数チームが存在するのでルールを効率的に適応するガイドが存在する
  • 大規模スクラムスクラムである、なので基本的にスクラムと同じ考え方である
    • LeSSでは従来のスクラム同様にバランスを取っている
      • 抽象的な原理・原則
      • 具体的なプラクティス
  • プロダクトオーナーは1人 <- これはけっこう驚いた
    • 大規模なため全てのアイテム詳細を把握するのは不可能
    • 詳細よりも優先順位の明確化に重きを置く
    • プロダクトバックログは全チーム共有である
  • スクラムの開始と終了は全てのチームで共通である
  • 広く浅くよりも狭く深く
  • ボトムアップトップダウンが大切
  • 最小限で始める
    • そぎ落としではなくスケールアップ
  • スプリントプランニング
    • 1部:代表者で集まる
    • 2部:全員で集まる

所感

大規模スクラムについて話を聞くのが初めてだったので、初めましてな言葉がたくさんでした。 ひとまず、SAFeにせよLeSSにせよ大規模になってくると、リーダーや上級マネジメント層が重要な役割を担っている。 よくスクラムでは自己組織化されたチームという表現があるが、大規模アジャイルの場合は、横連携であったり強力な推進力がないと 難しいのだろうなと感じました。チームの自己組織化はチームメンバーの問題であり、横連携とかサイロになりがちな部分は全体像を見渡す リーダーとかが重要なのだと認識しました。 まだまだ、大規模アジャイルについて学習していないので、これを機にちゃんと学習してみようと思います。

2. 「レトロ・オブ・ザ・デッド ~ゾンビレトロしてたチームを2年間観察していたら、良い振り返りをするようになったので、その活動報告~」 github.com

アジャイルコーチとして2年間同じチームを見続けているRyo Tanakaさんのお話。 自己紹介の写真は有料の写真なので貴重らしいです。 チームを観察して気づいたことやレトロスペクティブについての考えが聞けた会でした。

レトロ・オブ・ザ・デッド

メモ・感想

  • 良いレトロって何?
  • 楽しい
  • 実験的
  • 継続的
  • 投資的
  • 長期的視野
  • 長期的ゴールと短期的ゴールが完全に乖離している時に、 長期的ゴールに対するアクションがあるといい
  • アンチパターンなレトロは?
  • 自傷的にチームがチームを良くないと評価し続けていている
    • 常に反省会になってるレトロとか?
  • チームで起きた問題しか興味がなく、良かったことは良かったね〜だけ。
    • 良かったことに対する分析がない
    • 学びを見落としているとか
  • とりあえず出てきた、技術的問題にしか興味がない
    • これはまだ体験したことがない
  • そもそも振り返れない
    • チームの最初にあったかも
  • 自己肯定的チーム
  • 良いこと・悪いことを認めること
  • 自分たちが成長できることを肯定していること

所感

レトロは普段から自分たちもやっていることなので共感できる部分や参考になることが多かったです。 特に「自己肯定的チーム」は大事にしている考えだったのですが、言語化されていて、 これからたくさん使っていきたいフレーズでした。 他の学びとしては、「帆船ふりかえり」は面白そうなので自分のチームでも取り組んでみようと思います。

最後に

チームは問題解決を見てはいけない

Ryo Tanakaさんのお話の中で「チームは問題解決を見てはいけない」という言葉があり どういうことなのか考えてみてくださいという話があったので、自分なりに考えてみました。

このフレーズを見たときに直感的に思い浮かんだことは、目先の問題であったり長期的な問題にとらわれるのではなく あくまで、チームは「ゴール」を見据えて進むことが重要という意味ではないのかと認識しました。

なぜならば、目先の問題は人や役割によって見えるものが異なるので、チームが問題解決に注力してしまうと 方向性がぶれる危険があるからだと考えています。 その点、「ゴール」に関しては人や役割が異なっていようが、同じものを目指しているはずなので「ゴール」を見据えて 行動することで、常にベクトルの方向が揃うから、気が付いたら何やっているだっけ?状態にならずに済むような気がしました。

このような状態を作るためによくインセプションデッキなどの手法が使われると思いますが チームでも同じようにインセプションデッキを作って、常に向きなおれる準備をすることが大切なのかな?

なんかうまくまとまっていない気もしますが、個人的にはこんな意見です。 他に意見があればぜひ共有いただきたいです。