CSP-SM受けてみることにしたその9(ファシリテーション、POのスケーリング)

2022年4月11日 21:52

これまでの話はここからはじまる

まえがき

なんだかご機嫌なMarcの日でした。

と思わせて突如、日本はどんな感じ？って話になりました。
ドイツではコロナとウクライナロシアの影響でダメージがきついらしいです。

些細なことだけど、近くの人が何かしらの影響を受けていることで、より自分ごと化できる気がします。

そのテーマで話せたことに感謝せねば。

事前レポートの内容をベースに話ていくセッションです。
今回の指摘事項は・・・。

「ちょっと具象化しすぎているかも」

というフィードバック。もっと簡単な意思決定の方法とかでよかったらしく・・・。

決定のプロトコルをどう作り上げていくかというようなフィードバックで終了。

A-CSM時で終了している内容だった。

それとは別で、共通で使用しているSaaS的な基盤を自社で開発した場合はプロダクトに当たるのかという議論がありました。

「プロダクトとは、顧客に価値提供しているものだよ」

という話になり、「けどこの場合はその基盤を使っている人を顧客と考えればいいんじゃない？」と聞いてみたり。

プロダクトオーナーのスケーリングは、基本的に階層構造を作って意思決定者を1人にするのがセオリーだそうです。

多重階層での意思決定の遅れを取るのか、それとも横並びのチームで合意形成が難しいことを取るのか・・・って議論になる気がしてなかなかしっくり来ませんでした。

結局のところ、スケーリングを考えすぎる事態がなんなんだ？というところと、意思決定の待ちが発生しない構造を綺麗に作りましょうという話な気がしました・・・。

スクラムアライアンスもチーフPOの制度だったらしい！

POは8チームが最大だと言われていたりするらしいです・・・。

まず最初に聞かれたのが、「システムエンジニアリングにルーツがあるよね？」という再確認をされました。スクラムマスターがシステム開発にルーツがないこともよくあるくらいドイツではスクラムが一般化しているのだろうか？？

そんなこんなで、Marcの好きなパートだったのか、熱く語ってくれた気がします。

エンジニアは全てのコードベースを知っておく必要がある
Continuous Improvement/Continuous Refactoringを通じてシステムをよくする必要がある
負債が貯まることは、最終的には経営の悪化につながっていく
- SonarCubeを使ってコードをよくする
- ペアプロでスキルやコードの品質を担保する
- リファインメント時に技術だけでなく業務知識の知識量を均一にすることも必要(エキスパートとノンエキスパートのペアがいいよ)

今回は肩の力の抜けた豆知識が多い回だった気がする。

ちょっとした知識を与えてくれるようなところがこういうセッションの醍醐味だなーと実感。

いよいよ最終回が近づいてきています。

多めに予約していたものがMarcによってキャンセルされていました・・・。

さぁ・・・いい感じに終われるのか！？