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