Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RSGT2019 スクラムならできる プロダクトバックログの戦略

1,749 views

Published on

Regional Scrum Gathering Tokyo 2019 Day1 Hall-B

Published in: Engineering

RSGT2019 スクラムならできる プロダクトバックログの戦略

  1. 1. スクラムならできる プロダクトバックログの 戦略 RSGT2019
  2. 2. 2自己紹介 去年まで… アジャイルコーチ 開発チームの活性化・開発戦略の支援 Certified ScrumMaster® (2010) Certified Scrum Product Owner® (2011) Certified Scrum Professional® (2016)
  3. 3. 自己紹介 3 2018年2月から… 株式会社AmidA ICT部
  4. 4. システムリニューアル後で大変な時期 4
  5. 5. 5 繁忙期であり、そこそこのペースでアウトプットしてる タスクを共有すること、コミュニケーションすることに慣 れていない まずは、各自が抱える問題を共有して、相互扶助を体感す ることから スクラムは 徐々にやってこうかな
  6. 6. プロダクト課題を把握する 6
  7. 7. 部長、 知らないでは済まされませんよ
  8. 8. 8 合意されていた重要案件が間に合わない 管理能力を不信がられる • 手を付けていない案件がある -状況把握の能力に難があるんじゃないか • 全員でミーティングをやってる -研修をしている場合か (アジャイルコーチは研修屋ではありません) • ガントチャートやスケジュールの類の情報が出ていない -そもそもPM技能が不足してないか 洗礼を受ける
  9. 9. 9 やっぱ、スクラムでいこう バラバラの作業を統合しなければ 作業それぞれの責任の始まりと終わりをハッキリさせよう 着手するより終わらせていこう
  10. 10. 過去に「スクラム(らしきもの)」を実践していたと きに存在した会議体 • 事業部長が全員参加 • 「バックログの順序を調整する」ため • リリース前に忙しくなって立ち消えた システム調整会議はじまる
  11. 11. いざ、開催してみたら… • ICT部への不信感、私への不信感 • 要望を伝える。課題共有しない • 事業部にとって手が出せないシステム問題の不満を共有する場 システム調整会議はじまる
  12. 12. プロダクトバックログ でチームを引っ張る
  13. 13. 進捗させること 決して作業や工程が「完了した」ことではなく、 前に進んでいるという実感、それを外部と共有すること チームがやっていることに意味を持たせる 業務で利用できる状態を明確に示す 完成できる内容・大きさ 品質に注意を怠らない
  14. 14. 実現するとどんな変化を起こすのか いま必要とされているか?それはどんな条件か? 何が動けば、来週にドヤ顔できるか PBIそれぞれの持つ意味で順番を決める 「価値の高い順」って??? カネ・時間による評価は複雑で変動する 良いかどうかは、機能性よりも、どう使われるかによる
  15. 15. 15 「作業用のバーコードリーダーの反応が遅い」 と業務部門から相談を受ける → その場で実演してもらう → エンジニアもいじってみる → 「解決できるかも」とエンジニアから提案 → やりましょう! 風が変わる
  16. 16. 16 「せっかくなので、もう少し使いやすくしないか」  現状が、開発者目線で作られた機能のかたまりだった  利用するストーリーで評価しながら改修
  17. 17. チームとの会話のなかで導き出す 1. スプリントに選んだPBIを包括するような言葉 2. PBIを入れ替えたり、言い換えたりしてみる 3. 繰り返すうちに、ピタっとくる魅力的なゴールが見つかる 徐々に、ICT部が主導権を持って進めるようになってきた スプリントゴールに合意する PBIを並べてるだけでは一貫性が欠けがち  チームがPBIの詳細から一歩高い視点が持てる  スプリントの成果として実績を作っていける
  18. 18. 事業部間の システム調整会議 も、少しずつサマになってきた
  19. 19. 19 調整会議前に、 1. 事業部ごとにリスト分割して配布 2. 事業部長の責任で、順番または重みづけをしてもらう 3. ICT部長の権限において1列のリストにマージする 毎月実施:1ヶ月のサイクルで事業部要望を反映する PBIの並びについて希望を出してもらう
  20. 20. 20 日の近いものだけ議論すればいい 要望はリストに入れられて、翌月には順番を指定できる 各事業部とも要望したことがだいたい頭に入っている 「そういえば、コレ、昔にウチ(事業部)がお願いしたん だろうけど、興味ないんだよね」 事業部で誰が要求に責任を持てるのか、それが明確に なってきた 調整会議が変化した
  21. 21. 小さなAwesome
  22. 22. 22 まだ信頼は不十分 「リリースしてから使えるようになるのに、 3ヵ月はかかるだろう」 ※実際は優しく会話いただいています どんな要素を組み上げるのか、まるで分からない • 該当箇所がシステムの全域にわたる • 実装が複雑に関連していて分離できない 「新しい拠点を立ち上げる」
  23. 23. 全員で理解する 個別の機能よりも、利用の流れ全体を俯瞰する 基本パス以外を徹底的にそぎ落とす 数日で大まかな形ができた  残件はあるが、それが何か具体的になっている  デモを事業部に見てもらい、実感を持ってもらえた  稼働させる時期を優先して、残件が見直された 23チームだけが頼りの綱
  24. 24. その後のAwesome 24
  25. 25. ある日、 社長に呼び止められる 25
  26. 26. ひゃっほー 褒められた!
  27. 27. まとめ にかえて
  28. 28. 28 「善い」目的をつくる能力 場をタイムリーにつくる能力 ありのままの現実を直視する能力 直感の本質を概念化する能力 概念を実現する政治力 実践知を組織化する能力 「フロネティック・リーダーに必要な6つの能力」野中郁次郎 リーダーシップの要素
  29. 29. 29「半分の時間で倍の効果」 これまで通りの遷移 ベロシティが徐々に倍 になった場合の遷移 バックログを半分に した場合の遷移 チームが倍のスピードで働くより、 プロダクトバックログを半分にしたほうが効果的

×