tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

Regional Scrum Gathering Tokyo 2022に参加してきました #RSGT2022

f:id:tune:20220109175931j:plain

はじめに

2019年が初回で、通算4回目の参加でした。

参加者(2019)→スポンサー(2020)→参加者(2021)ときて、今年は登壇機会がいただけ新しい楽しみ方ができました。 登壇に関しては来週あたりに会社のブログで別途書きます。

聞いてきた話など

「録画で後で見れるし、他のオフライン参加者と親交を深めるか」と考えて発表を聞いたのは半分くらいです。 3日目は家族都合 & 会社都合で不参加でした、後日録画で見ます。

Agile Program Management: Scaling Collaboration Across the Organization

f:id:tune:20220105101953j:plain

「スケールする際にコラボレーションを増やしてスケールしよう」というのはわかる。LeSSだと「ただ話す」とかなのかな?

f:id:tune:20220105104151j:plain

Software Program Teamはよくわからなかった。コラボレーションを絞る方向の仕組みだと思うけど、でも何かを決める仕組みが時に必要なのは同意。

Leading Skilled Agile Teams: Investing in Team Outcomes with the Agile Fluency® Model

f:id:tune:20220108220623p:plain
https://martinfowler.com/articles/agileFluency.html より転載

Agile Fluencyの図がなるほどなーと思って聞いていました。 チーム文化を変える→チームスキルを上げる→組織構造を変える→組織文化を変える の中で、自社の今はOptimizeのあたりかなーと思いあたります。 「アジャイルである」領域を広げる際に、気持ちではなく仕組みで工夫する必要があり、とっかかりを試行錯誤していた自分にとってはしっくりきた図でした。

martinfowler.com

今年の感想

ゴールに関する発表が多い

プロダクトビジョン・プロダクトゴール・スプリントゴールなど、目標やゴールに関する話が多かったし、講演後も議論しているのを良く見かけた気がします。

1チームのスクラム・立ち上げはできるところが増えてきて、LeSS / Scrum@Scale / Spotify Modelなどスケール手法を試すところが出てきて、「複数チームの方向性を束ねて力を引き出すにはゴール設定で認識揃えるのが大事だと考える人たちが増えてきた」とかかなーと思っています。 自社でもプロダクトゴールが明確に作れてなかったり、スプリントゴールをフワッと決めてしまうところがあり、今ひとつしっくりきてない感じがあったので長沢さん・稲野さんの発表を踏まえて試行錯誤します。

建設的な議論をカンファレンス中にやりたい

コロナ禍となり、オンラインカンファレンスになってからテキストチャットで感想を伝えるからか「いい話」のようなコメントが増えたような気がしています。

どんなことを言っても受け止めてもらえる場は大事だけど、議論して課題を見つけていく・考えることはもっとやった方が良いんじゃないかなと感じました。気心の知れたメンバーと個別に行っていたり、自社・自分の現場に持ち帰ってあーでもない・こうでもないと話しているような気がします。 できることなら会期中に「こんな意見もあるんだ」という観点を得てもらうのに見える形でできた方が良いなと。単にDiscordに撒き散らしていると荒らしっぽく攻撃しているように見えちゃうけど、RSGTの参加者ならうまくやれる方法を見出せるような気がしたり。

全体として前進できているかな?

プロダクト・現場を良くするため、知見を持ち寄って協力するギャザリングだと思うので、数年単位で見たら変化が感じられるような場であってほしいなと思うようになりました。もちろん新規参加の裾野は広がり続けるし、うまくいったり・いかなかったりを繰り返しながら螺旋のように改善が進んでいくと思うのですが、全体としてどうなんだろうと。一部の人は成功体験を積んで前進しているけど、個人に紐づいている割合が大きいような気がします。

その意味で伊藤さんの発表は考えさせられるポイントがいろいろあるなと感じました。この講演を聞いた人が次世代の社内アジャイルコーチとして業界全体のレベルを引き上げたり、伊藤さんが新たな視点を経てRSGTに戻ってきたりとか、そんな瞬間に立ち合えるといいなと思っています。

自分の4年前を思い出すとできていることが増え・フェーズが変わってきた実感がありますが、参加者全体で見ると参加者・登壇者が開発・アジャイルコーチに寄りすぎていて、もっとステークホルダー(経営層・幹部層)やプロダクトマネージャーなどが増えると良さそうだし、基調講演の反応が変わってきたりするのかなと思いました。

「モノリスからマイクロサービスへ」を読んで考えたこと

2021年に会社で読書会をし、社外の方とも別途読書会をしたほどの本でしたが、タイミングを逃して感想を書いてなかったので残しておきます。

マイクロサービスに取り組む上での基礎や重要事項が丁寧に説明されている

1章と5章が特に良かったです。

  • なぜマイクロサービスに取り組むのか。
  • 3つの疑問。1. 達成したいこと、2. 代替案がないか、3. 成功の基準。
  • マイクロサービスで守るべきこと

などなど。

3章と4章はテコ入れの界面を見定めて徐々に新しステムに切り替えていくストラングラーパターンをサービス内・DBで行うような似た話が続いており、ここを工夫できればもっと短く上手くまとめられそうなのになと感じました。

書籍全体の印象としてはマイクロサービスを考え始めたぐらいの時期から、実際に進めていて壁にぶつかったあたりまでに読むのが良さそうです。 関係者の知識や思想を揃えるにはいい本でした。マイクロサービスを推進していく上での実践テクニックはそこまでカバーされていません。

モジュラモノリスそんなにいいものだろうか

書籍ではマイクロサービスが一押しというわけではなく、なぜマイクロサービスに取り組むのか・モノリスではダメなのかという話も同じくらい重きを置いて説明されています。 デプロイ単位としてまとまっているが、内部の作りは分けられたモジュラモノリスも書籍で触れられていますが、読書会でもモジュラモノリスに惹かれるメンバーがいました。個人の感想としてはモジュラモノリスフレームワークの後押しが欠かせないと感じていて、知っている限りだと取り組むのに向いているフレームワークはあまりないかなという印象です。強いて言えばRails Engineなのかな?

自社でも一つ、小さなサービスの寄り合いになっているサービスをモジュラモノリスのように作ってみましたが、内部で知らず知らずのうちに依存関係を持ってしまったことが後日わかり、切り離す判断が遅れていたらもっと結びつきが強くなってただろうなと思います。フレームワークで依存関係を防止できるか検出できるようになってないと厳しい印象です。 モジュラモノリスに取り組んでいるところがあればぜひ話を聞いてみたいなと思いました。

マイクロサービス移行は文化の変革である

自社のマイクロサービス移行は数年かけた計画になっており、早くともあと3〜4年かかるかなという見立てですが、書籍でもマイクロサービス移行は文化を変える必要があり、長い時間がかかるとはっきりと書かれています。 自社の力不足や怠慢で時間がかかっているのではなく、開発文化を変えながら進める必要があるためこれぐらいかかるのが当たり前だという時間軸の認識を揃えられたのが良かったです。

異なるプロダクトに取り組んでいる人同士で話すと違った気づきがある

冒頭で触れた通り社内読書会と社外読書会で2回読みましたが、それぞれ違った気づきがありました。

社内メンバーとの読書会は会社のプロダクトの歴史を踏まえ深く議論することができますが、経験が似ているからか観点は偏りがちで、書籍で意図が汲み取れなかった箇所が社内メンバー全員わからずといったこともありました。

社外メンバーとの読書会では、経験・背景が異なるので、「こういう経験があった」「こういうことかと受け取った」といった話を広く聞くことができ、いろんな視点から本の内容を考えることができました。2022年も何かの本を選んで社外の方と話をすると面白いかも。

他に気になっているマイクロサービス本

会社でマイクロサービス導入を始めた2019年に読んでこれは完走しました。だいぶ前の本ですが、内容が大きく古びていることもなく今でもおすすめかと。

まだ未読ですが、「モノリスからマイクロサービスへ」よりも実践的な内容がカバーされている印象を持っています。

2021年11〜12月に社内で共有したアジャイル開発関連の記事

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。次回からは3ヶ月に1回のまとめに変えてみます。

ノウハウ・知見

ハックマンに学ぶ良いチームの作り方

speakerdeck.com

アジャイルなソフトウェア開発に使えるかもしれないメトリクス

iucstscui.hatenablog.com

スプリントレビューでコンテキストをきちんと共有する

callas1900.net

アリスター・コーバーン再考

話が引き継がれるにつれて変わっていくのあるあるですね。

www.agile-studio.jp

他社事例

ChatworkのScrum@Scale

開発体制、スケジュール、自己採点の仕組みなどが興味深い

www.youtube.com

はてな MackerelのLeSS事例

hktngch.hatenablog.com

マッハバイト(LIVESENSE)のスクラム導入と廃止

よく見る失敗談で、新天地でスクラム入れようと奮闘する人も何割かは直面することになるものばかりだなーと思いました。

made.livesense.co.jp

Mobility TechnoglogiesのLeSS事例

now.mo-t.com

その他

Women in Agile Japan

いい取り組みだなー、貢献できることあるかなーと思っている間にDiscord招待リンクが切れてしまっていた><

note.com

Twitter

スクラムマスターの一人相撲

顧客に予算を持たせて、何を作るか投票させる

スレッドの情報含めて面白い。

アジャイル浸透が頓挫する組織の風土

作り方がわかる人がいないのに決めたがる不思議

不確実性を人に押し込めるのがアジャイル?

知的コンバットできていますか?

qiita.com

この記事はAdvent Calendar for upcoming Regional Scrum Gathering Tokyo 2022 Advent Calendar 2021 25日目の記事です。自分がRegional Scrum Gathering Tokyoに初めて参加したのが2019年のこと。2020年は会社でスポンサーでき、2021年は同僚が登壇して、2022年は自分が登壇できることになりました。今所属しているRettyアジャイルに・大規模スクラム(LeSS)に取り組む会社としてある程度認知いただけるようになった感触がありますが、年初にRSGTでエネルギーを貰えているのが助けになっている気がします。

知的コンバットによりイノベーションを生み出す

www.youtube.com

※ 注 : RSGT2021での野中先生基調講演動画はRSGT2022開催までの期間限定公開だそうです。

RSGT2021の最終日の基調講演で野中先生から投げかけられた言葉「知的コンバット」。これまで自分が探究していきたいことを「顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースする開発体制のあり方」と表現していましたが、もっと端的に短く・もっと情熱がこもった言葉を聞くことができ、この1年間自分の頭から離れないキーワードとなりました。

全身全霊で向き合うためには二人、ペアであることが最適です。同時に、双方の目線が上向きや下向きではなく、真っ当に向き合っていることが大事です。それでもそう簡単にはコンセプトは出てきません。「知的コンバット」を何度も繰り返す必要があります。双方が感じた異なる直観を、真剣勝負で何度もぶつけ合いながら、ようやく「こうとしかいえないよね」というコンセプトにつながっていくという感じです。この「共同化」のプロセスがない限り、組織で「知」を生み出す、イノベーションが起こるということはあり得ません。

【野中郁次郎氏対談】第2章 徹底的な対話による「知的コンバット」なくして、イノベーションは生まれないより引用

「プロダクトオーナーが決めたプロダクトバックログの優先順位に従って開発を行う。開発チームは固定期間で区切ったスプリント内でインクリメントを作成し、リリースして得られた学びから次に何をしていくべきかを改めて考える。」こうして不確実なプロダクト開発に挑戦してくのがスクラムですが、真に優れたプロダクトを作る・イノベーションを生み出していくにはもっと真剣に自分たちが取り組む対象に向き合い、議論を戦わせていかなければなりません。

知的コンバットは難しい

「議論が大事だから意見を戦わせよう。職責やロールにこだわらずやっていこう。」と言うのは簡単ですが、実際に起きるのはレベルが低いケンカとトラブルです。 「セールス・企画・開発で納得のいく計画・プロダクトを作りたいのでお互いに意見を伝え合おう」と言うと、率直な意見が攻撃と受け取られ、職責を超えた提言が信頼感の欠如として受け取られてしまいます。「なぜ取り組むのか」「なぜ今なのか」「もっとよい打ち手はないのか」「何を学ぼうとしているのか」、プロダクト開発に真摯に向き合い本質に迫ろうとする問いほど、その山を知らなかったり、登り始めたばかりの当人にとっては致命傷となるマサカリになります。

HRT(Humility, Respect, Trust)を心がけた発言に、ドメインの理解や背景の共有、相手との信頼感を醸成し、人・相手ではなく問題・ゴールに目を向けて話す。ここまで段取りを整えてようやく知的コンバットの入り口に立てそうというのが私の正直な感想です。

RettyのAdventCalendarでプロダクトマネジメント組織で浸透した7つのキーワード(①PMスキル定義・評価制度, ②アウトカム, ③ロードマップ, ④事前検証, ⑤問いを立てる力, ⑥既知と未知, ⑦因果ループ)を野口がまとめてくれていますが、知的コンバットの土台となるこれらを浸透させるだけで1年です。長い道のりです。

note.com

知的コンバットの実現に手応えを感じた出来事

知的コンバットと呼べるような議論の成功を目指し、うまくいったりいかなかったりを繰り返しながらの開発でしたが、「知的コンバットとはこう言う状態なのでは?」と手応えを感じたことがありました。その出来事の直前は1ヶ月弱ほど中規模プロジェクトの開発に取り組んでおり、その振り返りで「実はプロジェクトの序盤からうまくいってないもやもやを抱えていて、良くないと思っていました」という告白を複数人から聞いたことがきっかけです。「その時言っておけばもっと違った今があるかもしれないのに」と静かな怒りを覚えたのをとてもよく覚えています。

その次のスプリントではスプリントプランニングにいつも以上の時間と熱量をかけました。「次のスプリントに何を取り組むべきか」「プロダクトオーナーの優先順位に質問はないか」「開発観点で先に取り組むべきことはないのか」「言うならこのタイミングだぞ、終わってから意見の後出しだめだぞ!」「本当に納得したか?」とかなり口すっぱく確認し、そこからチームの動きや成果が大きく改善された気がします。

本当に足りなかったのは熱量なのかも。

この記事を書きながら思い返してみると、タイミングやプロセス、知識の問題もあったかもしれませんが、それ以上に熱量が足りてなかったのかもしれません。 その後のメンバーとの1on1で気持ちを込めたアドバイスを多く送った気がします。

  • 相手に言っても聞いてくれないじゃない、聞いてもらえるように言うんだ。
  • 聞いてもらえるために「背景を説明する」「費用対効果を説明する」「時には感情を込める」「めげずに何度も言う」など色々試す。
  • 「コミュニケーションが足りない」とはどういうことなのか。真の問題から目を背けているのではないか。
  • あとでふりかえりをしたらダメだったことが良かったことに出来るわけではない。勇気を出していつでも言うべき。

終わりに

「真剣勝負で意見をぶつけながら、こうとしか言えないコンセプトを作り上げる」を達成した瞬間の楽しさは何ものにも代えられません。 「知的コンバット」の実現に必要な土台は準備は簡単ではありませんが、こうした経験が積める場を作れつつあることがマネージャーとしての今年の成果かと思います。

今日の話は「協働でゴールに向かう"チーム環境"」に関する話ですが、RSGT2022では「高速に石橋を叩いて渡る"開発環境"」の話をします。来年もRSGTでエネルギーを補充し、イノベーションを産む原動力を養っていきましょう。

心理的安全性をもたらすには

この記事はEngineering Manager Advent Calendar 2021 4日目の記事です。

f:id:tune:20211122101448p:plain

心理的安全性という言葉が一般的になり、その重要性も、誤解(心理的安全性=ぬるま湯とか)も、訂正(心理的安全性は当人が決めるもの)も広まった状況かと思います。

心理的安全性を扱った記事はたくさん見かけるものの、「心理的安全性を高めるに具体的にどう行動したら良いのか?」という疑問に正面から答えた事例は少ないように感じます。ということで自分が普段行なっている行動や背景にある考えを紹介します。

ただ話す

チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されています。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけです。立ち上がって話に行ってください。

これは大規模スクラムフレームワークの一つ、LeSSで紹介されているプラクティスの1つです。 何か相談しないといけない時にマネージャーやリーダーに相談したり、定例会議を設けたり、調整役を設定したりすることをよくしますが、LeSSでは調整が必要になった時にただ立ち上がって相手のところに行き話すことを推奨しています。

チーム同士で調整が必要な項目はマネージャーを介さず話してもらっていますし、チームに対してのもやもやを相談された時は直接当人に伝えてみてはと話しています。マネージャーが間に入った方がうまくいくケースは少ないですからね

調整と統合 - Large Scale Scrum (LeSS)

"誰"の話をしているのかを明確にする。

「チームに言いずらい」という悩み相談を1on1で聞くことがありますが、その時は「言いづらい相手はAさんのことですか? それともBさん? それともCさんのことですか?」と名指しで聞くようにしています。1人1人の顔を思い出して考えてもらうと個別の人に言いづらいということはほとんどなく、大抵はチームや組織といったボヤッとした対象に対してなんとなく受け入れられないんじゃないかという不安感を抱いているケースがほとんどです。

対象をぼやかして話すと、さも抽象度の高い難問に取り組んでいる感じが出てしまうので、具体的に掘り下げてみましょう。 似たような話ですが「組織は話さない」というブログ記事が切れ味鋭くて好きです。

組織は話さないですよ|qsona|note

個人の問題ではなくプロセスの問題として扱う

「ただ話す」を実施してもらい、「誰の話か明確」にしても解決しない問題はあります。 1個人の望ましくない振る舞いが槍玉に挙げられることは少なくありませんが、この手の問題は「個人のコミュニケーションの問題」としてしまいがちです。 ですが一緒に働くメンバーを信じるならば、これは個人の問題ではなく「問題を生み出す背景プロセスの問題」なのではないでしょうか。

プロセスの問題を炙り出すには事例を複数集めて共通する背景要因を時間をかけて考える工数が発生しますが、個人の問題として安易に断じない姿勢をとり続けることで、問題をエスカレーションしても正しく議論されるという安心感が醸成できるのではないかと考えます。

聞きにくいことを率先して聞く

皆にしてほしい振る舞いを率先して行い、背中で見せることはよくあると思います。 私は言葉足らずだなと感じた説明があったら、意図を明確にするためにあえて聞くことを意図的に行なっています。

例えばあるルールが「"従業員"を対象に実施」と説明された場合、正社員の自分が対象者に含まれることは自明ですが、アルバイト・業務委託・インターン契約社員のメンバーは悩むかもしれません。こんな時は「従業員にアルバイト・業務委託・インターン契約社員は含まれますか?」とSlackチャンネルでオープンに聞いたりします。「マネージャーなので質問しやすいんでしょう」と思われているかもしれませんが、投稿する時はドキドキしています。役職者になってもそんなものです。

心理的安全性があるかのように振る舞う

心理的安全性の話が出るといつも引用してくる好きなスライドです。 マネージャーだからドキドキしても聞きにくいことを聞く、マネージャーだからメンバーを信じてプロセスの問題を探す、マネージャーだから皆が自律的に動けると信じて後ろで見守る。皆も同じような振る舞いを続けて自信がついてきた結果の先に心理的に安全な職場が実現できる。私はそう考えています。

おわりに

心理的安全かどうかは各々が感じる・決める話ではありますが、2021年夏に勉強会を開催した際に「今の会社は心理的に安全か?」とファイブフィンガー (指1本:安全でない〜指5本安全である)で回答してもらったことがありました。私は指4本を出しましたが他のメンバーは指5本出していたので、そこそこ安全な職場が作れているのだと考えています。

そんなエンジニアリングマネージャーが考えていることの紹介でした。

チームトポロジーを読んで考えたこと

2021年12月1日にTeam Topologiesの翻訳 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 が発売になります。 本書のレビューに参加させていただき、翻訳者の皆様から一足先に書籍をいただきました。 レビュー時は「なかなか難しいな…」と思っていましたが、翻訳者の皆様の努力とカラー装丁の効果か、読みやすい本に仕上がっております。

チームトポロジーとはどんな本か

翻訳者の一人であるryuzeeさん始め、多くの方が既にまとめてくださっているのでそちらを参照するのが良いかと思います。

チームトポロジーは、このコンウェイの法則を踏まえたチームファーストのアプローチです。 「チーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現する」という逆コンウェイ戦略を実現するために、4つのチームタイプと3つのインタラクションモードを定めています。 それをもとにフローを最適化する組織を設計しようというのが肝です。

自分の言葉で話すと「ソフトウェア開発体制」の定石を扱った本かなと思います。パターンランゲージとかが近いのかもしれません。 チームトポロジーの知見を踏まえつつ、状況に応じた開発体制のあり方を議論し見直していく。うまくいく状態を見いだせてから組織図に反映していく。本書とはそんな付き合い方が良いのではないかなと思います。

"ソフトウェア開発はこうしたらうまくいくんじゃないかな?"という経験や理論が体系化されている

「フロー(デリバリー、バリューストリームとか)を最大化する組織を目指す」「チームを基本単位として長く存続させる」「コミュニケーションパスを整理する」といった、ソフトウェア開発をうまくやるための知識が幅広く紹介・解説されており、関連する書籍や一次情報へのポインタもまとめられています。「サービスが成長し、人も増えて来て組織のあり方を見直したい」というのは"あるある"のよく聞く悩みですが、本書はそんな悩める人が手に取り読み、共通の知識・用語を使って議論を始める土台とするのにちょうど良いと思います。

自分は開発部門のマネージャーとしてチーム編成を見直すことが時々ありますが、チームにどんなコミュニケーションを取ることを期待しているか説明することができていなかったなと本書を読んで感じました。本書で説明されている3つのインタラクションモードは誤解なく伝えることができそうで、業務でも取り入れようと考えています。

コンウェイ戦略という用語の難しさ

本書のベースにはコンウェイの法則と逆コンウェイ戦略があります。

先に引用したryuzeeさんの説明も「チーム構造と組織構造を進化させて」とあるので、変えていくこと前提だと思うのですが、「目指すソフトウェアアーキテクチャ正解があって、それに合うように開発体制を作るんだ」と考えている人が一定割合いるんじゃないかなと感じることがあります。本書はそんなこと書いてないんですが、斜め読みして誤解する人が増えると嫌だなーとか用語が出てくるたびに頭をよぎります。

"ドメインの知識はあっても望ましいサービス責務が見えていない"は割とあるケースだと思っています。 ストリームアラインドチームのコラボレーションを促し、チームの責務を意図的に広く・曖昧にして議論を促すと良いのかなーとか考えたりするんですけど、逆コンウェイ戦略かと言われると違う気がしています。「脱コンウェイ戦略」とかなのかな?

ハブやコミュニティをどう表現するか

組織のスケーリングを扱った書籍だとコミュニケーションのハブとなる人材や、ノウハウマネージャーを置いたりして、コミュニケーションパスを短くするアイデアがよく紹介されます。Spotifyモデルのギルドのように職能や目的別のコミュニティを作るというやり方もありますが、これらはチームトポロジーではどう表現するとよいのでしょう。

仮想的なイネーブリングチームがあって、他チームをファシリテートで導いている気もするし、チームの一部メンバーがコラボレーションしているとも言える気がします。

ソフトウェア開発以外の組織体制はどうしていくといいんだろう?

サービスはソフトウェア開発だけで成立しないので、営業や企画など他部門を交えてフローを最大化していく必要があり、開発組織と合わせて進化させていく必要があると思います。チームトポロジーの考え方は使えるような気がするんですが、本書はソフトウェア開発に絞った話なんですよね。

チームトポロジーの狙いはあくまで明快なパターンの提供だとすると、もう少し具体化したルールを定義することで「アジャイルはソフトウェア開発にしか適用できないが、スクラムはソフトウェア開発以外にもで起用できる」ような状態にできるような・・・できないような・・・

他社の事例も聞きたい

読んで終わりにするのではなく、自社の状況を図示して整理し、共通の用語を使って議論できることにチームトポロジーの価値があると思っています。自社の開発体制を描いたものが手元にありますので、見てみたい方・議論したい方・ツッコミしたい方、お声がけください。

Meety or Meetyのグループディスカッションを考えたのですが、クローズよりはオープンな勉強会とかの方が良いのかなと思ったり。何社か集まってできるといいな。

2021年9〜10月に社内で共有したアジャイル開発関連の記事

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第7弾で2年目に突入しました!

ノウハウ・知見

Ryuzeeさんがまとめてくれたアジャイルに関するFAQ

これもよいし、Waicrew 角さんのも良いまとめだなと思っています。

www.ryuzee.com

山型クロスファンクショナルチーム

クロスファンクショナルチーム/フィーチャーチームを組もうとすると「全部触れるようにならないとダメですか?」と質問がいつもくるのでこういう考え方もあるよって広まってほしい。

Miroの便利機能まとめ

有償でしか使えない機能があったりするので色々探検が必要。

note.com

短期と長期両方大事

理想論から長期目線に引っ張られることが多いけど、短期でも成果を出していくことは大事。

yattom.hatenablog.com

スクラムフェス三河キーノートスピーチ書き起こし

ありがたい

logmi.jp

カイゼン・ジャーニー・カンファレンス - プログラマのジャーニー

3年前の発表資料のようですが何かの拍子にふと見かけて良い内容だったので

しいばさんと咳さんとみわさんの雑談

タイミング合わなくて聞けなかったのが残念。

咳チームのことを考えると、自分の中の不純物に気づくことができるから。

これわかります。

aki-m.hatenadiary.com

bufferings.hatenablog.com

心理的安全性おじさん」になっていませんか?

概念じゃなくて現場に寄り添いましょう。

www.nakahara-lab.net

余白を作り、埋める動きをする

自分が社内でやっている動きに近い。

他社事例

atama plusのスプリントの紹介記事

スプリントレビューで500件コメント出るのはすごい。見学に行ってみたい。

note.com

atama plusでLeSSを取り入れたことのエンジニア感想

Rettyと大差ないねーという声がありました。

note.com

Twitter

オンラインのアイスブレイクにはしりとりがおすすめ

うまくいかない時は自分と周囲の状況把握こそ大事

仕様通り以上の品質にチャレンジしているか

すぐできる改善はさっさとやろう

ミーティングなんか出てないでディスカバー行ってこいよ

入社したばかりの人に「次にこの人と話すといいよ」というテレフォンショッキング形式 1on1をやるとよい

Rettyでも次に入社した人にやってあげようと思っています。

改善項目の選び方

ほんとこれ

デプロイを自動化したいというPBIはHowを表している

Keepを考えるのが苦手な方へ

POが決める優先順位にはフィードバックをあげる必要がある。

Minimum Viable Productを作るイメージ

mobile.twitter.com

ステークホルダーの紹介をきちんとしてあげよう