2021年9〜10月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第7弾で2年目に突入しました！
- 2020年9〜10月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2020年11〜12月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年1〜2月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年3〜4月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年5〜6月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- 2021年7〜8月に社内で共有したアジャイル開発関連の記事 - tuneの日記
- ノウハウ・知見
- 他社事例
- Twitter
- オンラインのアイスブレイクにはしりとりがおすすめ
- うまくいかない時は自分と周囲の状況把握こそ大事
- 仕様通り以上の品質にチャレンジしているか
- すぐできる改善はさっさとやろう
- ミーティングなんか出てないでディスカバー行ってこいよ
- 入社したばかりの人に「次にこの人と話すといいよ」というテレフォンショッキング形式 1on1をやるとよい
- 改善項目の選び方
- デプロイを自動化したいというPBIはHowを表している
- Keepを考えるのが苦手な方へ
- POが決める優先順位にはフィードバックをあげる必要がある。
- Minimum Viable Productを作るイメージ
- ステークホルダーの紹介をきちんとしてあげよう
ノウハウ・知見
Ryuzeeさんがまとめてくれたアジャイルに関するFAQ
これもよいし、Waicrew 角さんのも良いまとめだなと思っています。
山型クロスファンクショナルチーム
クロスファンクショナルチーム/フィーチャーチームを組もうとすると「全部触れるようにならないとダメですか?」と質問がいつもくるのでこういう考え方もあるよって広まってほしい。
Miroの便利機能まとめ
有償でしか使えない機能があったりするので色々探検が必要。
短期と長期両方大事
理想論から長期目線に引っ張られることが多いけど、短期でも成果を出していくことは大事。
スクラムフェス三河キーノートスピーチ書き起こし
ありがたい
カイゼン・ジャーニー・カンファレンス - プログラマのジャーニー
3年前の発表資料のようですが何かの拍子にふと見かけて良い内容だったので
しいばさんと咳さんとみわさんの雑談
タイミング合わなくて聞けなかったのが残念。
咳チームのことを考えると、自分の中の不純物に気づくことができるから。
これわかります。
「心理的安全性おじさん」になっていませんか?
概念じゃなくて現場に寄り添いましょう。
余白を作り、埋める動きをする
自分が社内でやっている動きに近い。
他社事例
atama plusのスプリントの紹介記事
スプリントレビューで500件コメント出るのはすごい。見学に行ってみたい。
atama plusでLeSSを取り入れたことのエンジニア感想
Rettyと大差ないねーという声がありました。
オンラインのアイスブレイクにはしりとりがおすすめ
そういえば、以前やったことあるんですがオンラインMTGにあまり慣れていない人の集まりのアイスブレイクはしりとりがおすすめです。そこそこ楽しい気持ちになるし、全員のマイクとスピーカーの調子が一撃で確認できるので。
— だいくしー (@daiksy) 2021年9月3日
うまくいかない時は自分と周囲の状況把握こそ大事
上手くいかないのをシステム、上司、同僚、他部署のせいとか、あるけども、それはひとつの可能性としてだし、求められる態度は
— きょん＠アジャイルコーチ、システムアーキテクト (@kyon_mm) 2021年9月11日
何が起きていて、自分は何をしていて、周りはどう、っての解像度の高い説明をできるように知ろうとすること
なんだよな。。。結果としての1つの選択肢でしかないというか
仕様通り以上の品質にチャレンジしているか
多くの現場が「仕様の確認」ばっかりテストしているので、「仕様どおりであること」以上の品質にチャレンジできていない。そして、網羅性の価値比重が高いので、探索テストが重要視されないのではないか
— Dai Fujihara | mabl ノーコードテスト自動化SaaS (@daipresents) 2021年9月22日
すぐできる改善はさっさとやろう
すぐできるような改善は別にレトロスペクティブなんか待たずにガンガン勝手にやればいいんだよ
— Ryutaro YOSHIBA (@ryuzee) 2021年9月24日
ミーティングなんか出てないでディスカバー行ってこいよ
プロダクトマネージャーがプロダクトディスカバリーに時間が取れないというのは、本人と（特に）チームがプロダクトディスカバリーを他タスクよりも優先させていないから。参加が必須ではないミーティングにでも出ていたら、そんなことよりプロダクトディスカバリーしてこいよと言うチーム文化が欲しい
— 及川卓也 / Takuya Oikawa (@takoratta) 2021年10月1日
入社したばかりの人に「次にこの人と話すといいよ」というテレフォンショッキング形式 1on1をやるとよい
Rettyでも次に入社した人にやってあげようと思っています。
フルリモート環境で転職して新しい職場に馴染むために、勝手に「テレフォンショッキング方式1on1」をしている話を、来月登壇時の資料として書いている。
— Akiko Kurono - a.k.a crema (@crema) 2021年10月2日
すぐに仕事をご一緒する人と1on1する→そのとき「次に誰と会ったらいいですか？」と紹介してもらう→その人にDMして1on1を依頼。以下ループ。
改善項目の選び方
ほんとこれ
- どうでもいい小さな改善をたくさんやるよりインパクトのある1つの改善を
— Ryutaro YOSHIBA (@ryuzee) 2021年10月4日
- 問題を扱うときは薄く広くじゃなく、深く狭く
- 意見と事実を切り分けろ
- 実際に改善できたかどうか追求しろ。効果がなければもとに戻せ
- 改善は仕掛け化しろ、気を付ける、注意する、共有する、連携するとかは無意味
デプロイを自動化したいというPBIはHowを表している
今日はこういう基本的な話をした。 pic.twitter.com/Xs2Z6ZbVdS
— Ryutaro YOSHIBA (@ryuzee) 2021年10月7日
Keepを考えるのが苦手な方へ
ふりかえりのシート、ぱっと見KPTなんだけど、【Keep】の見出しに
— よこち (@akira6592) 2021年10月15日
・学んだこと
・楽しかったこと
・ポジティブな気づき
・など
とかいたら、何時も書かれないタイプのKがでてきた。
POが決める優先順位にはフィードバックをあげる必要がある。
POが決めるための十分な情報（めりでめだけじゃなくどっちがいいと考えてるかとか、ほんと十分な）を与える職責があり、決めたことにもきちんとフィードバックする必要はあるんだけど、そこをしなくていいと思ってる人が結構いて、そういうのがすごく嫌い。
— いろふ (@irof) 2021年10月22日
Minimum Viable Productを作るイメージ
— Pukar (@PukarDesign) October 24, 2021mobile.twitter.com
ステークホルダーの紹介をきちんとしてあげよう
スプリントレビューで、POが招待したステークホルダーの名前や仕事の内容とかバックグラウンド、プロダクトとどう関わっているのかを参加者全体に説明してて、とても良い
— Ryutaro YOSHIBA (@ryuzee) 2021年10月27日
