肥大化したプロダクトバックログを捨て、部署横断で1から再構築している話
2019年4月からスクラムで開発をしています。
チームには「他部署からの要望」や「経営判断による最優先事項」が集中しやすく、
プロダクトバックログは、自分たちでコントロールすることができないほどのアイテム数に肥大化していました。
結果、
「あのチームは、依頼してもやってくれない」
「自分たちは、本当に価値のあるものを提供できているのだろうか」
そんな声が聞こえるようになってしまいました。
現在、この状況を打破すべく、一度プロダクトバックログを捨て、部署横断で1から再構築しています。
プロダクトバックログの作り方を変えたことで、開発のプロセス自体も変化しました。
このプロポーザルを書いている時点では、再構築したプロダクトバックログを使い、1スプリント終わったところです。
一度もらった要望を捨てるという判断にも関わらず、どうやって他部署から協力を得ることができたのか、
このチャレンジにより、どんな変化が起き、どんなことを学んだのか
といったことをご紹介できれば、と思っています。
Outline/Structure of the Talk
- チームの背景
- この2年での開発プロセスの変化
- チームの役割
- 自分たちは、本当に価値のあるものを提供できているのだろうか
-
着手前もリリース後も、価値の検証が出来ていない
-
着手前に価値の検証をしたくても、PBIが多すぎる
-
- あのチームは、依頼してもやってくれない
- 擦り合っていない期待値から生まれる不信感
- プロダクトバックログを捨て、再構築する
- プロダクトバックログの作り方の見直し
- 他部署に協力してもらわないといけない
- まずはスモールスタートで、1部署だけ巻き込む
- 実際にやってみた
- ぼろぼろ出てくる課題
- その中で見えた希望
- 今後やってみたいこと
- 課題の解消
- 巻き込む部署の拡充
Learning Outcome
- チームが成果を出せていない、と感じたときの、改善のための方法の1つを知ることができる
- もしくは、そんなチームの事例を知ることができる
-
プロダクトバックログの作り方の1つの形を知ることができる
-
他部署の巻き込んで、既存のやり方を変えた方法を知ることができる
Target Audience
チームの成果に疑問がある人、プロダクトバックログがいけてないと感じる人、他部署を巻き込んだ改善に踏み出せない人
schedule Submitted 1 year ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Tatsuya Sato - なぜ私はチームにい続けるのか。あるいは、エンジニアとしての成長のためのチームの活用について。
20 Mins
Talk
Beginner
2016年夏、あるチームが解散となりました。そのチームのうち、社内に残ったエンジニアは一人。当時、彼は一人でプロジェクトをこなしていました。ステークホルダーから感謝されていたので一人で開発を続けていました。しかし、エンジニアとしての成長は殆どありませんでした。切っ掛けでとあるチームでエンジニアを募集していることを知りました。技術スタックもそれまでの事業領域も異なるところでやっていけるのだろうか?と彼は悩みました。そのチームにいるエンジニアと一緒に働きたいという想いからそのチームへ入ることにしました。あの時の彼の決断は正しかった、と今の私なら言えます。
このセッションは、RSGT2020で発表された「Team-Based TEAM - 会社を越えるチーム」に対するアンサーセッションです。RSGT2020当日に初めてこのセッションの内容を知りました。それでも「あぁ、わかる。これは自分たちだ。」と思える内容でした。このセッションでは、Team-basedチームの一員として得られたものが何かについてお話します。
-
keyboard_arrow_down
Tomonori Fukuta - 田舎で14年スクラム - Agile未開の地に降り立ったらあなたはどうしますか
20 Mins
Talk
Beginner
Regional Scrum Gathering Tokyo 2020 で「田舎で14年スクラム - チームを導く現場の「ゲームモデル」づくり」というプロポーザルを出したら落ちたのと、当該カンファレンスで2つもゲームモデルの話があったので、田舎の未開度合いと、そこで発見した奇跡について話したいです。
鳥取に比べたら、世界中スクラムパラダイスやで!
前回「田舎で11年スクラム」との違い
- 1年経過しました
- 計算間違ってません
- 田舎のスクラムチームを取り巻く状況はさらに深刻に
- 田舎では、会社の中でスクラムチーム運営してますわーいだけでは先がありません
- Long-Stable-Teamを求めて、ちんもは自分が働いている土地とそこに住む人々について改めて考えることになりました
-
keyboard_arrow_down
kyon _mm / neno neno / Gota Miyazaki / Takao Oyobe - Agile Wars − アジャイルチームの夜明け −
kyon _mmTest Architectオンザロードneno nenosoftware developerGota MiyazakiSoftware DeveloperDENSOTakao Oyobeアジャイルモンスター株式会社デンソーschedule 1 year ago
90 Mins
Talk
Intermediate
予告動画 : https://www.youtube.com/watch?v=ymZnqdUQ8DE&feature=youtu.be
数度目のアジャイル開発戦争が勃発。
内製開発企業と受託開発企業ではそれぞれのビジネスと命運をかけて防御壁を展開、エンジニア獲得の勢力図がうごいていた。Scrumの加護をうけし組織となるために工作を展開する企業。
それに反発し自由と共同を求めてオープンなコミュニティをつくりあげるものたち。終わりが見えない戦争に希望を見出すため、各組織では次世代の旗手をみつけ育成する作戦が遂行された。
そしてミレニアル世代が第一線に配属され、時代はひとつの転換を向かえようとしていた・・・ -
keyboard_arrow_down
Yukio Okajima / Yuichi Hashimoto - 「ここがアジャイルの世界か」 ~ 業務SEがアジャイラーになるまでの8か月
Yukio OkajimaDirector of Agile Studio Fukui株式会社永和システムマネジメントYuichi Hashimoto--schedule 1 year ago
45 Mins
Talk
Beginner
巨大ウォーターフォールプロジェクトの一員であった業務SEは、8か月後、重要なアジャイルプロジェクト(※)を任されるエンジニアになっていました。
「なぜ?」「どうやって?」。このセッションでは、チャレンジした本人(橋本)とそれを支える組織(岡島)それぞれの目線から、次の切り口で明らかにしていきます。
- 価値:変化を抱擁する世界へのチャレンジと、それを支援するアジャイル組織の在り方
- 原則:本気で取り組むための「ビジネスと学びの両立」「段階的動機付け」「組織能力化」
- プラクティス:プログラミング未経験の業務SEが成長するために日々考え実行したこと
※ https://jbpress.ismedia.jp/articles/-/57937
-
keyboard_arrow_down
Ryo Tanaka - 会社組織で実験をしていくためのサバイバルテクニック
20 Mins
Talk
Beginner
実験場はどうして必要か?
企業の中で企業を変えようとしているスクラムマスターやアジャイルプラクティショナーの皆様。
コミュニティや本などで仕入れた新しいワークショップや、メトリクスがうまく働くかを会社で試してみたいと思いますよね。でも、それ大丈夫ですか?
安全ですか?失敗しても大丈夫ですか?失敗しないようにがんばりますか?
でも、失敗ってしたほうがいいんですよね。会社組織は良い実験場か?
そもそも会社組織の中で最初に実験するのってハイリスク・ハイリターンですよね?
失敗した場合ときには実験を止めたいと思いますが、下手に予算やOKRが決まってたりすると、とりあえず四半期ぐらいは引くに引けない状態になったりして、危険な状態になることがあります。そうならないように、安全に実験できる場所を探しましょう!
そのためのサバイバルテクニックを考えましょう。サバイバルテクニック
#1 趣味を増やそう!
単に趣味を増やすことに意味はありません。
社会性が得られる趣味であれば、それは立派に実験場として機能します。#2 地域コミュニティに参加しよう!
PTAや自治会、地元神輿会など、地域コミュニティも立派な実験場です。
#3 家族を実験に
家族との信頼関係が利用できる場合は、実験目的を話して実験に協力してもらいましょう。
父親、母親、子息、伴侶それぞれ幅広い年齢層に対して実験できます。 -
keyboard_arrow_down
Shuichi Matsubara - で、結局 "誰に" 価値を届けるの?〜大企業のアジャイル開発で失敗に成功した話〜
20 Mins
Talk
Beginner
我々は誰に"価値"を届けるのでしょうか?
エンドユーザー?自動車メーカー?事業部長??
大企業はPOからエンドユーザーまでが遠すぎます。
そして、POと開発チームの間にも距離感を感じている方もいるのではないでしょうか?
では、"価値"とはなんでしょうか?
ユーザーの求める価値=ステークホルダーの求める価値でしょうか?
ステークホルダーの求める価値=POの考える価値でしょうか?
そして、POの考える価値=開発チームの考える価値でしょうか??
また、"価値"とはどうやったら生まれるのでしょうか??
失敗に成功した!
私のチームはとあるWebアプリ開発をスクラムで取り組みました。
結論を言うと、プロジェクトは予定通りリリースできました。が、その道のりは失敗の連続でした。
このセッションでは、とあるプロジェクトを通して私たちが経験した失敗談をお届けします。
しかし、結果的にこの失敗のおかげで私たちはアジャイルの原則に立ち返ることができ、開発チーム、PO、ステークホルダー、プロジェクトに関わった全員が大きく成長できました。そう、私たちは失敗に成功したのです!
皆さまには、プロジェクトの中で価値を生み出し続けるための明日から使える具体的な提案と、愛という"価値"をお届けするセッションになればと思います。
-
keyboard_arrow_down
Kanako Muroyama - プロダクトオーナーのチームビルディング 〜 心理的安全性が高く、自走できる組織の作り方。うまくいってちょっと泣いた話と、その後の話。
20 Mins
Talk
Intermediate
こんにちは。楽天 ランキングサービスグループの室山です。
楽天市場のランキングサービスでプロダクトオーナーのチームリーダーをやっています。
少し前、トラブルが多発し、モチベーションも低下していたグループの中で、プロダクトオーナーたちはそれぞれが孤独に責任を負っていました。
そこでチームビルディングのやり直しを行って、助け合うプロダクトオーナー組織へと変わりました。
モチベーションも低く疲弊したチームから、心理的安全性の高いチームへ。どうやって、心理的安全性の高いチームになったのか?
どうやって、メンバーは自走を始めたのか?
どうやって、メンバーは変化を受け入れてくれたのか?
私達が取り組んだチームビルディングと、そこから学んだことをお話します。
メンバーが「仕事が楽しい」って言ったとき、正直ちょっと泣きました。その後のお話も。
プロダクトオーナーだけでなく、チームをリードしている方々と、飲みながらでも語り合いたい!
課題共有の場になれば嬉しいです。本セッションは、2019年4月にDevLove関西「プロダクトオーナーの現場」でご紹介した
「トラブルだらけの現場から仕事が「楽しい」現場に変わった、6か月間の話」と、その後日談に関連した内容となります。
https://www.slideshare.net/cowappa/ss-141300729
ぜひこちらも合わせてご覧ください。(Slidesの項目に記載したスライドと同じです) -
keyboard_arrow_down
Mototsugu Uezono - 自己組織化されたチームを目指してCSDを取得してRSGTに参加したらチームを離れることになった話
20 Mins
Talk
Intermediate
3年前に自己組織化したチームを目指して独学でスクラムを学び、アジャイル開発もどきをスタートさせました。
そこからアジャイルコーチに支援してもらいながら徐々に独り立ちを目指し、SMはCSMを、POはCSPOを、Dev(自分)はCSDを取得しチームの練度を高め、アジャイルな活動を広げてきた結果、チームを離れることになってしまった話です。
チームと僕の未来はどうなっていくのでしょう。
-
keyboard_arrow_down
Daisuke Kasuya - プロダクトを5年間運用したチームの歴史 - 長く続くチームづくり -
45 Mins
Talk
Advanced
Mackerelというプロダクトはローンチから5年が経ちました。ぼくはそのほぼすべての期間、このチームに在籍していて、うち3年間はマネージャーとしてチームを運営しています。5年間運用されたチームではさまざまなことが起こりますが、いくつか事例をご紹介しながら、長く安定的に続くチームづくりについて考えていきたいと思います。
-
keyboard_arrow_down
Yuma Konishi - プロダクトのグロースのためのチームを立ち上げてプロセス改善をしている話
20 Mins
Talk
Intermediate
株式会社i-plugにて自社サービスのOfferboxの開発をしている小西と申します。
Offerboxというプラットフォームの質的改善を加速するために、2019年秋からグロースに特化したチームを組成するというの話が上がり私がチームリーダーとして指揮を執ることになりました。
2019年4月よりスクラム開発をしており、ものを正しく作っていく部分はできるようになってきていたものの正しいものを作る部分は経験がありませんでした。その状態から価値あるプロダクトを提供できるように他職種(デザイナーやデータアナリスト)の方と協力しながらこれまでデュアルトラックアジャイルのような開発プロセスを構築してきました。
データアナリストとともにABテストをしたりデザイナーとともにユーザーテストをしたり、その結果を踏まえて仕様を磨いたり廃案にしたり提供価値にこだわった意思決定をしています。
また、職種をまたいで連携することで1つ1つの工程のクオリティを高めることにもこだわっています。そのような現場で具体的にどのようにプロダクト開発を行っているのかという状況であったりそれを実現するまでの過程であったりをご紹介できればと思っています。
-
keyboard_arrow_down
Takuo Doi - 行動分析学でScrumチームの課題を解決してみよう!
45 Mins
Talk
Intermediate
Regional Scrum Gathering Tokyo 2019、Regional Scrum Gathering Tokyo 2020では、行動分析学という視点から見たScrumチームについての考えをお話させて頂きました。そして、この話を聞いて、行動分析学に興味を持ったよと言ってくださった方もいらっしゃました。
一方で、行動分析学的な観点でScrumチームの課題を自分で分析しようとした場合には、どのように分析をし、どのような点に注意をすればよいかのご質問も頂きました。
そこで、本セッションでは、参加者の皆様と一緒に具体的なケースを想定し、一緒に分析をし、その行動の改善につなげるための介入の施策を検討してみたいと思います。
-
keyboard_arrow_down
徳冨 優一 - ミルクボーイがスクラムを説明したら
20 Mins
Talk
Beginner
駒場
「最近、うちのおかんがシステム開発に興味を持っててなぁ。名前は忘れたんやけど、その開発手法には "プロダクトオーナー" ってゆー役割があるってゆーてたんやわぁ。」内海
「そんなもん、スクラムやないのぉ〜。 プロダクトオーナーゆーたら、スクラムの三つのロールの一つやないのぉ〜。スクラムに決まりやがなぁ〜。」駒場
「オレも最初スクラムやと思っててんけどな、話しを聞いてみるとなんかちょっと違うねんなぁ〜。」内海
「違うことあれへんがなぁ〜。何が違うねんなぁ〜。」
続きは会場で。 -
keyboard_arrow_down
Yasunobu Kawaguchi - とにかくおもろいセッション
20 Mins
Talk
Beginner
なんやて!このセッションおもろそうやな〜。
だから大阪好っきゃねん。
-
keyboard_arrow_down
Yoh Nakamura / Yuusuke Sakai - 公開Coaches Clinic 〜アジャイルコーチに相談してみよう〜
90 Mins
Workshop
Beginner
アジャイルやスクラムなどについて悩んでいる時、みなさんはどうしますか?
インターネットなどで似たような悩みを解決した話がないか調べてみたり、SNSでつぶやいてみたり、同僚に相談したりする人もいます。みなさんの現場にアジャイルコーチがいるなら話してみるのもいいかもしれません。多くのアジャイルコーチはアジャイルなマインドセットや幅広い知見を持っています。しかしそんなアジャイルコーチがすべての現場にいるわけではありません。
先日のRegional Scrum Gathering Tokyo 2020では Coaches Clinic という、アジャイルコーチに(基本)1対1で相談できる場がありました。
この時間では、その Coaches Clinic の紹介をし、実際にどのような感じで行われるのかを見ていただこうと思います。このセッションを終わった後には、ScrumFestOsakaでも Coaches Clinic の場ができるといいと考えています。
※Workshop(90分)を選択していますが、30〜45分の想定です。
-
keyboard_arrow_down
Tatsuya Sato / Hiroaki Ono - いつもの前説
Tatsuya SatoSoftware DeveloperDENSOHiroaki OnoSoftware DeveloperRakuten, Inc.schedule 1 year ago
20 Mins
Talk
Beginner
後の講演を楽しめるようにするために場を暖めます。
-
keyboard_arrow_down
Yasunobu Kawaguchi - とにかく明るいオンラインセッション
20 Mins
Talk
Beginner
たのしいでっせ
-
keyboard_arrow_down
Yasunobu Kawaguchi / Miho Nagase / Takahiro Kaihara - プロダクト生存戦略 : スクラムギャザリング東京の10年から学ぶ
Yasunobu KawaguchiAgile CoachAgilergo ConsultingMiho NagaseAgile CoachAttractor Inc.Takahiro KaiharaJesterTao of Scrum Kansaischedule 1 year ago
45 Mins
Talk
Advanced
なかなか東京だと実現できない実行委員やスタッフや参加者の方のふりかえりを通じて、東京のRSGTで何が起こっていて、どう思って運営していて、これまでどんな事件があったか、みたいなのを話し合ってみたいです。
実行委員やスタッフで参加される方、共同登壇者に名前を連ねませんか?2-3人でできればと思います。実行委員で東京のスタッフをされた方にも声掛けしたいです。
-
keyboard_arrow_down
Etsuo Yamada - アジャイルチーム成長の過程ってどんな感じ?
20 Mins
Talk
Beginner
はじめて組織にアジャイル開発が採用された時、そのチームはどのように成長していくのだろうか?またそれに伴って、組織にどのような変化が起きやすいのだろうか?事例はたくさん聞いたけどどう取り入れればいいか。。。そんな事例の迷路にはまっていませんか?
もちろん、事例から学べることはたくさんあるのですが、このこのセッションではアジャイルコーチとして現場をみてきた経験を元に、おおよそ共通してみられる以下の2点についてお話いたします。- どの現場でも起きるであろうチームが成長する過程
- アジャイルチームの成長に伴い組織に与える影響とその対策
-
keyboard_arrow_down
知宏後藤 - 要件設計から開発へ、繋がるデザイン設計のあり方
45 Mins
Talk
Intermediate
デザインは、要件定義から開発への流れを支える重要な工程です。
要件定義で交わした内容がデザインに反映されていない、
出されたデザインの実装コストが大きく開発部門を圧迫する…UIや見た目の良し悪しとは別の問題として、デザインを取り巻くワークフローの問題は
概ね「コミュニケーションする」で解決されがちです。本セッションでは、デザインを要件定義から開発へのフローを橋渡しするステップ捉え、
「伝わるデザイン」のありかたと、デザインを通じたワークフロー設計を考えてみます。
Public Feedback