fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

Regional Scrum Gathering Tokyo 2020 (Day1)

2020/1/8(水)～1/10(金) Regional Scrum Gathering Tokyo 2020に参加してきました。
20200110_010.jpg


公式サイト
https://2020.scrumgatheringtokyo.org/
https://confengine.com/regional-scrum-gathering-tokyo-2020/schedule/rich （タイムテーブル）

Togetter
https://togetter.com/li/1452991

アジャイル関連のお仕事やってるので、会社の経費で参加させていただけることに。
去年も参加したかったんですが、一瞬でチケット売り切れてしまったので・・・
今年は申し込み開始直後、すぐにサイトにアクセスして、なんとかチケット買えました。

以下、聴講メモ。

The Ten Bulls of the Scrum Patterns


https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/13334/the-ten-bulls-of-the-scrum-patterns



スクラムはガイドの中で見つけられるものではない
プロダクトバックログは要件のバックログではない。

十牛図　・・・　悟りにいたる10の段階を10枚の図と詩で表したもの

４．得牛（とくぎゅう）　・・・　牛を捉まえたとしても、それを飼いならすのは難しく、時には姿をくらます
なぜ、がわからなければ、過去のやり方を踏襲してしまう。ウォーターフォールになってしまう。
→　なぜ、が重要である

デイリースクラム
デイリースクラムは型。毎日構築していくもの。1日1回集まってやる。
状況を毎日再評価する必要がある
スプリントゴールを達成するよう翌日の作業を再計画する。
報告や３つの質問に答える、ではない。
スクラムマスターはPMではない。
なぜ、がわかれば、アジャイルのコアである自己組織化し、次の24時間のために再計画することが大事
それを学んだ

スプリントレトロスペクティブ
Whyを使ってプロセスの変更を始める
ただスクラムガイドや本のとおりにやってるだけでは、同じもやもやが残っている
スクラムは１つではない
科学的な実験室のようなもので、失敗も許されている

失敗すべき
スプリントに持ち込むのはベロシティ。半分はベロシティに入り、半分は入らない
→　５０％失敗していなければおかしい
スクラムはしっかりコントロールされている中で失敗すること。

トヨタのカイゼン、失敗ないしに改善はありえない
みんなで反省する、集合的に反省する
失敗しなければカイゼンの動機がなくなる

継続的にプロダクトを変えていくことができる。
Windows Updateです。みなさん大好きですよね。
継続的な開発、これがアジャイルです。
アジャイルは解決策ではない。

多くの企業は目的が一貫していない。
アジャイルが問題。
トヨタのカイゼンから学ぶこと。
変化にオープンであること、それがアジャイル。

スクラムとは規律。
計画を策定し、変更を自分たちに許すこと。
計画はつきもの。変えると、お客さんいなくなる。

プロダクトバックログはデリバリの順番で並べる。優先順位ではない。
どういう順番でデリバリしていくか。
デリバリのありようを変える。
要件を変えるのではなく、ユーザーストーリーを変えるのではなく、インクリメントを変えていく。

６．騎牛帰家（きぎゅうきか）　・・・　心の平安が得られれば、牛飼いと牛は一体となり、牛を御する必要もない

真実は常に変わっていく
スクラムは学ぶための仕組み
パターンはスクラムを学ぶための仕組み

スクラムで２つ構築する
・スクラムチーム
・正しいプロセス
　作れば正しいプロダクトが出来上がる　トヨタ
　
マネージャを全員解雇しなさい
チームは自分自身で管理する
マネジメントは会社を管理する

止めることも大事。
止めたプロダクト、Googleだとこの5年で35くらいある。

上手くいっている日本の企業から学んだ。パターン。
アジャイルとは何かをすること。


スクラムは何かを構築していく
何かをする、ではなく、何かになる
一生懸命する、doする、はアジャイルではない

仏教は自然。自然をありのままに受け入れるのが無為
なにかを制御しようとするのではなく、調和するということ。

スクラムが作るのはプロダクトでない。プロセス。
プロダクトを作るためのプロセスをスクラムは構築する。組織を構築していく。

スクラムはメソッドではなくフレームワーク。
チームの本来の姿になる、ということ。
内省。自分の中を見つめなおしてください。

２つの集合体がある。
　１．どのように組織を構築していくのか
　２．バリューストリーム

５６のパターン
バリューストリーム
学習のロードマップになる

自分の心に従ってください
パターンは手伝いをするだけ。サポートする。

パターンは相互に影響しあっている
Whyを知る必要がある。
自分のものにしていくことが必要
そこから、見つけていく必要がある
本に書いてあるから、ではない。
自分が信じているから、腹落ちているから、それが真実になる。

パターンは小さいもの
実験ができる。
うまくできなければ変えられる。
フィードバックを受け入れていく

アジャイルを使って、プロダクトだけでなくプロセスやチームを改善していく

無名の質
全体性、美しさ
アジャイルは常に変化していくということ。
場　・・・　集まると、その場から強力なエネルギーが生まれる
それが感じられなければ反省の余地がある
場が感じられないのか考えてみる必要がある
ワクワクして、情熱を感じる必要がある。

スクラムは組織を美しくしていくもの。
そうなっていなければ、改善が必要。
５つのS
日本の主婦からきている
家事　housekeeping
すべてのテストはパスしていますか？
日時のリズム、クリーンアップを習慣づけてください

Swarming
チームが全員、同じことに作業する

かんばん方式　
在庫があるのは恥ずべき事。かんばんがよいことであることを宣伝する人がいるが、そうじゃない。
この幻想をもとに作られた手法がたくさんある。
Swarmingはチームワーク

７．忘牛存人　・・・　家に戻ってくれば、牛を捉まえてきたことを忘れ、牛も忘れる

無為　何もしない
環境と調和する
自然についていく
毎日、変更に対応していくこと
それを無為と言う見方で行っていく
真の自分に戻っていく
個人を中心に据えないといけない。

スクラム＝刺身


８．人牛倶忘　・・・　牛を捉まえようとした理由を忘れ、捉まえた牛を忘れ、捉まえたことも忘れる[1]。忘れるということもなくなる世界
無我。世界があるだけ。

９．返本還源　・・・　何もない清浄無垢の世界からは、ありのままの世界が目に入る
自然からリーダーシップを学ぶ
自然こそが我々をコントロールしている。
それと調和をすること。
お客さんをコントロールするのではない。
私とあなた、という概念はない。私たち。
自然から学ぶ。

１０．入鄽垂手　・・・　悟りを開いたとしても、そこに止まっていては無益。再び世俗の世界に入り、人々に安らぎを与え、悟りへ導く必要がある

人を理解するには自分を理解しないといけない

アジャイルコーチ活用術





セッション内容：https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11780

アジャイルコーチは何をする人？
アジャイルコーチのゴールは、チームを自走できるようにすること。育てる。

ティーチングとコーチング
ティーチングが必要なことは多い。まずは教える必要があることが多い。
相手の状況に応じてやりかたを変える。

アジャイルコーチとスクラムマスターの違い
アジャイルコーチはスクラムマスターと違い、スクラムチームの責任を負うことはできない。

期待値を設定する
アジャイルコーチに何をどうやって依頼するか？
→　期待値を設定する。これが今日の結論。期待値が無いまま外部の人を呼んでも意味が無い
大事なのは、優先順位付け。プロダクトバックログと同じ。同時に複数のことをやろうとしない。
コーチじゃなくて、技術のスペシャリスト呼んだほうがいいこともある。
期待値によって適切なソリューションを選択する

頻度や期間をどう設定するか
頻度や期間は期待値に密接に関係がある。
予算ありきにすると不十分な結果になる。予算がこれだけだから何回支援できるか、じゃない。

コーチングの期間が見短すぎると成果が出にくい。3か月は最低限必要。
タックマンモデルでも言ってるけど、3か月でも変わらないならコーチや現場に問題あり。

コーチが朝から晩まで週5日います、は役に立たない。ずっといる必要はない。
毎日いましょうか、とコーチに言われたら疑ってください。
感覚的には、週１～２。

よくある依頼のパターン
準備期間は手集めに支援。
3か月くらい経ったら週１くらい。
コーチはプロジェクトの初めから呼んでもらったほうが、途中で呼ぶより効果がある。
後から呼ばれても負け戦は変えられないことがある。

コーチに依頼すべきでないこと
スクラムチームがやるべき作業をコーチに依頼するのはダメ
今できないことをできるようにするのがコーチの目的。
アウトソースするのではない。
「達成」を依頼するのもダメ。コーチに権限と金を潤沢に渡さない限り、それは無理。

必然的にアジャイルコーチには継続的学習が必要
コーチは、みんながハマるところを事前に学習しておくことが非常に重要。
インプットがコーチングの質を上げる。
忙しすぎるコーチはまずい。
安い単価だと、稼働率を上げないといけない。
コーチの価格は、経験を含めての値付けになってる。
学習とかも価格に入っている。

アジャイルコーチとの相性
コーチも人間なので相性がある。
期待値を明らかにして、それにあったコーチを選ぶ。

よいアジャイルコーチを見つける方法
まずはコーチと会いましょう。

コーチの有効性の評価
定量的にコーチの効果を表すのは無理。
チームの状況がどう変わったかで見る。
定性的なものが軸になりやすい。

いつコーチの依頼を終了すべきか
自分達で走れるようになったらコーチから離れる。

みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか？





セッション内容：https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11778/outcome

OutcomeよりOutputのほうが評価しやすいので、重視しがち。
OutputできてないのにOutcomeを主張しても説得力がない。
PBIの価値を「ダイヤ」という単位で評価する。
https://guildworks.jp/works/item.html?id=53
ダイヤの運用で、詳細化する時はICEスコアのようなフレームワークを使う
ICEスコア　＝　影響力（Impact）　×　信頼度（Conficence）　×　容易性（Ease）
PBIの項目はインパクトトラッカーを参考にしている。

★スクラムガイドには以下に記述がある。
"プロダクトバックログには、詳細・並び順・見積り・価値の属性がある。"



見積りしないスクラム





セッション内容：https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12120/noestimates-scrum

見積には隠れた５つのコストがある
・80/20の法則のコスト
・遅延コスト
・設計トレードオフ　・・・　数値化によるコミット圧力
・見積作成時間　・・・　数値化による仕事量の最大化
・パーキンソンの法則のコスト　・・・　数値化による正確であるという錯覚

→　↑２つが優先順位付け（価値見積り）の問題で、下の３つが数値化することによる問題。

NoEstimate ＝　要求される機能を、サイズ/期間の数値に変換せず、意思決定に必要なコスト、情報、価値を取り出すこと

PBIやSBIの見積はしない。
・PBI（ユーザーストーリー）のサイズを1スプリント（１Week）以内にコントロールする。
・SBI（タスク）のサイズを1日以内にコントロールする。

スプリントの進捗はデイリースクラムでタスクの残数と残日数で確認する。

★このセッションにも、１つ前の中村さんのセッションにも、両者で「価値見積り」の話が出来てきた。
・中村さん：　ダイヤ
・陶山さん：　Cost of Delay　（この機能のデリバリが遅れると、単位期間にどれだけ損失があるか？）



モブプログラミング x 行動分析学 x 教育


モブプログラミング x 行動分析学 x 教育 from Takuo Doi

セッション内容：https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11896/x-x-mob-programing-x-behavior-analysis-x-education

行動分析学
・行動を変える変数を実験によって探る方法論
・意志の弱さや能力のせいにしない

行動随伴性
・好子：　その行動を強化する刺激
・嫌子：　その行動を弱化する刺激

好子による介入の方が、嫌子による介入より良い

特殊部隊SETチームの日常　- 技術と実験を融合した実践アジャイル術 -





セッション内容：https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11774/set-

１．プロダクト開発チームと共に在る
・上手くいかない仮説：　施策が他人事になる
・検証のポイント：　プロダクト開発チームと一緒に取り組む。プロダクト開発チームと一緒に苦しんで取り組む。

チームと3か月一緒に働き、一緒に取り組む。一緒に痛い目にあうことで本当に必要なものを発見・提供する。

２．Learning Session：　チーム力の強化
新しい人をチームになじませて成果をだせるようにする
Onboarding　・・・　組織の一員やサービスのユーザーとして新しく加入したメンバーに手ほどきを行い、慣れさせるプロセス

仮説：　業務時間内に勉強することこそ当たり前ではないのか
業務時間内にやる勉強会の手法 →　Learning Lession
・仕事に必要な技能の習得
　・チームの強化
　・チームのプロセス改善

３．Design Sprint：　技術戦略の策定・実施
Design Sprintは、以下を一週間単位で実施する
　・アイデア出し
　・プロトタイピング
　・ユーザー実験

効果あった。ダメなら即捨てられる。



テックリードは未来の話をしよう





セッション内容：https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11890/tech-lead-in-scrum

The Seven Levels of Authority
「The Seven Levels of Authority」のLevel１（指示する）からLevel7（任せる）に一気にいってしまって、上手くいかなかった。
１．指示する　→　２．説得する　→　３．相談する　→　４．合意する　→　５．助言する　→　６．尋ねる　→　７．任せる
Level1からLevel7までの間が大事

学び：チームの成長を支える
　１．変化に適応する
　２．献身を信頼する　（コミットメントは献身のことであり、最終結果に対してではなく、行動や努力に対して適用される）
　３．心を否定しない　（心を変えるのではなく、それを生み出す元となった部分を取り除く）

スクラムの価値基準にコミットメントが入っている

大切だなって思うこと
１．現在地を確認（現状を受け入れる）　・・・　誰かのせいにしたくなったときは期待で動いている
↓
２．目的地を確認（自分色のビジョン）　・・・　強い信念を持って目指す場所を描こう
↓
３．進む（選ばない選択）　・・・　何かを選ぶときには何かを選ばないということも選んでいる

→　このループ　＝　失敗と学習



2日目へ（Comming Soon）
関連記事

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/345-23fb9140
この記事にトラックバックする(FC2ブログユーザー)

-->