Yuusuke Sakai
Specialises In (based on submitted proposals)
前職で、スクラムに出会い、挫折し、アジャイルコーチと出会って、やっぱりスクラムが好きになる。
スクラムマスターを経験後、転職。
開発プロセスの改善を行いつつ、その先に、高速で価値を提供し続ける開発チーム、事業部と一体になったプロダクト作りを目指す。
-
keyboard_arrow_down
肥大化したプロダクトバックログを捨て、部署横断で１から再構築している話
20 Mins
Talk
Intermediate
2019年4月からスクラムで開発をしています。
チームには「他部署からの要望」や「経営判断による最優先事項」が集中しやすく、
プロダクトバックログは、自分たちでコントロールすることができないほどのアイテム数に肥大化していました。
結果、
「あのチームは、依頼してもやってくれない」
「自分たちは、本当に価値のあるものを提供できているのだろうか」
そんな声が聞こえるようになってしまいました。
現在、この状況を打破すべく、一度プロダクトバックログを捨て、部署横断で１から再構築しています。
プロダクトバックログの作り方を変えたことで、開発のプロセス自体も変化しました。
このプロポーザルを書いている時点では、再構築したプロダクトバックログを使い、1スプリント終わったところです。
一度もらった要望を捨てるという判断にも関わらず、どうやって他部署から協力を得ることができたのか、
このチャレンジにより、どんな変化が起き、どんなことを学んだのか
といったことをご紹介できれば、と思っています。
-
-
keyboard_arrow_down
失敗から学んだ、スクラム導入の負け筋と勝ち筋
20 Mins
Talk
Beginner
とあるECサイトを運営する前職での話です。
新システムプロジェクトに失敗。1からの再スタート。急いでシステムリプレースを進めねばならない。
そんな時にもたらされた一言。
「”スクラム”って知ってますか？」
そこから始まる阿鼻叫喚・悲喜こもごもの日々。
- 実はスクラムがどんなものか誰も知らない
- ふりかえらない
- プランニングしない
- プロダクトオーナー不在
ベテランの方々から見れば、鼻で笑ってしまうような出来事でも、同じような体験をした方、絶賛体験中の方いるんではないかと思います。
いきなり上手く出来なくてもいい。でもちゃんとスクラムできるチームになるためには？
未だ学習中の身なので偉そうなことは言えませんが、面白おかしい失敗談から、感じ取ってもらえればと思います。
-
No more submissions exist.
