天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

「#RSGT2022 プレゼンを同時視聴したり、アジャイル系の相談したり」に参加してきた

distributed-agile-team.connpass.com

こちらに参加してきたので、会の様子と感想を書いていきます。

Leading Skilled Agile Teams: Investing in Team Outcomes with the Agile FluencyR Modelを見ていく

youtu.be

まずはこちらを見ていきました。以下のような感想が挙がっていました。

  • 自然となってしまうっていう意味ではパタンっぽさがあるな
  • deliverしなきゃしなきゃって意識してたから立ち返ってfocusingできているか確認しなくては
  • 最終的には5年くらいのスパンって長いなぁ。めったにそんな長いチームないぞ
  • managersってことはこのモデルは結構上の人目線?
  • fluency、定義が上手く理解出来ていない、自然な流れができてるかという話…?
  • チームのマネージャーって意味なんですかね
  • fluencyは障壁がない的な解釈してます
  • based on resultsって大事だよなぁ。この場合のresultsって、outcomeですよね
  • デブサミのちえみ先生たちの発表とかも踏まえて、チームの成長とかを聞くとすぐに植物的なイメージが浮かぶ
  • 学ぶって自然とできる人とできない人がいると思いますけど何が違うんですかね
  • 1日目のkeynoteとこの2日目のkeynoteで"leader"の意味が若干違ったんですよね
  • 経営レベルで考えるとどうなんだっけ?っていうのはあまり言及がなかったね。
  • RSGTで明確に概念が変わった2単語はleaderとmanagerです
  • 学ぶことが自然にできてるように見える人も一定努力してるかもしれないと思いました
  • ほんとに自然にできてる人は、努力が習慣化したか、自分は無知なことを知っているような気がします(無知の知)
  • Zoom背景じゃなくてリアル障子なのが良かったってコメントあったの思い出しました
  • なんか驕ってない人ほど自然に学べてる気がします
  • 今の自分の周りには「みんなで学んでいこうね」ってマインドの人が多いからコンフォートゾーンど真ん中なんだけど、そうじゃないコミュニティやチームとかってありますよねー
  • 強要したくないから、自分の中でどういう落とし所にしたら良いのかっていう。
    あとは、自分ごと化をしてないと学びが自分とは関係ないとなって、学べなさそう…?
  • 改めて聞いて思ったのは、入門的な話としてはいいんだけど、で、具体的にどうするんだっけ?っていう話としてはイマイチな感じがするのが当日おもったことだったなー。スクラムマスター研修の次にこのキーノートを軽くきくのはいいなーっておもえる。
  • 結構抽象的な、マインドセット的な感じですよね
  • 言われてみれば具体的にすべきことがよくわからなかった(そもそも内容理解がたいしてできてないのもある)
  • この形への抽象化はひつようだったのかよくわからない。というのが当日おもったことだったな。
  • optimizing以降はまだ自分ごとにできてないのですが、enPiTのメンターやってたときはdeliverがどうの言う前にまずチームとして開発に集中できているのかを見なきゃなって思いました。
  • 30分でわかるアジャイルチームジャーニー。みたいなセッションとしてはいいんだけど、これがなにか偉大な話かと期待して聞いてしまったのが自分が当日困惑した理由だなー。
  • focusingを、集中して意欲と当事者意識を持って取り組むことだと認識しているけど、であればまず初めにとても大事であるということに共感できる
  • いわゆるやる気みたいなものを、最初少なくともチームメンバーの一定割合以上が、持ってないと続かなさそう
  • Agile Fluency Modelいまいちよくわからないなぁ。驚きがないというか、そういうのもあるよね、くらいというか

プロダクトゴールとは?あるいはプロダクトのゴールを設定するには何が必要か?を同時視聴する

www.youtube.com

  • リアルタイム参加したかったなぁ…
  • EBM、まだちゃんと調べてなかった。
  • 「プロダクトゴール」という言葉自体を聞くのが初めて(もしかしたら忘れてるだけ)
  • まったく椅子が見えないw
  • enPiTだとEVPがプロダクトゴールになりがち
  • PBIって受け入れフローあったのか…
  • EBMもっとガンガンつかっていきたい。。。
  • EBMまだよく分かっていないです
  • どの項目に何があるのかは調べたけど、具体的に何??ってなってる
  • CVに従業員満足度が入ってるのがなんというか以外
  • 「プロダクトゴールをもとにして考える」
  • 「プロダクトバックログから抽象化して設定しないこと」うっ
  • スプリントゴールの設定でまさにやってしまっている

スクラムを始めるにあたって何を準備としてやっておくといいか?

OSTでテーマ出しをして、スクラムを始める準備としてどのようなことをやっていくといいのか?というのを聴いていきました。以下のようなアイデアが出ていました。

  • 問題探索からはじめる
  • チーム名決め
  • プロダクトゴールの意識は合わせておきたい。

  • 影響与えてきそうな人(≒ステークホルダ)は気を付けたい。

  • 関係しそうな人を集めてインセプションデッキ(なぜ私たちはここにいるのか?、エレベーターピッチ、自分たちのポジション、どういう風にしていきたいのか)

  • どういう方向を向いているのか、を確認する。

  • 同期を取るタイミングを会議体ベースで決める

  • PBLをつくるとこから始めるのはよかった

  • MTGでどういうことを話すのか、を決める

  • コミュニケーションのチャンネルをどういう所に持つのか、を決める

  • ユーザーのフィードバックをどこに書くかなど、情報整理をどこにしておくかを決める

  • スクラムをあまり知らない人たちとふりかえりをする

  • 上下関係があるか、会社の立場的にいいづらいみたいなことはないのか、みたいは気にしておく

  • リモートワークをどれくらい皆したいか?

  • やることリスト/やらないことリストを作っておく

  • 自分たちの関係性ってこうだよね、というのを鍛えていく(ドラッカー風エクササイズをやるだけでもまずはいいかも。関係性とは何か?を考えてみてもいいかも)

  • 何からやるといいと思う?をお互いに話し合ってみる

  • プロジェクトの成功が自社と発注先それぞれにどのようなメリットがあるか。また、見えているステークホルダー以外にもいい結果はあるはずなのでそれを考える。

  • (波及先も含めて)ステークホルダーとも仲良しになっていく

  • ホットライン(重要な何かあったらすぐに耳に入れられる)整備

  • ライフライン(プロジェクトが危機に遭った時に助けてもらえる人)整備

  • ドメイン知識をパッケージとして販売することもできるなら、サイドビジネスとして第二にのプロダクトを作ることを考えておく

  • お金で解決できるようなオプションを持っておく

  • プロダクトライフサイクルを考えておく。どういう流れにしておくのかをおぼろげにしておく。チームでの次の活躍を考えておく。

  • めちゃくちゃ面白い話をする、そのために、めちゃくちゃ面白い話ができる関係性にする。話すためのトピックとして使うツールは何でもいいが、ユーザーインタビューやインセプションデッキなど。

  • ステークホルダーに対して自己効力感の演出をどのように出していくのか、を考える

全体を通した感想

OSTで皆さんのスクラム導入経験を聴くことができて、とっても楽しかったです。

皆さんの色々な視点が聴きたくてOSTのテーマ出しをした所、想像をはるかに超える視点がもらえて、ありがたい限りでした。
OSTを有効活用できた感じができて、とても満足でした。