キーワード
- スクラムは成長、プロセスづくりの方法、プロダクトづくりのものではない。
- うまく50%失敗する。失敗から学びを得る。
- Hidden Cost
- 見積もりは意思決定の為に使っているはず、ネガティブなパワーがあるので、管理の為に使うということを疑う。
- MVPは本当にMVP。期間も機能も小さく、しかしプロダクトであること。
- コミットメントは約束、というより献身。
- うまく行ったらどうなるの?という問いかけ。
- デリバリすることで｢AだったものがBになる｣ようなものに価値がある。
- コミュニケーションは聞く側の問題もある。
- Performingに辿り着けるのは2%とかなり困難。
- チームの新陳代謝を自分たちが新陳代謝することで行う。
- Practice = Principles x Context。プラクティスだけ見られがち。
- Scrumを選択するには、成長したいという動機が必要。
- レビューにも目的をもたせる。
- 魅力的なスプリントゴールを作る。
- 意見のでないレビューに意味はない。
- フィードバックの無いプロダクトを作る意味はない。
- 方法よりもエンパワーメント(かもしれない)。
参加できたセッション
Day1
- James Coplien - The Ten Bulls of the Scrum Patterns
- アジャイルコーチ活用術
- みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか？
- 見積りしないスクラム / NoEstimates Scrum
- モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education
- The Product Owner and Scrum Master Brain Transplant! Mwuhahahaha!!!
- テックリードは未来の話をしよう (Tech Lead in Scrum)
Day2
- Michael Sahota - Lost in Translation: The Manager’s Role in Agile
- チームの再定義 -進化論とアジャイル-
- Team-Based TEAM - 会社を越えるチーム
- 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方
- ORGANIC agility®: an evolutionary approach to organizational resilience
- 最高のScrumキメた後にスケールさせようとして混乱した(してる)話
自分のモチベーション見える化
- トータル、49個
- 共感したこと(Empathy)、18個
- 学んだこと(Learn)、21個
- 疑問(Problem)、4個
- 次の行動(Action)、6個
共感したこと(Empathy)
- モブプロはスループットを安定させて、パーキンソンを解決する。
集団で活動する事によってカバーしあい、個人に左右されづらくなる。
- どろくさくやる。恥をさらす。
- プロダクトはコンセプトを決めてそれを軸にMVPにする。
MRD,PRD。
- PMの代わりにスクラムマスター、PM=SM。と思われがち。
それは、健全ではない。PMはプロジェクトの管理者。SMはプロセス、成長の管理者。とでも言うニュアンスかな?
- ワクワク、情熱を感じる場であるべき。
- チーム全体で取り組む
全員がPBIをこなせるようにする。
個々の依存性にとらわれないように。
在庫(滞留)が発生しているのは恥ずべきこと。
全員がすべての仕事をする。
パラレルで進む。
- 開発チームとともにoutcomeを考える。
ユーザーの声を届けることで行ったり。
- 期待値を設定するのは、依頼側の責任。
- チームはいつ死ぬか?
老衰?衰弱死?っていうのは面白いなと。
- 同じチームでも自ら新陳代謝する。
チームの新陳代謝は人を入れ替える事。が本質ではない。
- 講義を予習しない。は怠惰ではない。
予習をしない。という行動を選択している。
｢人間は何もしない｣ということはない。
何もしないという選択をしている。
予習してこないのは予習しなくても済んでいる。から。
｢学び｣が喜びであれば好子になるが、そうでなければ嫌子。
- 文化はPrinciplesやContext
｢Practice = Principles x Context｣
Practiceに注目されがちで、Principles(原則) x Context(環境、背景)を無視される。
PracticeはPrinciplesとContextの掛け合わせから生まれる。
- イノベーターのジレンマ
結果を変えたくて(失敗からの脱却)、行動を変えようとしても、文化を変えていかないと失敗のエリアから抜け出せる行動を選ぶことができない。
文化を変える必要性。
- POとSMはやることが異なっていてもマインドセットでは変わらない。
から、POがSMやってもSMがPOやっても問題ないのではないか?
というのは興味深い。
- コミットメントをなんと思うのか人によって違う。
約束･結果、献身。
何にせよ、期待のすり合わせがされないと不幸になる。
まぁ言いたいことはわかるw
- 盛り上がるレビューに演劇という手段
- レビューに対する不感症
学んだこと(Learn)
- スクラムは自然の道、門。
人も自然。抗わずに調和を持ってすすめる。
- スクラムはプロセスを作る、チームを成長させる。
タスク管理やプロダクトを作る手法である面もあるが、プロセスづくりや成長する為の手法という面もある。
タスク管理の面ばかりで捉えていると、ふりかえりも｢作業の進め方ややりかた｣の話をせずに｢次なんの作業をするのか｣と作業の話をしがちになりそう。
改めて｢POはプロダクトを考えるし、SMはプロセスを考える。｣と、強く思った。
プロダクトの為ではなく、組織のためのアジャイル。
プロセスがプロダクトを作る。スクラムはプロダクトを作らない。
- スプリントは実験の場、スプリントは半分失敗させる。
失敗から学びを得て、改善させる。
計画よりもスプリント期間内での行動を計測し改善させる。
- PBIはデリバリの順番、優先順ではない。
優先順=デリバリ順ではないこともある。
デリバリにフォーカスして考える。似ているようで違うもの。
- スクラムなんて存在しなかった。
調和、自然が唯あるのみ?
"やる"と"なる"。は違う。
本来の自分に習うのがスクラムで、ソレ以外はメソッド。
- 見積もりにはHidden Costが発生する。
見積もりは数値化しても正確にはやりきれない。
そこにムラ、ムダが常に発生する。
見積もりすることで、パーキンソンとかプレッシャーとかネガティブに作用する(ところがある)。
- なぜ見積もりを行うのか?計画を立てたい、適切な意思決定を行いたいから。
ではないか?という提示。
見積もりをしないことで、スケジュールをどう担保するのか?
遅延による"損失"を見積もることでリリースのタイミングを決める。
リリースまでの?リードタイムを計測している。=キャパシティの実績をためている。
- コミットメントは献身
約束というよりは｢献身｣と考える。
- MVPは常に。
- うまく行ったらどうなるの?という問いかけ手段。
価値があるかどうか問いかけの質問にも使えそう。
- コミュニケーションは聞く側の問題もある。
当事者意識とか自分ごと化みたいなところにも通じそう。
伝え方の良し悪しを考える。というだけでなく、聞く側に何かしら課題があるのでは?と考えるのも一つの手。
- 情報の並列化
目的がチームではなく、つながりがあるのがチームなのでは?という問いかけ。
仕組み化。
- 価値とは?利用者がどう変わるか。
ビジネスアウトカム=売上。
ユーザーアウトカム=｢欲しい物が見つかる。｣とかユーザビリティを向上させる的な。
- アウトカムとアウトプットは対立しない。
outputがないのにoutcomeの話をしても意味がない。
- ｢チームアウト｣的なプロダクトの作り方みたいなのもあるのか?
自分たちチームが作りたいものを作る的な。
トークの本意ではないだろうけれど。
- タックマンモデルの最後までたどり着けるのは2%(どっかの海運?海軍?大学調べ)
｢いつからお前はPerforming期にいけると思っていた?｣的な。
StormingからのAdjourningウケる。
- モブは、貢献出来ない感が嫌子として作用する。
けど、嫌子の介入はあまりオススメしない。
モブ自体が嫌子になったり。
好子と嫌子は人さまざま、種類もバランスも。
- コミットメントから想起するものはベクトルがある。
自分がコミットしていると感じること、周りの人がコミットしてくれていると感じること。
- スクラムを選択するには、成長したいという動機があること
みたいなのはありそう。
成長したい感がなければ、選択してもうまくいきづらい。
- レビューのテーマを決める。
｢レビューによって何を得るのか｣｢○○に見せる為に事前にレビューするよ｣とか。
- 意見のでないレビューに意味はない。
そして、それが現状。問題があるなら改善すればよい。
フィードバックを得るサイクルを適度に短くしつつ意味のある状況で実施すればよい。
フィードバックの無いプロダクトを作る意味はない。
疑問(Problem)
- 遅延による"損失"の見積もりとは?
極端な話、損失が無ければどこまでも開発をしていい。ということかな?
逆にいつまでに開発すれば(見込みの)利益が得られる。みたいなことの計算もしているのかも。
四半期、半期の計画をしたい場合には、ポイントだとか見積もりとか、どうしてもしてしまいそう。
- ディスカバリのスキルの見つけ方。
アイデアの見つけ方でいいのかな。
- OpsでScrum?
opsな感でも継続開発な感じなのだと違和感なさそう。
けど、インフラ系とかだとやっぱりハマりづらいのか?
ルーチン的な業務でも時にカオスだったり、先の見えづらい作業にはよいのだろうな。
- 経営陣は逆に何を考えているか認める必要があるのではないか?
トップを変えたがっている人たちが多いけれど。
一方的な感じも受ける。
次の行動(Action)
- Hidden Costの発生源をさぐってみる。
- リモートは常にウェブカメラで繋いで少しでもコミュニケーションしやすく。
- デイリースクラムは報告じゃなくて先のタスクを調整するもの。という話し合いをする。
- ワクワクしているか、ワクワクする場所にできるか確認、行動する。
- 今後もScrumですすめるか?成長したい動機の確認。
- 魅力的なスプリントゴールをたてるよう工夫する。
最後にヒトコト
pmconfに続き、ものすごく充実したカンファレンスでした。
感謝。
